"How's it going?" "Good. Almost there." The demo looks fine. A month later you ask again and hear the same answer. The release moves by two weeks, then by two more. Nothing is obviously broken, and nothing is obviously finished.
You pay for development every month, and you can't tell whether that money is building something solid or something that will have to be rebuilt.
Usually nobody is hiding anything. A project is just hard to see from the inside, and if you don't write code yourself, you can't check what you're told.
"Almost done" isn't a status
Most owners see development through three windows: the demo, the task board, and what the team says in meetings. All three show progress. None of them shows the condition of what's being built.
A demo shows the path where everything goes right. A task board shows that tasks are closed, not whether closing them brought you closer to a working product. And "almost done" usually means the visible part is done. The rest is the part nobody demos: error handling, edge cases, tests, deployment, moving the old data. It often takes as long as everything before it.
It's like buying a used car. It's clean, it starts, and the test drive goes fine. Whether the engine has years left in it, you can't tell from the driver's seat. That's a question for a mechanic.
Three questions you can't answer from the outside
When development feels off, it usually comes down to three questions.
Is the code solid? Code can work today and still be expensive tomorrow. A product on a weak foundation is fine until it has to change. Then every change costs more, and the reason is hard to see from outside.
Is the team slow, or is the work hard? Some features are hard. Some need experience the team hasn't had a chance to build yet. From the outside, both look the same: weeks pass, and the feature isn't there. One needs patience. The other needs help. Treat one as the other and things get worse. Push a team doing hard work, and you get shortcuts. Wait patiently while a team works beyond its experience, and you just burn more budget.
Are the estimates honest? Usually they are, in the sense that the team believes them. But if every estimate misses by about the same amount, that isn't bad luck. It's a pattern, and a pattern has a cause. Sometimes it's in the code: a fragile part that slows down everything built near it. Sometimes it's in the planning: work nobody counted, or a requirement nobody fully understood. We wrote about the second kind in You don't know what a feature will really cost.
The team can't see it either
It's tempting to just ask the team. Sometimes that works. Often it doesn't, for three reasons.
A team that has worked in the same codebase for two years gets used to it. The workaround everyone knows about stops looking like a workaround. The module nobody wants to touch becomes "just how it is." Drive the same car every day and you stop hearing the rattle.
There's also an experience ceiling. A team can only spot problems it has seen before. If nobody on the team has taken a system through the next stage of growth, such as ten times the users, a second product or a new market, they can't tell you what will break on the way. They haven't watched it break.
And there's position. A developer who says "the architecture is wrong and we need two months to fix it" is telling you that their own work, or their lead's, has a problem. Some developers will say it anyway. Many won't, at least not to the person paying the bills.
Signs you should look under the hood
None of these proves there's a problem. Together, they're a good reason to check.
- Deadlines slip a little, but every time.
- Each release fixes one thing and breaks another.
- Simple changes take longer than they used to.
- Some parts of the system have a "don't touch" reputation.
- One developer is the only one who understands a key part.
- Customers find bugs more often than tests do.
- New team members take months before they can change anything safely.
- You've asked the same question in three meetings and got three different answers.
What a mechanic looks at
A Technical Audit is the mechanic's inspection. Someone who hasn't been inside your project, and has seen many others, looks at it and tells you what's really there.
We look at four things:
- Architecture. Can the system grow where your business is going? Which parts will be the first to struggle with more users, more data or more features?
- Code quality. Is the code readable, tested and consistent, whether people or AI agents wrote it? Are there security holes, fragile spots, or the same logic copied in five places?
- Delivery speed. How long does a change take to reach production, and what in the code or the release setup slows it down? How often does a release break something? How do past estimates compare with what actually happened, and where does the gap come from?
- Team skills. Does the team have the experience this system needs, and where are the gaps?
These four are usually connected. Slow delivery turns out to be a fragile module everyone is afraid to change. The fragile module turns out to be a decision made two years ago, when the system was a tenth of its size and nobody could see where it was going. If the cause is the process rather than the code, that's what our Process Review is for.
Anyone can run a tool that lists everything that could be better. The hard part is knowing which findings matter. A tool will flag a shortcut in the checkout code and a shortcut in an admin page the same way. Only one of them will cost you a rewrite when your traffic doubles. Our job is the short list: what will actually hurt you.
We're not there to grade the team. We're there so that you and the team are looking at the same picture. Good teams often already suspect many of the findings. What they usually lack is the time, and an outside voice, to put them in order.
A few weeks against six months
An audit takes two to three weeks, for a fixed price. We need access to the code. We may ask the team a few questions along the way, when something in the code needs explaining. Development doesn't stop while we work.
The alternative is another six months of guessing. A worn timing belt is cheap to replace. Wait until it snaps, and you're paying for the engine.
At the end, you get:
- a written report in plain language;
- the risks, ranked by severity, so you know what matters now and what can wait;
- prioritized fixes: what to do first, and why;
- a debrief call where we walk you through the findings and answer your questions.
You'll know where the project really stands, and what to do next. Sometimes that's good news: the project is in better shape than you feared, and the delays have an ordinary cause. That's worth knowing too.
An audit won't fix anything by itself. What it gives you is a written picture you can plan around, instead of a feeling.
If you're not sure your project is where the team says it is, book a call.