You've hired a development agency, signed the contract, and the sprints are underway. But how do you actually know if the work is good? A practical framework for non-technical founders and decision-makers who need to hold their agency accountable — without opening a single file.
There's a version of this conversation that happens constantly in founder communities, but rarely makes it into public discourse: 'I paid six figures for a software build. It was delivered. It seems to work. But I genuinely don't know if it's good — and I don't know how to find out.'
It's one of the most common anxieties among non-technical business owners who outsource development. Not 'will it get built?' — that's the fear before you hire. The fear after you hire is subtler: how do I know I'm not being quietly ripped off, delivered mediocre work, or sitting on a codebase that will cost three times as much to maintain as it should?
The answer is not 'learn to code.' The answer is knowing which signals to read — and those signals are available to anyone who knows where to look.
Four operational metrics will tell you more about your agency's work quality than most people realize — and none of them require technical knowledge to track.
Velocity trend. Are features shipping on the schedule the agency committed to? Not whether they're 'busy' — whether committed scope is completing on time. A team doing good work delivers consistently. A team cutting corners, accumulating debt, or under-staffing your project will show velocity problems within the first two to three sprints. Track planned vs. delivered scope for every sprint.
Regression rate. How often do new features break things that were already working? Every software build will have some bugs at launch — that's normal. What's not normal is a pattern where the login page breaks when a payment feature is added, or an old integration stops working every time new code is pushed. Recurring regression is a structural code quality problem. You don't need to read the code to notice it.
Bug age. How long do reported bugs sit open? An agency managing a healthy, well-structured codebase can typically investigate and fix a reported bug within a few days. Bugs that stay open for weeks, get closed and reopen, or require lengthy explanations about why they're 'complex' are often exposing underlying architectural problems the team is reluctant to surface directly.
Deployment frequency and confidence. How often is new code being deployed to a test or staging environment? A professional development team ships small, frequent updates — not large batches of code after weeks of silence. If you're only seeing the product updated in big bang releases with long gaps between them, the team is likely not following practices that prevent accumulation of integration problems.
Key Takeaways
Sprint reviews and status calls are where agencies with something to hide get comfortable — because most clients accept updates without pressing on specifics. That pattern is worth changing.
Ask: 'What did you decide not to build this sprint, and why?' A team doing thoughtful work makes deliberate tradeoffs. A team that can't answer this question hasn't been making tradeoffs — they've been reacting.
Ask: 'What technical debt are we accumulating?' Every software project makes shortcuts; professional teams track them explicitly and plan to resolve them. An agency that claims there is no technical debt in your project is either not being honest or not doing the kind of engineering introspection that produces maintainable code.
Ask: 'If someone new joined the team tomorrow, how long would it take them to understand this codebase?' Maintainable, well-structured code can be onboarded in days. Code that has been written quickly without documentation or internal consistency takes weeks — and that cost falls on you when you eventually hire an in-house developer or switch agencies.
Ask: 'What would cause this feature to fail in production?' Teams that write good code think about failure modes proactively. Teams that don't will give vague or defensive answers to this question.
Key Takeaways
If your business metrics or sprint conversations are raising flags, or if you're approaching a major milestone like a fundraise, acquisition, or the handoff to an internal team, a third-party code audit is worth serious consideration.
A technical audit is exactly what it sounds like: an independent senior engineer or specialist firm reviews your codebase and delivers an assessment of its quality, security, maintainability, and structural soundness. They are not connected to your development agency and have no incentive to give you a reassuring answer.
Audits typically cost between $3,000 and $10,000 depending on scope and the seniority of the reviewer — a number that is almost always worth paying before committing to the next major development phase or before transferring significant additional budget to the same agency. A good auditor will give you specific findings, not generalities: which parts of the codebase are well-structured, which carry risk, and what remediation would cost.
Ask your auditor specifically about: test coverage (what percentage of the code has automated tests), security posture (are there common vulnerabilities present), documentation quality, and whether the architecture will support the scale you're planning for. These are the four areas where cost accumulates fastest after delivery if the work was not done well.
Key Takeaways
The quality of how an agency communicates about its work is one of the most reliable early indicators of the quality of the work itself. Good teams communicate specifically. Bad ones communicate in ways that sound confident but commit to nothing.
A good status update names specific features completed, references the acceptance criteria that were met, flags specific blockers with proposed resolutions, and states clearly what will be delivered next sprint. It reads like something written by people who know exactly what they built and can defend it.
A bad status update uses language like 'the backend work is progressing well' without naming what was completed, 'we're almost done' across multiple consecutive sprints on the same feature, or 'we encountered some complexity' without explaining what it was or how it changed the timeline. These phrases are not communication — they're placeholders that defer accountability.
If your status updates have started feeling vague, that vagueness is information. Press for specifics every time. Teams doing good work can always give them.
You don't need to read code to hold a software agency accountable — you need to know which signals matter and have the confidence to ask for specifics when the answers are vague. Track velocity, regression, and bug age consistently. Ask the questions that expose technical debt and architectural decisions. Bring in an independent auditor before you commit to the next phase. And pay attention to how the agency communicates: specificity is usually a sign of competence, and evasion is usually a sign of something worth examining. At StepTo, we build with the expectation that non-technical clients will ask hard questions about the quality of the work — not just the status of the work. If you're currently evaluating agencies or unsatisfied with how your current build is progressing, we're happy to have a direct conversation about what good looks like and whether your engagement reflects it.
StepTo helps European and US companies build senior-led nearshore engineering teams in Serbia. Let's talk about what your next engagement could look like.
Start a conversationIgor
stepto.net