You hired a software team, the demo looks fine, and every sprint review ends with everyone nodding. But "it looks done" and "it is healthy" are not the same thing — and if you can't read the code, the sprint review is the one recurring moment where you can still tell the difference. You just need to ask about the right things.
None of the questions below require you to be technical. They're the same questions a good technical co-founder would ask on your behalf — reframed so you can ask them yourself, in plain language, and know what a reassuring answer sounds like versus one worth a follow-up. The point is never to catch your contractor out. It's to turn a passive demo into a real conversation about how the work is actually going.
The short version: at every sprint review, ask what shipped that a user can feel, how much time went to rework versus new work, who else could maintain each piece if one person left, what got touched that wasn't planned, whether new features arrived with tests, how much went in without review, and what had to be undone. You don't need to read code to ask these — and the answers tell you far more than the demo does.
1. What did we ship this sprint that a user can actually feel?
Start here because it grounds everything else in outcomes, not activity. A healthy answer names one or two concrete things a real user could now do that they couldn't two weeks ago — and the demo shows them. A weaker answer is a long list of internal work ("refactored the auth layer", "upgraded the framework") with nothing a user would notice. Internal work is legitimate and sometimes necessary, but if every sprint is invisible to users, that's worth a calm, direct conversation about where the time is going.
2. How much of this sprint was new work versus fixing and redoing old work?
This is the single most revealing question about the health of a project. Every team spends some time on bug fixes and rework — that's normal. But when sprint after sprint is dominated by fixing things that were "done" a month ago, it usually means the work is being rushed, tested too late, or built on shaky foundations. A good contractor will give you a rough split honestly ("about 70% new features, 30% fixes this sprint") and be able to explain any spike. If you can't get a straight answer, the git history can give you one directly.
3. If the person who built this had to step away, who else could pick it up?
Ask this about each significant feature, because the answer exposes your single biggest continuity risk. If the honest answer is "only Alex really understands the payments code", you have what's called a bus factor of one — one person leaving, going on holiday, or falling out with the agency could freeze a critical part of your product. This is extremely common in outsourced work and rarely surfaces until it's a crisis. You're not asking anyone to change how they work; you're asking so you know where the risk sits and can decide whether it's acceptable.
4. Which parts of the codebase did we touch that weren't in the plan?
A small, self-contained feature should touch a small, predictable set of code. When a simple change ends up reaching into many unrelated parts of the system, it's often a sign that the codebase is tangled — that things are more connected than they should be, so every change risks breaking something far away. A good team will tell you when this happens and why. If it happens on most changes, it's an early warning about maintainability that's much cheaper to hear now than in a year.
5. Did the new features arrive with tests?
Automated tests are the safety net that lets a team change your product quickly without breaking what already worked. The question to ask isn't "what's our test coverage percentage" — that number is easy to game. It's simpler: when we add a new feature, does a test show up alongside it, and when we change existing behaviour, do the existing tests get updated too? A team that consistently ships features with no accompanying tests is trading speed today for fragility and slower work later — and that trade is your money, so it's yours to understand.
6. How much of this sprint's work went in without a second person reviewing it?
On a healthy team, one developer writes a change and another looks it over before it becomes part of the product — this is called code review, and it's how teams catch mistakes and spread knowledge. If most of the work is written and approved by the same person with no second pair of eyes, you're relying entirely on one individual's judgment, and you're back to the continuity risk from question three. Ask what share of this sprint's changes were reviewed by someone other than the author. "Almost all of them" is a great sign about how the team works.
7. What did we have to undo or redo this sprint, and what did we learn?
Every team occasionally ships something and then has to reverse it — that's not a problem in itself, and a defensive "nothing, everything went perfectly" is often less trustworthy than an honest account. What you're listening for is whether the team learns from it. "We shipped the new checkout, saw errors, rolled it back within an hour, found the cause, and it's fixed" is a team that's in control. The same thing happening three sprints running, with no change in approach, is the pattern worth raising.
How do I get honest answers without just taking their word for it?
Here's the useful part: almost every question above can be answered directly from your project's git history — the running log of who changed what, and when, that every software project keeps automatically. How much was rework, whether one person owns a critical area, whether tests arrived with features, how much shipped without review — it's all recorded, whether or not it comes up at the meeting. As the client, you're normally entitled to read access to that history; it's worth agreeing to up front.
That's exactly what PulseRepo reads. It turns your git history into a short, plain-language list of the questions worth raising this sprint — not scores, not a verdict on anyone, just the handful of things you'd want to ask about if you could read the code yourself. You can see a sample report to get a feel for it. Walk into your next sprint review already knowing which of the seven questions above actually apply, and the meeting stops being a demo you watch and becomes a conversation you lead.