A diagnostics startup proved its at-home testing concept with a booking MVP in ten weeks

Representative examplesEvery case study in this library is an illustrative composite of the kind of engagement we deliver — written to show our method and standards, not to name clients.

Where they started

The client was a diagnostics startup founded by lab scientists and a clinician — the lab was licensed, the collection kits were specified, and pilot contracts with two employer health programs were signed. What they did not have was any software: intake was a PDF form emailed to the founder's laptop, and kit dispatch was a text message to the courier. Their runway covered one build, and every agency quote they had collected assumed a bigger budget and a longer clock than their pilot contracts allowed.

What it was costing

The founding team had clinical partnerships and a lab but no product; every week without a working booking flow was a week their pilot contracts slipped, and bespoke agency quotes started at twice their runway.

What they could see

• Pilot contract start dates slipped twice while the founding team evaluated development quotes.
• Interested participants emailed a PDF intake form, and follow-ups depended on whoever opened the inbox that morning.
• Kit dispatch was a text to the courier with no record of what shipped or when it arrived.
• Eligibility questions were asked over the phone, inconsistently, and never recorded against the booking.
• Nobody could answer the pilot's core question — how many booked participants actually returned a usable sample.

The constraints we worked inside

• The MVP had to be releasable under the pilot contract's timeline, not a grand roadmap — scope discipline was the whole game.
• Sample-kit logistics start at a partner courier with a manual dispatch process for the pilot's first months.
• Regulatory lines had to stay uncrossed: no diagnosis, no results interpretation — booking and logistics only.

What had been tried before

Bought no-code licenses and had a co-founder assemble a booking funnel over two weekends.

The courier dispatch and kit tracking steps had no no-code equivalent, and the funnel could not emit the completion events the pilot contracts required.

Collected full-scope agency proposals for a patient platform with results delivery and clinician dashboards.

Every quote priced the roadmap, not the pilot — roughly twice the runway — and the regulatory surface of results interpretation added months they did not have.

Started a contract with a freelance developer to extend the no-code funnel with dispatch tracking.

Progress stalled whenever the founder was unavailable; after three weeks the working prototype still could not reconcile a shipped kit against a booking.

What we proposed

We proposed building only the booking spine — eligibility questions, slot selection, kit dispatch — plus a small ops console, and writing down everything else on a signed not-now list. The reasoning was the pilot itself: its success metric was completion rate from booking to received sample, so every screen and every event had to serve that measurement and nothing else. Courier dispatch and any future lab interface would sit behind narrow interfaces, so the manual pilot processes could later be replaced without reopening the product. Regulatory lines stayed drawn by construction — the system handled booking and logistics, never results.

Just as important is what we ruled out, and why:

• Extending the no-code funnel with custom code — The pilot's completion-rate question needed events from every step, and bolting instrumentation onto a funnel we did not control would have been archaeology, not analytics.
• A full patient platform with results delivery — Results interpretation crosses the regulatory line the founders could not cross during a pilot, and it would have doubled the build against a runway sized for one.
• Off-the-shelf scheduling software plus spreadsheets — Booking was the smallest third of the flow — kit dispatch and sample reconciliation were where the pilot would live or die, and no SaaS covered those.

How the work ran

Delivered by the systems pod — 2 engineers over 10 weeks, with working increments reviewed with the client every week.

The stack, and the reasoning

Next.js

The ops console and public booking flow share types and validation code, and one framework kept a two-engineer pod from splitting attention.

TypeScript

The founders will hand this codebase to their first engineering hire; types make the eligibility and dispatch rules legible to a newcomer instead of leaving them in a founder's head.

Postgres

The pilot's question is a funnel query — bookings to received samples joined by participant — and that is exactly what a relational database does natively.

Prisma

Schema discipline enforced the not-now list — anything not in the schema could not quietly grow features during a scope-sensitive build.

Vercel

Zero servers to operate matched a founding team with no engineer on payroll; previews also let the founders review each build on their phones.

What went wrong

How we worked together

Cadence

Monday scope calls with both founders, Thursday demos against the pilot checklist, and a running not-now list that absorbed every could-it-also request.

Client side

Both founders — the clinician owned eligibility content and regulatory lines, the lab scientist owned kit and courier reality, and both reviewed weekly builds.

Decisions

Anything the demo could not settle went to the founders' Thursday walk-through at the lab, where the clinician and the lab scientist decided in the room — or the default was the smaller scope.

They provided

Pilot contract terms, the courier's process as it actually ran, clinical review of the eligibility wording, and two hours a week of founder attention.

What changed

The headline: booking mvp live with the first pilot cohort scheduled and samples reconciled through the ops console — 0 → pilot-ready product, read from Pilot completion-rate dashboard. A second check: concept to first booked pilot appointment at 10 weeks.

The first conversation after launch was about the second cohort, not the backlog. Bookings arrive without an inbox check, dispatch is a sheet the courier acknowledges instead of a text thread, and the ops console answers the completion-rate question the founders had been assembling by hand from courier receipts. The not-now list survived the launch; the founders keep using it to deflect feature pressure from pilot contacts. Both pilot contracts started on the dates the amended agreements promised.

The result was read from Pilot completion-rate dashboard against the pre-engagement baseline over the stated window, with a guardrail check on concept to first booked pilot appointment. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

• The booking product repository with deployment pipeline and environment configuration
• The ops console with its dispatch-sheet and sample-reconciliation workflows documented for office use
• A written not-now list and signed scope decisions the founders retained for future phases
• The completion-rate event schema and query definitions behind the pilot dashboard
• Courier-facing dispatch sheet template and the confirmation process agreed with the partner