Final architecture from day one, a lean implementation to start
You don't have to choose between building fast and building right. Draw the system's boundaries correctly from the start, put the simplest implementation behind each one, and grow later without a rewrite.
Two voices show up at the start of every product. One says "let's build fast and fix it later." The other says "we have to design for scale from the beginning." Heard alone, each is expensive. The first ends in a rewrite; the second in a product that never ships.
My working principle is a third way: final architecture from day one, a lean implementation to start.
What the principle means
Architecture is about boundaries: which part is responsible for what, and how parts talk to each other. Implementation is whatever sits behind a boundary.
Changing a boundary is expensive, because everything leans on it. Changing the implementation behind a boundary is cheap, because the rest of the system doesn't know about it.
So what has to be right from day one is the boundaries, not the volume of code.
A simple example: notifications
Suppose the product must alert the owner when an order comes in. In version one, a log line may be enough. Later comes SMS, then email, then a messenger.
If the ordering code calls the SMS service directly, every change means editing core logic. If instead there is a small contract such as notifyNewOrder(order), the core only knows that contract. Behind it sits one log line today and three channels tomorrow.
This site works that way: the contact form only knows a "notifier", and where the message goes is decided by configuration, not code. The pattern is described in swappable layers.
What must be right from day one
- Module boundaries. Clear responsibility, clear interface.
- The core data model. Key entities and their relationships; changing them later means migrating data.
- The edge to external services. Payments, SMS, AI and storage behind their own layers.
- Identity and access. Adding security to a system designed without it is a rewrite. See security from day one.
- The deployment path. Releases must be repeatable from the start.
What can start simple
- A lightweight database instead of a distributed cluster.
- One server instead of ten services.
- Manual work behind the scenes instead of full automation.
- One payment method, one language, one channel.
None of these is technical debt, as long as it sits behind the right boundary. Technical debt appears when the shortcut damages the boundaries too.
Why it matters to the client
The principle has a direct commercial result: version one arrives early, and what you paid for it isn't thrown away in version two. A product that runs today can still grow years from now.
The decisions made along the way should be written down so they can be defended later. The tool for that is the architecture decision record.
The takeaway
Speed and quality are not enemies. What reconciles them is knowing which parts must be right from the start and which can begin simple. Stable boundaries, light implementation.
If you need a precise blueprint before the build starts, see architecture and technical planning.