Technology-First Thinking
"I want to build e-commerce" → React, Next, Postgres, Redis, Kafka, Docker, Kubernetes — a reflex, not a plan. Recognise it, understand why it feels like progress, and replace it with Problem → Requirements → Data → Workflows → Scale → Architecture → Technology.
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.
The first thing you did with the new problem was choose a stack, and it felt productive. How do you recognise the technology-first reflex in yourself, and what is the sequence that goes in its place?
Someone says "we want to build e-commerce" and within the hour your notes read: Next.js for the frontend, Postgres for data, Redis for the cart and sessions, Kafka for order events, Docker, Kubernetes for deployment. It looks like an architecture. Nobody has said what an order is.
Name the stack. It is the part of the problem you actually know things about — you have opinions on frameworks and you have none yet on this store — so naming technologies is the only way to feel competent in the first hour. And each name feels like a decision made.
The list contains a solution to every problem except the one you have. Kafka solves event fan-out at scale; Redis solves hot reads and ephemeral state; Kubernetes solves running many services. None of those problems has been shown to exist, so each component is an answer looking for a question.
- The list contains a solution to every problem except the one you have. Kafka solves event fan-out at scale; Redis solves hot reads and ephemeral state; Kubernetes solves running many services. None of those problems has been shown to exist, so each component is an answer looking for a question.
- Every later requirement is bent to fit the stack. The cart lives in Redis because Redis was chosen, so "the cart survives a restart" becomes a persistence question nobody wanted; order events go through Kafka, so a failed payment becomes a consumer-retry question before it was even a requirement.
- The stack sets the unknowns. Instead of "who says an order is paid?", the research list reads "Kafka partitioning", "Kubernetes ingress" — real questions about technologies that may not belong in the store, crowding out the ones that do.
- When the founder asks what V1 will do, the honest answer is the stack. A diagram with seven boxes and no workflows is a picture of infrastructure, and it will look like an architecture to anyone who does not ask what an order is.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Notice the reflex by its signature: technology names appear in your notes before nouns from the problem do. If "Kafka" is written down and "order" is not, the sequence has run backwards. The test is mechanical and worth running on your own notes.
- Understand why it feels like progress, so you can stop trusting the feeling: choosing a technology produces artefacts — a repo, a diagram, a decision — and artefacts look like work. The problem, meanwhile, produces only questions at first, and questions do not look like work. The reflex optimises for how the first hour looks.
- Replace the sequence with one that runs from the problem to the technology: Problem → Requirements → Data → Workflows → Scale → Architecture → Technology. Each stage produces something the next one needs, and technology is last because it is the only stage whose answer depends on all the others.
- Keep the technologies you know as a constraint, not as a starting point. "The team knows Postgres" is a real input at the Technology stage (Known vs Required Technology); it is not a reason to have chosen Postgres before knowing whether the data is relational.
The two sequences, side by side
The reflex is a sequence too — it just runs from the technology towards the problem, and it rarely arrives. Read the worse column as it is actually written in the first hour: a list of capabilities of tools, none of which has yet been shown to be a capability the store needs.
React + Next.js for the frontend. Postgres for data. Redis for the cart and sessions. Kafka for order events. Docker, then Kubernetes for deployment. Then: "so what does an order look like?"
Problem: sell to one-time buyers. Requirements: browse, cart, guest checkout, pay, confirm; never oversell; never double-charge. Data: five relational entities. Workflows: two. Scale: small, one region. Architecture: one app, one database, one external provider. Technology: whatever the team knows that can render, serve and persist — and nothing else yet.
Every item in the problem-first column is derived from the one before it, so each can be defended and each can be changed when the requirement changes. Nothing in the technology-first column can be defended except by reference to other technologies, and nothing in it can be changed without the whole list wobbling.
Problem → Requirements → Data → Workflows → Scale → Architecture → Technology
The replacement sequence, stage by stage, with what each one produces and how the reflex typically hollows it out. Technology is last not because it matters least but because it is the only stage whose answer depends on every other.
- 1Problem
What is being sold, to whom, and what "worked" would look like.
fails by Skipped; "e-commerce" is taken as self-explanatory.
- 2Requirements
What it must do and must never do — functional and non-functional (Functional Requirements).
fails by Only the happy path; "scale" written as a requirement without a number or a reason.
- 3Data
The entities, their relationships, what must persist, what is a snapshot (Data Discovery).
fails by A database chosen before the shape of the data is known.
- 4Workflows
The sequences of actions that cross entities: checkout, refund, restock.
fails by Assumed from the tutorial's workflows.
- 5Scale
Honest expected users, data volume and growth, and the evidence for each (Time, Users, Data).
fails by Invented to justify the component already wanted.
- 6Architecture
How many deployable things, which boundaries, which external systems — the fewest that meet the above (Architecture From Requirements).
fails by Copied from a conference talk about a system with different requirements.
- 7Technology
Concrete choices, each paired with the requirement it serves and the simpler thing it beat.
fails by Done first, and the other six stages back-filled to agree.
The stages are dependencies, not phases. On a familiar problem the whole sequence runs in one sitting; what matters is that Technology is filled in last.
What each reflex component would have cost
The reflex list was not random — each item solves a real problem somewhere. The table says what problem, what evidence would show the store has it, and what the component costs when the problem is absent. That last column is the one the reflex never fills in.
| Trigger | Symptom | Cause | Response |
|---|---|---|---|
| Redis for the cart | Carts vanish on a restart, or a second persistence path is added to stop them vanishing. | The cart must survive a restart and belongs to a session; it is durable state, and it was put in a store built for ephemeral state. | A cart table. Revisit if a measured read bottleneck on carts ever appears (Source of Truth). |
| Kafka for order events | A failed email becomes a consumer-retry and offset-management problem before there is a second consumer. | One consumer, small volume; the component solves fan-out at scale, and there is no fan-out. | A job table or a direct call. Revisit when there are several independent consumers that must not block checkout (Message Queues). |
| Kubernetes | Days on ingress, secrets and manifests for one service that could run on one machine. | The component orchestrates many services; there is one. | One process on one host with a restart policy. Revisit when there are several services with different scaling needs (From a Simple App to a Scaled System). |
| Postgres | None — but it was chosen before the data was known. | The right answer for the wrong reason: relational data and a team that knows it, discovered after the choice. | Keep it, and write down why, so the reason is the data and not the reflex. |
How to do it
Most important first.
- Run the signature test on your notes: circle every technology name and every problem noun. If the technologies came first, cross them out and start again from the nouns.
- Write the seven stages as headings and fill them in order; leave Technology blank until Architecture has content. The blank is the point — it is where the reflex wants to write first.
- For every technology you are tempted to name, write the problem it solves in one sentence, and then ask whether that problem has been shown to exist here (What Problem Does It Solve?). "Kafka: reliable fan-out of events to many consumers at high volume" — how many consumers does the store have?
- When you cannot resist, write the technology on a separate list called "candidates, pending a reason" rather than in the design. The list is allowed; its position in the sequence is what changes.
- Ask what the simplest technology that meets the stated requirements would be, and let the burden of proof sit on anything more complex (Add Complexity Only When Required).
Worked on a concrete problem
The move has to produce something. This is what it produced.
- The store, sequenced properly. Problem: sell products online to one-time buyers. Requirements: browse, cart, guest checkout, pay, confirm; never oversell; never charge twice. Data: Product, Cart, Order, OrderItem, Payment — relational, small. Workflows: browse → cart → checkout → paid; admin creates products. Scale: unknown, assume small; a single region. Architecture: one web application, one relational database, one external payment provider. Technology: any web framework the team knows; Postgres because the data is relational and the team knows it; no Redis, no Kafka, no Kubernetes — none has a problem to solve yet.
- The reflex list, audited. Redis "for the cart": the cart must survive a restart and belongs to a session, so it is a table, and the ephemeral-store argument does not hold. Kafka "for order events": there is one consumer of order events, the email sender, and it can be a function call or a job table. Kubernetes: there is one service. Each item was a solution to a problem the store did not have; each would have added an operational surface and a set of failure modes (The Complexity Ledger).
- The case where the reflex was half right. The analytics dashboard: "we need ClickHouse" was written before the requirements. Sequenced properly, the requirements turned out to include ad hoc queries over years of events with sub-interactive latency, and the data was append-only and wide. That is the problem a columnar store exists for. The technology was right; the reflex still got there for the wrong reason, and the sequence is what makes the choice defensible instead of lucky.
How you know it worked
What now exists that did not before, and what question you can now ask.
- Problem nouns appear in your notes before technology names do, and the Technology heading is the last one filled in.
- Every technology in the design can be paired with a requirement it serves and a simpler alternative it beat, in one sentence each.
- The stack has become boring: several choices would work, and you can say which constraint would tip it.
- Someone asks "why not Kafka?" and the answer is about the store — one consumer, small volume — not about Kafka.
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.
- ?Did a technology name appear in my notes before a noun from the problem did?
- ?For each technology I have written down, what problem does it solve — and has that problem been shown to exist here?
- ?What is the simplest technology that meets the requirements as stated, and what would have to be true for something more complex to be justified?
- ?Which of these choices is a constraint I actually have — team knowledge, an existing system — and which is a preference dressed as one?
What can go wrong
- The reflex is over-corrected into technology avoidance: no decision is made until every stage is complete, and a store whose data is obviously relational spends a week not saying "Postgres". The sequence orders the decisions; it does not forbid the obvious ones.
- The sequence is followed on paper and the technology was chosen anyway. "Scale" gets filled in with "millions of users" to justify the Kafka that was already wanted. The stages have to be filled honestly, with evidence, or they are decoration.
- Known technology is treated as a bias to be purged rather than a constraint to be counted. A team that knows Postgres deeply should usually use Postgres; the mistake is choosing it before the data is known, not choosing it at all.
- The move is applied to a well-understood problem. Someone building their fourth store with the same team does not need to rediscover that the data is relational; the sequence has been run before and the answer carries.
- Running the sequence delays the moment a repository exists, and that moment is what stakeholders — and you — use as evidence that the project has started.
- A stack chosen from the problem may be one the team knows less well than the one the reflex would have picked; sometimes the reflex's answer wins at the Technology stage for exactly that reason, and the sequence just took longer to get there.
- Writing "no Kafka" down in a design invites the argument with whoever wanted it. The reflex avoids the argument by never making the decision visible.
- "Technology-first thinking means the stack is always wrong." The stack is often fine; the analytics dashboard shows a reflex landing on the right answer. What is wrong is the order, because the order is what makes the choice defensible and changeable.
- "So never mention a technology until the end." Candidates are fine at any point, as long as they sit on a list labelled pending and not in the design. Suppressing them entirely just makes them come back as assumptions.
- "The seven-stage sequence is the method." It is the antidote to one specific reflex. On a problem you already understand, most of the stages are filled in from memory in a minute, and that is the sequence working, not being skipped.
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.
- GENERALThe signature — technology names before problem nouns — identifies the reflex on any problem; what the right technology turns out to be is domain-specific, and the sequence is how you find out.
- STAGE-SPECIFICOn a greenfield store the sequence runs in full; in an existing system the Technology stage is mostly answered by what is already running, and the move narrows to "does the new requirement justify a new component, or does the existing stack carry it?"
- ILLUSTRATIVEThe seven-item stack list, the store and the dashboard are invented for the shape of the argument; the reflex is real and the specific technologies are stand-ins for whichever ones are fashionable this year.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The technology decision tool at /thinking/decide asks which problem you are solving before it lets you pick Redis, Kafka or Kubernetes; use it on the reflex list.