the.garage
A momentum engine for life sciences founders.
Founders in life sciences make decisions that cost months when they go wrong, and their tools forget them between sessions. the.garage builds the venture's context once and surfaces the right piece at the right moment. I designed it end to end and wrote most of the first front-end with Claude Code. It is in production, and the first pilots are being structured on it.
Highlights
- Onboarding as context: conversation, voice, documents
- the.engine, one memory holding what several sources know
- Generative UI: interface and content composed as needed
- Every screen opens on what to do next
- Timing: the right information or person, when needed
Problem
Early-stage founders in regulated fields make high-stakes decisions with scattered context. Get an FDA pathway or a funding call wrong and the cost lands in months a small venture cannot get back.
The knowledge a founder needs is spread across the accelerator, the university, the investor, the attorney and the regulator, and each of them holds a piece. AI chat answers with a paragraph, and the work is still undone when it ends.
the.garage began as a smart directory of who a life sciences founder needs to know. The question I brought was what a founder needs to do next, and why, a reason the founder may not have seen yet. The people stayed, and the system grew around them: the context of the venture, the record it has to get right, and the moment each of them matters.
I designed the.garage around one question: what shape should this answer take? While a founder is still thinking, it stays a conversation. When there is something to do, it becomes a decision to commit, a plan with owners, a template, or the person to call. The interface is generated in the moment, in the form the moment needs.
Building the context
Onboarding is where the context gets built. The founder talks, typed or spoken, and uploads what they have, a pitch deck or a patent draft. An agent reads all of it as the conversation goes and assembles a company profile beside it, with a meter showing how well the system knows the venture so far.
It asks the questions an operator would. Say “grow Ops and Sales” and it asks: if we check in ninety days from now and it went well, what specifically happened? By the time the founder reaches the.workshop, every session starts from that profile.
the.engine
Under the.workshop sits the.engine, the part of the.garage I find most interesting. It holds context from several places at once: the venture, the accelerator or fund it belongs to, the university it came out of, and the regulatory and funding record, FDA, CMS and SBIR among it. Before the model answers anything, the.engine assembles that picture. An answer about a 510(k) pathway starts from the founder’s own device and the predicates already on file.
Surfacing the right thing
What the.engine holds only matters if it appears at the right moment, in the right form. So nothing here is laid out by hand in advance. The model assembles the screen as it goes, and picks what shape it should take.
While a founder is researching, the.garage stays a conversation. When the work turns into a choice, it composes the interface for that choice: a decision to accept or skip, with the reason it was proposed, a trade-off matrix that re-ranks as priorities move, a plan with owners and dependencies, a template with the 510(k) package already drafted. When the next step needs a person, it surfaces one, with their record and a way to reach them. That is where the directory went.
Timing runs the other way too. Every decision is logged with where it came from, founder, AI or system, and when new evidence contradicts one, the.garage brings the old decision back beside it and asks whether to reaffirm, revise or revert. It arrives as a check-in on a date the founder set. In a regulated field that is what lets an expert trust the system: they can see what it knows, and overrule it.
How it was built
I directed a senior product designer through the early exploration and built alongside the developer writing the backend, and the codebase keeps growing with the team. The code I wrote with Claude Code, against a real database and real regulatory content, so what we argued about was always the working system. That is how I have worked in every leadership seat: player-coach, in the work while directing the people around it.
A scientist tells the.garage what they are working on, and leaves with a next step to commit to and a system that will remember why.
