A founder once asked me whether they should build their application on a monolithic architecture or microservices. They had four engineers and zero paying customers.
This is a question I get regularly, and the honest answer is: that is not the right question. The right question is: what is the consequence of choosing wrong, and how easily can you change course?
Technical decisions vary enormously in their reversibility. Some decisions can be changed in an afternoon. Others take six months to unwind. Building a framework that matches the rigor of your decision to its actual consequence saves enormous time and energy on low-stakes decisions while ensuring enough deliberation on the ones that matter.
The Reversibility Test
The single most useful filter for technical decision-making is: how reversible is this?
Highly reversible decisions deserve less deliberation. Which monitoring tool to use. Which internal code style conventions to follow. Whether to use React or Vue for the internal admin dashboard. Whether to name a database table `users` or `accounts`. These decisions have consequences, but the consequences are manageable and changeable. Spending a week on a decision that can be undone in a day is a misallocation of engineering attention.
Partially reversible decisions deserve moderate deliberation. Which cloud provider to use. Which primary programming language to use. Which ORM or data access pattern to use. These are harder to change but not impossible. Switching is painful and time-consuming but does not require starting over.
Essentially irreversible decisions deserve significant deliberation. Your primary data model, especially in the early product stages before you have real usage data. Your multi-tenancy strategy if you have multiple customer segments with different isolation requirements. Your core API design, once external developers have built on it. Your cryptographic key management approach once you have encrypted data in production. These decisions are very expensive to change, and the cost of getting them wrong is high.
The framework: calibrate your deliberation time to the reversibility of the decision. Do not spend two weeks on a decision that can be undone in an afternoon. Do not spend two hours on a decision that will take six months to unwind.
When to Move Fast and When to Slow Down
"Move fast and break things" is a philosophy that makes sense applied selectively and breaks down applied universally. The question is which things it is okay to break.
It is okay to move fast on:
Features that do not touch core infrastructure. A new reporting dashboard, a UI redesign, a new notification type - these can ship quickly, fail fast, and be iterated on without systemic risk.
Internal tooling. Internal admin tools, developer tooling, monitoring dashboards - the users are your own team, the consequence of a bug is internal friction, and the iteration cycle is fast.
Experiments with explicit revert paths. If you are testing a new feature behind a feature flag and can turn it off immediately if it causes problems, moving fast is low-risk.
It is okay to slow down on:
Database schema changes that affect existing data. Schema migrations that modify existing columns, rename tables, or change data types on tables with production data require careful design and testing. A failed migration at 2 AM is an incident.
Security-related changes. Authentication, authorization, encryption, and credential management changes deserve extra review. The consequence of a bug here is not a user experience problem - it is a security incident.
External API changes. Once external consumers are using your API, changes need to be backward compatible or managed through versioning. Breaking an external API is not a bug - it is breaking your customers' integrations.
Compliance-affecting decisions. In regulated industries, decisions that affect HIPAA scope, PCI compliance posture, or other regulatory obligations need to be made with awareness of the compliance implications.
The Information Threshold Question
One of the most common traps in technical decision-making is waiting for more information before making a decision, when the information you are waiting for is not available and will not be.
The question I ask: what additional information would meaningfully change this decision, and can I get it?
If the answer is "I would make a different decision if I knew the usage pattern, and I can learn the usage pattern by running a small experiment" - run the experiment, get the information, make the decision.
If the answer is "I would make a different decision if I knew the scale requirements, but I will not know that until I have customers" - make a reasonable bet for the most likely scenario, design for changeability in the areas of highest uncertainty, and plan to revisit when you have real data.
If the answer is "I would make a different decision if I had perfect knowledge of the future" - make the best decision you can with current information and move on. No amount of deliberation converts uncertainty into certainty.
The practical application: I often see teams stuck on a technical decision not because the decision is hard, but because they are waiting for a clarity that is not available. The cost of the indecision accumulates while they wait. Making a good-enough decision and starting to learn is almost always better than waiting for certainty that will not come.
Disagree and Commit
In technical teams, consensus is often mistaken for quality. Teams where everyone must agree before moving forward on a technical decision either make decisions very slowly or converge on mediocre decisions to avoid conflict.
The disagree-and-commit principle is a practical alternative: the decision-maker (the CTO, the tech lead, whoever has the relevant authority) makes the call after hearing the perspectives of people with relevant expertise. People who disagree with the decision commit to executing it as if they agreed. The decision-maker is accountable for the outcome.
This requires two things to work. The decision-maker must actually listen to dissenting views and genuinely consider them - not just collect opinions for appearances. And the people who disagree must actually commit - not sabotage the decision they did not prefer or adopt an "I told you so" posture if it does not work out.
When I make a technical call that I know has reasonable disagreement, I say so explicitly: "I know some of us see this differently. Here is my reasoning, and here is the condition under which I would reconsider. For now, we are doing it this way." The explicit acknowledgment of the disagreement, and the stated condition for revisiting, makes the commitment more durable.
The Decision Log
One of the most useful practices I have introduced in technical teams is a lightweight decision log - a record of significant technical decisions with their rationale, the alternatives considered, and the expected outcome.
The purpose is not bureaucracy. The purpose is context. When a decision made eight months ago seems wrong in hindsight, you want to know: what information did we have at the time? What alternatives did we consider? Why did we decide the way we did? The decision log answers these questions without relying on anyone's memory.
The format I use is simple: the decision, the date, the alternatives considered, the factors that drove the decision, the expected outcome, and who made it. One paragraph per decision. The whole thing lives in a markdown file in the repository.
Teams with a decision log recover from "why did we build it this way?" conversations much faster than teams without one. The answer is in the file.
The One Decision That Is Always Hard
After 15 years and 200+ projects, there is one category of decision that I have never found a clean framework for: when to cut scope vs. when to hold the line.
The team has promised Feature A and Feature B for a release. Partway through the cycle, it becomes clear that both will not fit. Something has to give. What gets cut?
The framework I use: cut what is easiest to add later, not what is hardest to build now. The thing that is hardest to build now is hard to build later too. The thing that is not yet a customer commitment, does not have dependencies in other work, and can be shipped in a subsequent release is the right thing to defer.
This sounds obvious. In practice, the pressure to cut what is hard (because the team is tired of it) or to cut what is small (because the math looks right) often wins out over what is strategically right to defer.
The decision is made by whoever can see both the customer commitment and the engineering reality at the same time. That is usually the CTO or the fractional CTO. It is the decision where the business-technology translation matters most.
Book a 30-minute call: https://calendly.com/alpsf/zoom-with-aleksandr