How two hackathon teams built tools for scientists and small businesses with marimo
Authors: Mohammad Ahsan Fuzail, Brendan Giang, Kevin Lau, Konstantin Taletskiy, Sarah Tsai, David Wu, Jerry Yan
At two hackathons, Standard Physics (repo) and MIKMAK (repo) used marimo to turn Python projects into tools their audiences could use and review. Standard Physics built an app that lets small business owners scan their shops with an iPhone, identify potential accessibility issues, and explore changes to the layout. MIKMAK built interfaces for scientists to approve agent-proposed experiments and inspect what happened when laboratory robots executed them.
Standard Physics won the marimo track and “Most Production Ready” at CoreWeave Hacks. MIKMAK won first place overall and first in the Close the Loop track at a lab automation hackathon. Both teams used marimo to build interfaces alongside their underlying Python work, making their projects usable and open to review under hackathon deadlines.
Standard Physics (left) and MIKMAK (right)
#Standard Physics: exploring accessibility through an interactive prototype
Jerry Yan’s nonprofit held weekly meetings at a boba shop that had faced an accessibility lawsuit. That experience prompted a practical question: could a tool help small business owners identify potential accessibility problems and explore improvements to their spaces?
Jerry entered CoreWeave Hacks with three high school friends: Brendan Giang, David Wu, and Boris Nezlobin. Now studying at UC Berkeley, USC, and Stanford, the four formed Standard Physics after Boris shared the event in their group chat.
#From a room scan to an interaction
The prototype turned a phone scan into a detailed 3D room model, with textures from the photos. Users could adjust positions or distances by a few inches and see the accessibility checks update.
Moving a piece of furniture, for example, changed the narrowest point along a path through the room. Users could check whether the revised layout left enough space for a wheelchair and see which potential violations remained.
#Why a reactive notebook fit the project
marimo’s reactive execution connected these controls to the calculations: changing an input reran the computations that depended on it, so users could explore a layout and see the findings respond.
David had previously worked with Colab and local Jupyter notebooks. For this project, he wanted users to explore settings through an interface whose outputs updated as they interacted with it. With marimo, he said, “it feels more like an intelligent app.”
David had seen useful research software become difficult to adopt when people needed to configure an environment and run scripts. Brendan’s interest in filmmaking and storytelling shaped his focus on making the tool inviting to small business owners.
Since the hackathon, Brendan has been developing the user experience, preparing for an App Store launch, and recruiting small businesses in Los Angeles to beta-test the app. Boris and Jerry have been improving render quality and expanding the prototype’s visual features. The team reports that users have scanned more than 50,000 square feet across five California cities, from restaurants and boba shops to living rooms.
The team hopes to make the app free for small businesses and partner with nonprofit advocacy groups to improve accessibility.
#MIKMAK: making automated experiments open to scientific review
MIKMAK’s five members met at a lab automation hackathon. Kevin Lau, automation engineering manager at Myriad Genetics, brought about twelve years of laboratory automation experience, including leading teams in production diagnostic labs.
“The hard part of lab automation is no longer the robotics, it’s trust,” Kevin said. “Once an agent is proposing and driving the experiments, a scientist has to be able to look at a run afterward and see what was planned, what actually happened, and when someone had to step in. Without that, the data doesn’t get used.”
Their project connected agent-proposed experiments, physical laboratory runs, and analysis. Scientists needed to review proposed plans and inspect what happened during execution.
MIKMAK tested compounds that might block TEM-1, an enzyme bacteria use to break down penicillin and related antibiotics. The team measured the enzyme’s baseline activity, then tested how strongly candidate compounds inhibited it.
Across two rounds on physical hardware, agents designed experiments, generated robotic workflows, and interpreted results to propose the next round. Scientists approved each plan and started each run. Agent-initiated execution remained for future work.
#Scientists could review a plan before a run
MIKMAK used marimo at two points in the workflow. Before execution, an Approval agent displayed proposed conditions, including sample layouts, control wells, transfer volumes, and destination wells. Scientists could approve or reject a plan based on the assay’s requirements, then separately start the physical run. A dashboard presented agent usage, run history, and results, including whether runs passed or failed and whether they were manual or automated. The approval notebook and dashboard notebook are available in the team’s public repository.
#Building the interface alongside the experiment
Mohammad Ahsan Fuzail, an automation engineer at Lila Sciences, had discovered marimo while pursuing a master’s degree in AI.
With little time for separate interface development, Ahsan used a coding agent to build the marimo notebook from his description of what it should show.
On earlier projects, Ahsan had converted between Python files and Jupyter notebooks. Because a marimo notebook is itself a Python file, he could develop the code and interface together without that conversion step.
#Reviewing what actually happened
Ahsan had seen manual and automated experiments end up in separate tracking systems. Scientists who knew every step of a manual workflow could lose that visibility once robots took over.
MIKMAK fed manual and automated runs into one execution-tracking pipeline. An Audit agent used beads, a coding-agent memory system, to record actions and departures from the plan, including robot problems requiring manual intervention. Scientists could inspect each run’s history alongside its results in marimo.
The first experiment, measuring the enzyme’s activity, produced flat results. The team suspected the robot’s timing: by measurement, the earliest samples had been reacting for about half an hour. Reviewing the execution record in marimo showed where the time had gone. To distinguish a robotics problem from an assay problem, the team repeated the test manually on the same instrument with the same settings. The enzyme turns a yellow chemical red; the manually prepared samples changed color as expected, confirming that the assay worked. The agents used those results to design the next experiment and propose subsequent tests. Ahsan reported that every experiment, including the failed run, moved the science forward. Scientific validity still depended on the experiments and the team’s evaluation.
#Keeping the display useful as the workflow changed
The team reused existing robot-control skills supplied by the Zeon Systems platform, letting them focus on experimental workflows without first validating newly generated robot-control skills. They gave their agents these skills and the experimental context to optimize the workflow.
Kevin reported that the agents reordered the robot’s steps and changed the plate layout. The optimized physical run processed 48 samples in about 20 minutes, compared with 11 in about 30 minutes before optimization.
The Audit agent updated the plate map, which records the sample assigned to each well, for each run. Users selected a run from a dropdown in marimo to inspect its assignments without rebuilding the dashboard.
#Building and reviewing in the same workflow
The team continued working on the experiment without assigning someone solely to dashboard development. The same interfaces let scientists review the runs and judges examine the work.
#Making Python projects usable as they develop
Standard Physics built controls for exploring accessibility changes while developing its calculations. MIKMAK built interfaces for approving experiments and inspecting runs while developing its laboratory workflow. With marimo, both teams made their Python work usable within the same project, building interfaces for people to use and inspect as the underlying work continued.
marimo is the world’s best programming environment for working with data, and it’s all free and open source. Just pip install marimo or uv add marimo to get started.
