Tradeoffs and the Throughline
The capstone of the Orca case study: the engineering judgment behind every choice, and the one idea that ties them all together.
Judgment shows up in what you give up
Every architectural decision buys one property by selling another, and the engineer's job is to name what was sold — not to pretend the choice was free. This capstone does two things: it lays out the tradeoffs the Orca platform made and would defend, and it names the single throughline underneath all of them.
None of the earlier choices was free. Storage-first crash-safety cost synchronous simplicity; the generic renderer cost up-front complexity; the honest compliance posture cost the comfort of claiming a certificate. Good judgment is visible precisely in what a design is willing to give up, and at what price.
Tradeoffs worth defending
Here are the five decisions worth defending, each framed as a trade: what was given up, and why the trade was right at Orca's stage and budget. (Glossary: "storage-first" means writing each step's state to the database before running it; a monolith is one deployable service rather than many; a webhook is a real-time push callback, versus polling which asks on a schedule.)
| Decision | What was given up | Why it was right |
|---|---|---|
| Storage-first async engine | Simplicity of a synchronous call | Survives crashes; resume-from-last-step saves expensive GPU reruns |
| Generic SDUI renderer | Up-front renderer complexity | One render path forever beats N bespoke screens |
| Monolith core + a few services | Pure microservice independence | Extract only when a service earns its own lifecycle |
| VPC-isolated ISO stage | Environment sprawl | Clean network isolation for the regulated workload |
| Poll-based lab results | Real-time webhooks | Simpler, more robust integration for external labs |
Storage-first introduced eventual consistency but bought crash-safety and cheap resumption of expensive GPU work. The generic renderer was more work than one screen — but far less than the fiftieth screen. The monolith stayed a monolith until a service genuinely earned its own lifecycle. Every row is a trade made on purpose, at a known cost.
The throughline — build so the team can bend it without you
Underneath every decision is one idea: build the system as a template the team can bend without the person who built it. The senior engineer should never be the bottleneck standing between a field request and a shipped change.
Three mechanisms make that real. Feature flags let every change reach production hidden, then switch on for a percentage of users. SDUI — server-driven UI, where the screen is described by JSON the backend sends rather than hard-coded on the client — turns a new screen into a JSON edit. Workflows-as-JSON turn a new pipeline into an ordered list of steps in the database. Together they turn what the field asks for into configuration, not new architecture. Put the right compute in the right place, keep cost and compliance as code, and a small team on a real startup budget can move fast without the founder in the loop.
How the field's requests become configuration
The test of the throughline is what happens when a real request lands from a real user. On Orca, requirements came from watching people work, not from a backlog — and the architecture let each request land as configuration.
Three concrete cases. A lab's stain color threw off the model, so color normalization was inserted ahead of inference for that lab only — a new step in a JSON blueprint, no code change, no redeploy. Pathologists work on tablets with a stylus, so the input engine responds to pressure, tilt, and the device's refresh rate. Hospital wifi drops, so annotation operations are atomic and independently executable over REST — a save is never lost. The unifying idea is that the design turned each field request into config rather than a new build.
The engineering principles this platform demonstrates
Step back from the parts, and the platform demonstrates a consistent set of engineering principles. Each one is visible in something concrete that was actually built — not a claim, but a place in the system you can point at.
| Principle | Where the platform shows it |
|---|---|
| Requirements found by watching real use | Gigapixel on tablets, flaky networks, per-lab preprocessing — all came from the field, not a backlog |
| Ships fast in a regulated environment | Clinical-grade constraints, shipping to production daily behind feature flags |
| Simple, configurable solutions | Feature flags, SDUI, and workflows-as-JSON let users iterate without a redeploy |
| Connects engineering, product, and the user | Translates ambiguous field needs into shipped systems, end to end |
| Technical depth with taste | Storage-first workflow engine, QuadTree pyramidal viewer, compliance-by-architecture |
| Built so others can run it without the author | Repeatable templates a small team ships from — freeing seniors for the hard model and backend work |
The principle to underline is the last: the whole system was built as templates a small team could copy-paste — a section JSON, a registered component, a workflow step — precisely so the person who built it was not the bottleneck, and could spend time where the work was genuinely hard: the AI models and the backend.
The close
The best system is one the people around you — your own team, and the users you build for — can bend without you. Orca is the proof: feature flags, SDUI, and workflows-as-JSON turn field requests into config; the right compute sits in the right place; and cost and compliance are enforced as code — all on a real startup budget.
And the compliance program is honestly a program in mid-flight, sequenced on purpose, not a certificate. Naming what is not yet done is part of the same judgment as defending what is. That is the throughline of the entire case study: a platform built so the people around it can move without the person who built it.
Key takeaways
- Every architecture trades one property for another; the engineer's job is to name what was sold, not to pretend a choice was free.
- Five tradeoffs worth defending: storage-first async (gave up sync simplicity, bought crash-safety and cheap GPU resume), generic SDUI renderer (up-front complexity, one render path beats N screens), monolith + a few services (pure microservices, extract only when earned), VPC-isolated ISO stage (env sprawl, clean isolation), poll-based lab results (real-time webhooks, simpler robust integration).
- The throughline: build the system as a template the team can bend without the person who built it — the senior is never the bottleneck between a field request and a shipped change.
- Three mechanisms turn field requests into configuration: feature flags, SDUI (screens as JSON), and workflows-as-JSON (pipelines as ordered steps).
- The architecture proved it in the field: a per-lab color-normalization step added as JSON, a pressure/tilt/refresh-aware tablet input engine, and atomic REST annotation ops for flaky networks.
- The platform demonstrates six engineering principles — requirements from real use, shipping fast in a regulated environment, simple configurable solutions, bridging engineering/product/user, technical depth with taste, and building so others run it without the author.
- Judgment includes honesty about what is not done: the compliance program is mid-flight and sequenced on purpose, not a certificate.
Checklist
- [ ] I can explain why "no architecture is free" and give the tradeoff on at least three Orca decisions.
- [ ] I can reproduce the tradeoffs table: decision, what was given up, why it was right.
- [ ] I can state the throughline in one sentence and explain why it keeps the senior out of the critical path.
- [ ] I can name the three mechanisms (feature flags, SDUI, workflows-as-JSON) that turn field requests into configuration.
- [ ] I can give the three field-to-config cases: per-lab color normalization, the tablet input engine, and atomic REST annotation ops.
- [ ] I can list the six engineering principles the platform demonstrates and point to where each shows up.
- [ ] I understand why naming what is not yet done (mid-flight compliance) is part of engineering judgment.