Design Sprint vs Just Building: Decide Before Code
When structured design work saves a build, when it delays learning, and which product decisions must happen before code can honestly begin in a real product.
A feature can take two days to code and six weeks to get wrong.
I have seen that gap in small consumer products built with a design partner with a clinical background, and she changes what the product is: in one app, that meant refusing to let a health log act like a doctor; in another, treating a place as more than a map pin; and in a food tracker, putting human review between an estimate and a saved record.
Those calls became the data model, error states, permission prompts and parts we did not build, because a design sprint earns its keep by making an expensive decision early enough that engineering can commit to it, while it wastes money when the decision is cheap, reversible, or unknowable until people use a running product.
Small teams need someone who can decide, a real constraint and a short path to evidence, so the question is which uncertainty you are paying to remove.
A design sprint is only useful if it changes the build
A design sprint aligns people, creates options and tests a prototype, but those are activities rather than a reason to buy one.
Some decisions change every layer of a product, so making them after implementation starts means either keeping the wrong foundation or rebuilding it, while a design process is worthwhile when it settles one well enough to cut work away.
Take a family health log, where a parent enters a child's temperature, symptoms and medicine, because having the app tell them what to do turns a record-keeping product into something much more serious.
The clinical boundary was clear before the first persistence layer: the product records what a caretaker entered and does not calculate doses, validate them, diagnose illness or turn symptoms into advice; a medicine entry stores the medicine name, dose text and an optional parent-set interval, while the reminder says when that interval elapsed rather than that the dose is safe.
That shaped the model around children, illness episodes and dated facts rather than recommendations, so the report is factual history for a clinician rather than a diagnosis-shaped screen, while notifications narrowed and indefensible phone features were ruled out. Discovering this after a week of coding would mean revisiting the flow, collected data and promise to the user.
A sprint earns its cost when Friday produces a sentence specific enough to reject features on Monday: “This product records parent-entered health facts and does not offer medical advice,” whereas “Users value reassurance” tells engineering nothing.
Some decisions are structural, even when the screen is simple
A clean prototype hides structure because it shows the happy path while leaving the expensive questions underneath untouched.
The health log needed an early answer to what an illness is, because a child can have a temperature, symptom, photo, note and medicine entry over several days, and those facts must remain connected while a family can have more than one child and share care.
We chose one active episode per child, and the product records concurrent conditions within that episode without pretending every symptom can be classified neatly; an episode opens, facts are logged against it, it can be resolved, then archived. Nine entities sit underneath the product, including child, episode, log entry, appointment, vaccine and growth records, because without that every log entry is isolated and the doctor report is timestamps.
The child, not a loose collection of records, can be shared, which informed the CloudKit structure: a private store holds owner data, a shared store receives data shared with other caretakers, and the child is the share root.
I would spend a day deciding what is shared, who can see it and which thing is the model boundary, because permissions become relationships, migrations and support problems, and design here is product architecture. Engineering must be involved before a prototype promises what the data model cannot keep, but should not force a model because it is convenient to store - a table is not a product concept.
The map was not the first thing to settle
A travel journal is where just building was partly right: it was private memories connected to their places, and while a photo library knows when a photo was taken and a note holds reflection, neither helps someone return to a trip, city or café months later.
The early constraints were enough: private memories by default, no background location collection, reusable place identity, and a distinction between a city and a visit; the model has a city, travel record, dated visit, place and pin. A pin holds reflection, rating, tags and photos, while a place can be reused within a travel record, and creating a pin finds or builds the place and persists both in one transaction.
Separate coordinates and free-text place names would later require guessing which records refer to the same place and make the map less useful.
The live version showed that maps are full of non-obvious behaviour: a user may refuse location, a browser request can hang, the flow must work in a browser and iOS wrapper, and search can return places outside the city being journalled.
We built a controlled search boundary and learned through the interface: the place provider caches ordinary results for 12 hours, gives a racing request 20 seconds before trying again, and keeps an empty result for 90 seconds. It filters candidates to within 25 km of the selected city and checks the country, while the map requests location only while the app is in use, rounds coordinates to two decimal places and shows no better than 1,000 metres of accuracy.
Those numbers are responses to a running system and external services rather than early-workshop props, because the early decision was privacy and purpose: “We need a map” starts a backlog, while “We will not collect background location” sets a boundary.
A prototype can answer the wrong question very efficiently
I do not trust the pattern where a team shows a polished prototype to five people, hears that they like it and calls the direction validated, because people are generous with prototypes but rarely enter awkward data, wait, pay, deny permission or return after three days. A prototype can test comprehension or choice, yet it is weak evidence for a habit.
The nutrition tracker made this clear: typing food or taking a photo and receiving calories and macros looks convincing in ten minutes, but a prototype cannot tell you whether someone trusts the estimate enough to save it, whether the response is stable enough to render, or what happens when a photograph is ambiguous.
Before code, we decided the result was an estimate for review rather than an answer imposed on the user, and it is saved only when the person chooses. The user can type a description, use a photograph or scan a barcode, but typed and image paths estimate food and portions rather than providing a verified nutrition database.
The backend asks for total calories, protein, carbohydrates and fat, plus named items with their own values, and it uses strict JSON Schema and a low temperature of 0.3 so the client receives a predictable structure for review before it becomes a local food entry.
The design partner could decide review before save, the distinction between estimate and entry, and no clinical claim, while shipping exposed the operational limits: a large photograph is compressed before sending; the iOS path initially targets 1 MiB; the upstream call times out after 25 seconds; the client retries once after two seconds for retryable server failures; callers classified as attested get 100 requests a day and others 10.
A prototype cannot make someone wait 25 seconds in bad signal, show a rate limit or prove item values and meal total useful across a hundred messy descriptions, so asking for review was design work while finding whether analysis was good enough was shipping work. A clickable flow can validate whether a flow makes sense, not an uncertain technical capability pretending to exist.
For the fuller trade-off between a clickable demonstration and a launchable product, I wrote about prototype sprints and MVPs, because they solve different problems and too many teams buy the former when they need the latter.
The right output is a decision log, not a prettier deck
Structured design work should end with a small decision log rather than a fifty-page research report, stating who the first user is, what they are finishing and which action marks success; it should state boundaries that cannot move without a conscious decision, name what is postponed and why, and list questions only a running version can answer.
For the health log, the decision log should record parent-entered records, no diagnostic advice, a child as the sharing boundary, one active episode per child and a doctor report from recorded facts; it should also name the unresolved acceptance test, whether sharing works across two devices and two different Apple IDs. The repository has a deployment checklist for that exact test because a correct model can still fail with real CloudKit accounts.
For the journal, the decision log should record private memories, no background tracking, places that reuse identity within a travel record, and visits distinct from cities, while map-provider edge cases belong in the build; it should not promise offline conflict resolution when web and iOS have one server-side source of truth.
For the food tracker, the decision log should record estimates that are reviewable before saving, barcode data that follows a different path from natural-language analysis, and saved records that remain locally available, while accuracy, cost and retention remain live questions. There is no committed evaluation corpus or production cost telemetry in the work I have seen, so “Validated AI nutrition” in a workshop deck would be false.
A decision log makes the trade visible: if a founder wants shared health history, private travel memories and nutrition estimates that look certain, it exposes the conflicts before an engineer encodes one answer, and it also makes estimates less fictional because MVP cost is largely the cost of decisions left open. I covered that in what actually drives MVP development cost, and a short design phase can lower that cost while a long one can move it from an engineering invoice to a workshop invoice.
Just build when the cost of being wrong is low
Reversible decisions do not need proof first: an empty state, onboarding copy, two field orders, a basic filter, a map-marker style or a first recap; if changing it needs no migration, damaged trust or hard-to-explain reversal, build the narrow version and watch what people do.
Build when the question is local and feedback is short: build a first report, the simplest saved-search view or the camera bridge, because “Just build” is not permission to avoid decisions but a way to discover the ones you cannot know yet.
The health app's WidgetKit extension does not read the main Core Data database: the app publishes a small WidgetSnapshot as JSON into a shared App Group container, replaces it atomically and asks WidgetKit to reload, while the widget reads that limited snapshot rather than the full store. Dose state is a date, not a pre-rendered string, so the timeline can switch from “OK after” to “OK now” at the right moment.
That did not need a sprint; it needed engineering judgement once the safety boundary and need for glanceable status were settled: show a small amount of private, current information without making the widget another source of health interpretation.
Before scheduling a sprint, write the decision that must exist by the end and ask what engineering changes if the answer is A instead of B; if the answer is not much, skip the sprint and build, but if it reaches the data model, permissions, safety claim, pricing logic or every screen, stop and decide it properly.
The work is useful because Monday's code has fewer false assumptions.
I build product work from the decision through to the running system. My CV and day rate are here.