You built the MVP, and customers started using it. Revenue began to grow, and now engineering feels different. A feature that once took three days takes two weeks. Small changes create unexpected problems, and releases feel stressful. Engineers spend more time fixing old issues than building new things, and your infrastructure bill is growing. Someone says the architecture needs a rewrite, another one says you need more developers, another person recommends a new database, a different cloud setup, or a more sophisticated architecture - and you are left thinking: “What is actually wrong and what should we fix next?” This is where many post-MVP startups make an expensive mistake. They start treating engineering itself as the problem. The result is often a technical improvement project that produces more work, higher costs, and greater complexity without necessarily removing the constraint slowing the business.
It’s always a great idea to check on what’s preventing the business from moving as quickly, safely, and economically as it should, and how much of that problem is actually caused by engineering. That distinction matters, because a startup can have messy code and still grow rapidly, a simple architecture and still be perfectly capable of supporting the next stage of business, and/or even technical debt that is completely rational to leave alone. At the same time, a technically sophisticated startup can have an engineering system that quietly limits delivery, reliability, customer growth, or business flexibility.
So, the objective of a technical audit should be to understand engineering reality in the context of the business. That means answering: What’s working? What’s actually constraining growth? What evidence supports that conclusion? What’s the business impact? What should we fix now? What should we prepare for? What should we monitor? What should we deliberately leave alone? Where will engineering investment create the greatest leverage?
A technical audit should produce decisions, not just findings.
A conventional technical audit can become a long list, and the report might contain architectural weaknesses, technical debt, infrastructure concerns, missing tests, documentation gaps, security issues, performance concerns, deployment problems, and scalability risks. All of those findings may be true, but there is a problem: A list of technical problems is not the same thing as a useful business decision. Founders need to know which three matter.
Consider the difference between "The application has limited automated test coverage." versus "Low automated test coverage is contributing to repeated regression issues in the checkout flow, increasing release rework and delaying product changes." The first is a technical observation. The second is a business-relevant finding. That is the standard an effective assessment should meet. A useful technical finding should move through a chain: Evidence → Symptom → Constraint → Root Cause → Business Impact → Intervention → Expected Outcome. This forces an uncomfortable but valuable question on whether the technical problem actually matters to the business. If the answer is unclear, the finding may not deserve priority.
Start with the business, not the technology.
Before looking at architecture, infrastructure, or code, understand what the business is trying to do next. What matters over the next 6 to 18 months? Perhaps the company wants to double its customer base, enter a new market, sign larger enterprise customers, increase transaction volume, launch a major product capability, reduce operating costs, grow the engineering team, improve delivery speed, and/or meet new security or compliance requirements. Those goals change what "good engineering" means, and so it’s important to consider:
- A system that is perfectly adequate for 10,000 customers may require different capabilities for 100,000 customers.
- An architecture appropriate for a small SaaS may become a constraint as enterprise integrations increase.
- A deployment process that’s acceptable for one release every two weeks may be a problem when the product requires rapid experimentation.
This is why there is no universally correct level of engineering maturity. Architecture decisions involve trade-offs between factors such as operational excellence, security, reliability, performance, cost, and other business requirements. The right balance depends on the workload and its context. If you can correctly determine what the business is asking the engineering system to support, then you can reasonably ask whether the engineering system is ready.
Step 1: Find the constraint
Find out what is currently preventing the business from moving as quickly, safely, or economically as it should. It might be an engineering problem, or not. Possible constraints could be product decision-making, engineering delivery, software architecture, operational reliability, infrastructure economics, customer feedback loops, technical ownership, process, and/or security or compliance.
It would be easy to conclude that "the team needs more developers" in a startup where features are taking too long; investigation might reveal that developers spend much of their time waiting for product decisions, resolving unclear requirements, fixing regressions, performing manual releases, and/or handling production incidents. DORA's current software delivery guidance explicitly recommends identifying the significant constraint or bottleneck in the delivery process, improving it, and then measuring the effect rather than treating metrics as targets in isolation. That principle is much broader than DevOps.
Find the constraint first, then decide what engineering intervention is justified.
Step 2: Assess engineering confidence dimensions
Once the business context and current constraints are understood, the engineering environment can be evaluated through five lenses:
- Delivery confidence
- System confidence
- Operational confidence
- Economic confidence
- Decision confidence
These are five ways of investigating whether engineering is helping or constraining the business.
1. Delivery confidence
Focus on whether you can reliably turn business priorities into production changes. Suppose a founder says that they need a customer-facing feature this month, then the team agrees. Two weeks pass, and the feature is still incomplete. Then another release causes an unrelated problem. An engineer then investigates, and a different developer has to stop planned work to help. Then launch slips again. Understand the delivery system by looking at change lead time, deployment frequency, failed deployments, recovery time, deployment rework, testing, code review, release processes, handoffs, dependencies, and recurring bottlenecks.
DORA's current guidance uses five software delivery performance metrics to understand throughput and instability, and recommends using them as a basis for understanding friction and improving the most significant constraint. The purpose is not to chase a particular metric. It is to understand what the delivery system is telling you. For example:
- Long lead time may indicate excessive handoffs, large batches, review bottlenecks, testing delays, or unclear requirements.
- Frequent deployment failures may indicate weak testing, risky changes, environment differences, or fragile release processes.
- Heavy deployment rework may indicate that engineering capacity is being consumed by correcting previous changes rather than creating new value.
The business question is whether the engineering system can reliably convert business priorities into customer value.
You need to look at actual delivery evidence from recent work, identify where time accumulates, then find out the largest recurring constraint. Fix that before launching a broad "engineering productivity" initiative.
2. System confidence
Can your software support the business and the growth that’s coming? This is where architecture discussions become dangerous. When people have different opinions, like the architecture is terrible, upgrade to microsystems, and/or rewrite the whole system - that’s how the discussion quickly becomes about technical preference. That’s the wrong level of conversation. The argument should be about the business constraint that the current system is creating, or likely to create at a growth level that’s reasonably anticipated. Examine the architecture, data design, performance, scalability, dependencies, integrations, system boundaries, coupling, failure modes, and/or capacity constraints.
Consider a simple system: User → Web App (serves the customer) → API (moves requests between the application and backend) → Business Logic (enforces the product's rules) → Database (stores important business information) → External Service (provides capabilities such as payments, email, messaging, and/or authentication). Each component exists to support some business capability. A weakness in one area, for instance, a slow database that creates slower customer requests, a fragile integration that makes releases risky, and a tightly coupled component that makes a seemingly small product change expensive, can eventually affect the business. That does not mean the system must be redesigned immediately. Architecture is about trade-offs.
AWS explicitly recommends evaluating architecture decisions in terms of their benefits, risks, customer impact, efficiency, and business requirements rather than assuming that every potential performance or architectural improvement should be implemented.
A startup may need elaborate distributed systems, multiple specialized databases, complex deployment infrastructure, globally distributed services, and sophisticated orchestration tomorrow, not today. More infrastructure creates more things to operate, more components create more failure points, and more architecture creates more decisions. Complexity should therefore have to earn its place. It’s about if the architecture is sufficient for the business and the growth expected, not whether the architecture is sophisticated enough.
For every significant architectural concern, establish what is hurting today, what business or technical condition will become important, what fixing it requires, and what happens if change is postponed. That gives a rational modernization decision.
3. Operational confidence
Every production system eventually experiences failure. The important question is how much business damage failure creates, and how quickly it can recover, not whether failure can be eliminated.
Consider two companies experiencing the same outage. In company A, nobody notices for 45 minutes, then a customer reports the problem, and the team begins investigating. Logs are incomplete, and the engineer who understands the affected component is unavailable, so the recovery takes several hours. In company B, an alert fires, and the responsible team sees which component is affected. Recent changes are visible, and the problematic change is rolled back, so recovery is completed quickly. The technical failure was similar; the business risk was not. That's operational confidence.
Examine monitoring, alerting, logs, observability, backups, recovery procedures, rollback capability, incident response, operational ownership, and documentation. AWS's reliability and operational-excellence guidance emphasizes understanding how systems behave in operation, monitoring them, preparing for failure, and continuously improving operational processes.
Ask yourself or your team these questions: If the main application went down tonight, who would know first? How would the team understand what failed? How would the business limit the impact? How would the system be restored? When was the recovery process last tested? The last question is particularly important, because a theoretical recovery procedure creates less confidence than a recovery process that has actually been exercised.
Take the most important failure scenarios and map: Detection → Diagnosis → Containment → Recovery → Prevention. You need an appropriate level of resilience for the consequences of failure, not a perfect resilience everywhere.
4. Economic confidence
Spend engineering resources where they create the greatest business value since engineering isn’t free. The obvious costs include salaries, contractors, infrastructure, and software services, etc. The hidden costs can be larger as engineering also consumes time, attention, management capacity, opportunity, customer goodwill, and operational capacity.
Suppose an engineer spends two days a month dealing with the same manual process. Over a year, that becomes significant recurring effort. Or suppose the team spends months rewriting an architecture that was already adequate. The infrastructure might improve, but what other work could have been completed during that time? That's opportunity cost.
Sometimes spending more can be the rational choice when it improves speed or business value, while over-optimizing for cost can itself become expensive. It’s about allocating engineering resources where the return justifies the investment.
How much meaningful business value can you create from a given amount of engineering effort, capital, and risk?
- A feature can create leverage by increasing customer value.
- A refactor can create leverage by reducing the effort required for future changes.
- Automation can create leverage by removing recurring work.
- Observability can create leverage by shortening recovery time.
- Documentation can create leverage by reducing dependence on one engineer.
- Testing can create leverage by making changes safer.
- A simpler architecture can create leverage by reducing operational burden.
Leverage should not remain an abstract idea. For each major proposed investment, consider what customer or business outcome could be improved, what meaningful business risk is removed, what recurring engineering effort disappears, what becomes possible afterwards, what costs are, and what the team will not be able to do while this work is happening. You need disciplined comparison.
5. Decision confidence
Having enough evidence to know what should happen next may be the least visible engineering risk. A startup can have talented engineers and still make poor technical decisions because perhaps nobody fully understands the architecture; product and engineering teams disagree about priorities; the team has no useful delivery data; the founder receives three conflicting recommendations; or everyone agrees that technical debt exists, but nobody knows which debt is expensive. The problem is not simply technical; it’s decision uncertainty. It’s therefore important to examine architecture understanding, technical ownership, documentation, product-engineering alignment, customer feedback, engineering metrics, known risks, assumptions, and decision history.
DORA's recent research continues to emphasize the importance of the broader organizational system rather than treating technology tools in isolation. Its 2025 research, for example, describes AI as an amplifier of existing organizational strengths and weaknesses rather than a substitute for strong underlying capabilities. Tools do not remove organizational uncertainty; evidence does.
Consider separating facts like a significantly known increase in checkout latency and an observed slow request passing through one service from assumptions like customer traffic will double within 12 months, and whether the current infrastructure can support that level of traffic. That distinction is powerful. For each important conclusion, classify the evidence as high-confidence (multiple reliable sources support the conclusion), moderate confidence (evidence exists, but some uncertainty remains), low confidence (the conclusion is plausible but needs validation), or unknown (not enough evidence to make a responsible recommendation). This prevents a technical opinion from masquerading as a fact.
It’s important to check if you are building the right things because engineering can execute perfectly on the wrong priorities. A highly efficient engineering team can still destroy value if it spends six months delivering features customers do not need. It’s why engineering and product cannot be assessed separately. Look at customer feedback, feature adoption, product usage, customer pain, roadmap assumptions, experiment results, business priorities, and product-engineering alignment. This acknowledges that engineering efficiency has little value if the output has little value.
Security and compliance should be risk lenses.
Security deserves attention in almost every serious engineering effort, so treat security, privacy, compliance, and resilience as cross-cutting risk lenses. For example, a weak authentication system affects system confidence; poor access controls affect operational and security risk; missing audit trails may affect enterprise sales and compliance; and inadequate data protection may affect customer trust and market access. Always assess the issue in accordance with the business consequence. There are cases where security and compliance risks should override ordinary cost or speed trade-offs. Some concerns, such as security and operational excellence, are generally not treated as ordinary trade-offs against the other architectural considerations. Identify where these risks are material to the business and elevate them accordingly.
The cost of waiting matters as much as the cost of fixing
Engineering prioritization becomes much clearer when you compare the cost of acting versus the cost of waiting. Suppose a migration requires four months of engineering effort, but the current architecture is unlikely to become a constraint for another two years - immediate migration may be irrational. Say, the current architecture already makes every major product change risky and causes repeated outages - waiting may be more expensive than acting. This is why technical priority cannot be determined by severity alone. Consider the value of a change alongside probability, consequences, cost, and business priorities.
Every meaningful finding should lead to one of four outcomes: to fix now (the business consequence is material and the intervention is justified), prepare (the problem is not sufficiently painful today, but evidence suggests preparation should begin), monitor (the risk is real but currently low, uncertain, or uneconomical to address), or do not act (the issue exists, but its current and foreseeable business impact does not justify intervention). The fourth category is important because a strong engineering partner should be comfortable recommending it. That can be high-value.
Engineering readiness is contextual.
Engineering health is not the same as engineering readiness. A startup may have a messy system that is perfectly ready for its current stage. Another startup may have a relatively healthy system that’s not ready for the next business event. For example, a system works well today, but the company is preparing to sign a large enterprise customer that requires stronger reliability and security. The question is whether the system is sufficiently capable for what the business is about to ask it to do, not if it’s healthy. Readiness depends on context. You may be assessing readiness for current customer growth, enterprise sales, geographic expansion, higher transaction volume, a major product launch, regulatory requirements, or a large integration. That’s why there should be no universal definition of "good enough."
When an engineer works on a startup's software, they are not merely working with code. They are working with founder capital, team time, customer trust, engineering capacity, business opportunities, operational risk, and the company's future. That creates a responsibility. Therefore, the objective should be to maximize sustainable business value from engineering resources, not to maximize engineering activity. Sometimes that means building, fixing, measuring, simplifying, preparing, saying no, or even waiting. The quality of an engineering partner should therefore be judged by more than technical ability. It’s a much higher standard to check if they help the business make better engineering decisions.
Making engineering more sophisticated, modern, elegant, automated, and scalable may be useful outcomes. The real opportunity is when the company is more capable of delivering value, resilient to failure, economically efficient, prepared for its next stage, and confident in its engineering decisions. That’s engineering leverage.
The goal is to make better engineering decisions, not more engineering work. Sometimes the best engineering decision is to build something, fix something, simplify something, or to say “not yet”. That’s engineering judgment, not avoiding engineering because your engineering system does not need to be perfect. You need to know what matters now.
Share this article
Send it to someone who would find it useful.