Time, Users, Data
The three quantities that shape a design most — how long you have, how many people will use it, how much data there is and how it grows — and the habit of answering them with a number and a source instead of with "a lot" or "not much".
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
How much time, how many users, how much data — and how do you get honest answers to those three when everyone involved would rather give you an adjective?
You ask the founder how many users the store will have. "Lots, hopefully." How much data? "Not much, it's just products." How long do we have? "As soon as possible." Three questions, three non-answers, and you have to choose a database and a deployment by Friday.
Take the adjectives at face value and design for the flattering version: "lots" of users means design for growth; "not much" data means no need to think about it; "as soon as possible" means cut everything. Each adjective becomes an architecture decision without ever becoming a number.
"Lots" becomes a distributed design for a store that serves tens of orders a day; the first month is spent on infrastructure that a single server would have made unnecessary, and the deadline moves.
- "Lots" becomes a distributed design for a store that serves tens of orders a day; the first month is spent on infrastructure that a single server would have made unnecessary, and the deadline moves.
- "Not much" hides that product images are the largest thing the store holds and that order history grows forever; the database that was "just products" fills with images and the first backup takes hours.
- "As soon as possible" is not a date, so nothing is cut, because nothing is late until something is a date.
- When the estimates turn out wrong there is no record of what they were, so nobody can say the design was made for a different situation — it just looks like a bad design.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Turn each of the three into a number with a source and a range, and treat the range as the constraint. For users: how many at launch and how many if the plan works, from something concrete — an existing mailing list, a comparable business, a marketing budget divided by a plausible cost per customer. For data: which entities are the largest, whether each grows with users or with time, and how much of it must be fast versus merely kept. For time: a date, and what happens if it is missed — because "as soon as possible" is a mood and "the trade show on the fourteenth" is a constraint.
- For each number, ask what changes the design if it is off by an order of magnitude in either direction. If nothing changes, the number does not matter and you can stop refining it. If something changes — a different database, a queue, a second server — then that is a decision the number is making, and it deserves a source and a trigger.
- Design for the low end of the range and write down the trigger for the high end. A store designed for tens of orders a day, with a written plan for what changes at hundreds, is a better design than one built for thousands that will never arrive; the plan costs a paragraph, and the trigger is a measurement, not a guess.
- Convert time into scope explicitly. With a date and a rough sense of what each piece costs, the question "what is V1?" answers itself as "what fits before the date with margin for the unknowns" — and the pieces that do not fit are deferred with the date as the reason (What Is Not V1).
Three adjectives, three numbers
The matrix is the store's three constraints before and after the move. The "what it decides" column is the test: a number that decides nothing is not worth refining, and a number that decides something needs a source and a trigger.
| Constraint | The adjective | The number, range and source | What it decides | Trigger to revisit |
|---|---|---|---|---|
| Users | "Lots, hopefully" | Tens of orders a day at launch (comparable business); hundreds if the campaign works (a hope) | One server, one database; no queue, no cache | Measured traffic at a set fraction of the server's tested capacity |
| Data | "Not much, just products" | Hundreds of products (fixed, small); images (fixed count, large); orders (grow forever, small); carts (grow with users, discardable) | Images in object storage from the start; orders indexed by customer and date; carts with an expiry | Order table size at which the archive question becomes real; measured, not guessed |
| Time | "As soon as possible" | The fourteenth — the trade show; miss it and the founder shows a slide | V1 is what fits with a week of margin: catalog, cart, hosted checkout, admin, deployment; the rest deferred with the date as reason | The date passes, or the margin is consumed by an unknown — then re-scope, in writing |
What the date does to the order of work
A date turns "what should we build?" into "what fits?". The order below is the store's six weeks as a sequence; the reason beside each step is the constraint that put it there. The alternative is what changes when the date is not the hard constraint.
- 1Walking skeleton and deployment, in the first days
because The date is hard, so the thing most likely to eat the margin — getting the layers to connect in a real environment — goes first.
- 2Payment spike against the contracted provider
because The largest unknown and the one imposed technology; a surprise here changes the plan, so it is found while there is time to change the plan.
- 3Catalog and admin, using the framework's scaffolding
because Known technology and a small data set; the fastest path to "the founder can enter products".
- 4Cart, checkout, order — the straight line
because The core workflow; the payment spike already answered the shape, so this is assembly.
- 5The V1 failure branches, in cost order
because Double charge and crash recovery are not optional at a launch with real customers, and the date does not change that.
- 6Legal obligations: deletion path, data location
because Hard constraints that cannot be retrofitted cheaply; scheduled late but not deferrable.
- 7The margin week: the unknowns that appeared
because Something always appears; a plan with no margin is a plan to miss the date.
Low end now, high end on a trigger
The tradeoff matrix scores the two ways of answering "lots of users" — build for it now, or build for the low end with a trigger — across the axes the decision actually moves. The scores are coarse on purpose; the caveat says what they cannot say.
| Option | Simplicity | Time | Cost | Reliability | Maintainability | Note |
|---|---|---|---|---|---|---|
| One server, one database, written trigger for growth | Fits the six weeks and the budget; reliability is one server's reliability plus backups; the trigger has to be watched. | |||||
| Horizontally scaled from the start | Survives the hope; costs most of the six weeks and more than the budget; more pieces to keep working for a load that has not arrived. |
caveat The numbers say nothing about the probability that the campaign works, which is the whole question — and nothing about whether the trigger will actually be watched, which decides whether the first option is prudent or negligent.
How to do it
Most important first.
- For users, find a comparable: a business the founder admires at a similar stage, or their own mailing list. Write "launch: about X a day, from Y; if the plan works: about Z, from W" — and note that Z is a hope.
- For data, list the entities and beside each: grows with users, grows with time, or fixed; large or small per row; must be fast or must be kept. Images, logs and order history are the usual surprises (What Must Persist).
- For time, get a date and the consequence of missing it. Then ask what fraction of the time is already committed to the unknowns you have not sharpened.
- For each number, write the order-of-magnitude question: "if this is ten times more, what changes?" Only the numbers that change something get refined further.
- Put the numbers on the canvas with their sources and a date, and set a measured trigger for each design decision they made (Scale Thought Experiments).
Worked on a concrete problem
The move has to produce something. This is what it produced.
- Users. The founder's "lots" became: the existing mailing list has a few thousand addresses; a comparable business at this stage does tens of orders a day; if the trade-show marketing works, hundreds. Written as a range with both sources. Order-of-magnitude question: at ten times the high end, does anything change? One server still serves it if the pages are not doing anything foolish, so the number decides "one server" and a trigger at a measured fraction of its capacity.
- Data. "Not much, it's just products" became: a few hundred products, fixed, small rows; product images, fixed in count but the largest thing by far; orders, growing with time forever, small rows; carts, growing with users, discardable after a while. The order-of-magnitude question on images: at ten times the count they still do not belong in the database — so they go to object storage from the start, which is the one decision "not much" would have got wrong.
- Time. "As soon as possible" became the fourteenth, because the trade show is where the founder will show the store; missing it means showing a slide instead. Six weeks. Against a rough cost per piece — catalog, cart, checkout with the hosted provider, admin, deployment — the pieces fit with about a week of margin, and the margin is the payment unknowns. Recommendations, coupons and reviews do not fit and are deferred with the date as the reason, in writing.
- On the analytics dashboard, the same three questions produce a different shape. Users: a handful of internal people. Data: events growing with time, fast, and the one thing that matters. Time: no hard date. The data number decides everything — an event store and a retention policy before any chart — and the user number decides nothing; the move is the same and the answers are the design.
How you know it worked
What now exists that did not before, and what question you can now ask.
- Each of the three has a number, a range, a source and a date beside it, and the adjectives are gone.
- For every number you can say what changes if it is ten times larger, and the numbers that change nothing have stopped being discussed.
- The design is built for the low end of each range and carries a written, measured trigger for the high end.
- V1 scope was decided by the date and the rough costs, and the deferred pieces cite the date as the reason.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?How many users at launch and how many if the plan works — from what source, and which of those is a hope?
- ?Which entity is the largest, which grows with users, which grows with time, and which must be fast rather than merely kept?
- ?What is the date, what happens if it is missed, and what fraction of the time is already owed to the unknowns?
- ?If this number is ten times bigger, what changes in the design — and if nothing, why am I still refining it?
What can go wrong
- The numbers become a forecast exercise. A week is spent building a model of user growth for a store that has not launched; the number needed was "tens or thousands?", and it was answerable in an hour.
- Design for the high end "to be safe". The high end is a hope; building for it costs the time the low end needed, and the safety is against a problem that may never exist (Add Complexity Only When Required).
- The date is treated as the only constraint. Scope is cut to fit, but the pieces cut include the deletion path the law required, because the law was not on the list — Budget and Legal Constraints is the other half.
- The numbers are written once and never re-read. The store launches, the traffic is ten times the estimate, and nobody notices the trigger fired because nobody was watching it.
- Pushing for numbers can feel like interrogating a founder about a business they have not started; the sources are often thin and the ranges wide, and that has to be acceptable.
- Designing for the low end means a real chance of rebuilding something if the plan works; the bet is that the rebuild is cheaper than the up-front cost and that the trigger will be seen.
- Converting time into scope makes the deferred list visible early, and someone will read it as "you are not building what I asked for".
- "Get precise numbers." Get the order of magnitude and the source. Tens versus thousands changes the design; fifty versus eighty does not, and precision beyond what changes a decision is fake.
- "The data volume is small so the data model does not matter." Volume is one of three data questions; growth and access pattern are the others, and a small table that grows forever and is queried on every page is where the first performance problem lives.
- "Time constraints mean cut quality." Time constrains scope. A checkout that double-charges is not a smaller checkout, it is a broken one; the date decides which features exist, not whether the ones that exist work.
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- SCALE-SPECIFICAt tens of users a day the user number decides almost nothing and the move is mostly about resisting the high-end design; at the point where a single server's measured capacity is within an order of magnitude of the plausible load, the same number decides the shape of the system and the trigger has to be watched closely.
- STAGE-SPECIFICOn a greenfield project all three numbers are estimates with thin sources; in an existing system they are measurements — current traffic, current table sizes, the actual release cadence — and the move becomes reading the dashboards before asking anyone.
- ILLUSTRATIVEThe mailing list, the trade show, the six weeks and the "tens of orders a day" are invented to show the shape of the answers; no real business is being estimated.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The estimation lab at /thinking/estimate turns "six weeks" into pieces with ranges; the growth lab at /thinking/grow shows what the user number actually does to a single server.