Ship an AI Product with a Tiny Team

Every engineering decision in this course was shaped by how little there was to spend it with, so start with the constraints honestly. Pre-seed is the earliest stage of startup funding — before a formal seed round — meaning minimal money and a minimal team. On Orca that meant a co-founder who was also the CTO, an extremely tight budget, and a headcount you could count on one hand.

The diagram makes the scale plain: at no point in the first year were there more than three people building the product. A team that small cannot afford to hand-build every screen, every workflow, and every background job. That single fact is the reason the rest of the architecture looks the way it does.

Small teams still need aggressive timelines; the trick is to make each version a thin, shippable slice rather than a grand rewrite. HIPAA below is the US health-privacy law that governs how patient data (called PHI, protected health information) must be handled — becoming HIPAA-compliant is a long, deliberate program, not a feature. Here is what was planned, and what actually shipped.

The diagram tracks the arc: a demo at month three, real pathologists on AI features a month or two later, the full v1-to-v5 gigapixel platform inside a year, and — by month eighteen — a raise of more than twenty million dollars plus a filed patent and five papers. The point is not the trophies; it is that a three-person team reached them, which is only possible if most of the work is not bespoke.

State the objective in one sentence so every later choice can be checked against it: ship an AI product with a tiny team. The way to do that is not to work faster on bespoke code — it is to change the shape of the work so that most of it stops being bespoke.

The reframe is this. Instead of building screens, build a system in which a new screen, a new workflow, or a new async job is a copy-paste of an existing pattern with a small change. Juniors become productive quickly by following a template; the seniors spend their time where the work is genuinely hard — the AI models and the backend.

The diagram contrasts the two paths: hand-building everything makes the tiny team the bottleneck, while turning the easy parts into templates frees the seniors for the parts only they can do. Everything in the next three days is a way to make some category of work a template.

The strategy is a set of three paradigms, each one an instance of "build it once, use it anywhere." Two terms to gloss first. SDUI (server-driven UI) means the server sends the screen's layout as data — as JSON — and the client simply renders whatever it is handed, so a new screen is a data change rather than new client code. IaC (infrastructure as code) means the servers and cloud configuration are defined in files kept in the repo, not clicked together by hand.

The diagram lays out the three paradigms that carry the rest of the course:

• Build the core once, use anywhere — data is just a model. The UI and the behavior of the system are expressed as JSON. A screen is a list of section objects; a background job is a list of steps. Two tiny, real examples of "data is just a model":

{ "type": "image_list", "title": "Projects", "data": "project_slides" }

{ "blueprint": "ki67", "org_id": "lab_b", "steps": ["inference"] }

The first is a UI section; the second is a whole workflow. Neither is code — both are data the platform reads. Days 3–4 open up the first; day 8 opens up the second.

• Build AI capabilities once, use anywhere. Any workload or job — upload, color correction, tiling, inference, statistics — goes through the same pipeline, so adding a new capability reuses machinery that already exists.
• Keep the infra light. Serverless where it is cheap, containers or GPUs where the work demands it, and all of it defined as code so the whole account can be rebuilt from the repo.

The reason a template wins for a tiny team is that it collapses many different-looking tasks into one shape that is learned once. On Orca, simplicity was the explicit bar: one renderer, one async pattern, one workflow shape — learn one, understand them all. Config over code: a new screen, workflow, or job is a JSON edit, not new architecture. Fewer dependencies and fewer moving parts mean a new engineer is productive on day one.

The diagram shows the division of labor the whole strategy is built to produce: a junior ships a real surface by copy-pasting a section JSON and reusing a component that is already registered; the senior reviews a JSON diff in minutes and goes back to the model and backend work. It works because everything on the platform is the same kind of thing.

The box-art states the invariant that makes juniors safe: everything is an async job, every job shares one schema and one skeleton, so a new job is a copy-paste rather than a fresh design. That uniformity is what let a small, junior-heavy team punch above its budget.

Strategy needs a delivery rhythm, and the rhythm was deliberately small and safe. The method was Shape Up (from 37signals): a fixed timeline with flexible scope, delivering one integrated vertical slice per cycle. A vertical slice is a single feature built through every layer at once — frontend, backend, and database — owned end to end by one engineer. A feature flag is a runtime switch that turns a feature on or off without a redeploy, so code can ship "dark" and be enabled for a fraction of users.

The diagram walks one slice from a laptop to production:

• One-week cycles, Shape Up style — fixed timeline, flexible scope, one integrated slice per cycle.
• Each slice is a vertical feature — frontend, backend, database — owned end to end by one engineer.
• The path is local → Vercel preview → develop → staging → production, every step gated by a feature flag.
• CircleCI ships the backend and Vercel ships the frontend; code always merges to production behind a flag, so there are no stale branches, and the team can ship many times a day.

Behind a flag, "shipped" and "released" come apart: the code is in production but off, so it can be demoed on real infrastructure and then turned on for a small percentage of users before anyone else sees it. For a three-person team, that is how you move fast without breaking a medical product.

• The binding constraint was headcount: a co-founder/CTO plus one engineer in the first 4 months, plus two by month 12, on a pre-seed budget — never more than three people building the product.
• Despite that, the team shipped v1 → v5 of a gigapixel cancer-AI platform within 6/8/12 months, published 5 papers, filed a patent, and raised >$20M by month 18.
• The goal — ship an AI product with a tiny team — is met not by working faster on bespoke code but by making the easy parts a template a junior can copy-paste, freeing seniors for the hard model and backend work.
• The strategy is three paradigms: (1) build the core once, data is just a model (SDUI + workflows as JSON); (2) build AI capabilities once, every job through the same pipeline; (3) keep the infra light, all as code.
• Simplicity is the bar — one renderer, one async pattern, one workflow shape — so a new engineer is productive on day one and every job shares one skeleton, making a new job a copy-paste, not a new architecture.
• Delivery is Shape Up: one-week vertical slices owned end to end, shipped through local → preview → develop → staging → production, always behind a feature flag, many times a day.

• [ ] I can state the team size and budget constraints and explain why they force templates over bespoke code.
• [ ] I can recite the timeline and what shipped: v1 → v5 in 6/8/12 months, 5 papers, 1 patent, >$20M raised at month 18.
• [ ] I can state the goal in one sentence and explain the reframe from "build screens" to "build a system of templates."
• [ ] I can name the three paradigms and give the two-line JSON examples of "data is just a model."
• [ ] I can explain why one renderer / one async pattern / one workflow shape makes a junior productive on day one.
• [ ] I can describe the Shape Up delivery pipeline and what a feature flag lets you do that a plain deploy does not.