Every week the deck arrives. Tickets moved, hours logged, a burndown chart trending the right way, a paragraph about "continued work on the backend." It looks like progress. Four months in, you realize you still cannot show the product to a customer, and you cannot say exactly what you have paid 90,000 dollars to build. The status reports were never lying. They were measuring the wrong thing, and so were you.
Activity is the easiest thing in the world for an agency to produce, and the easiest thing for a non-technical founder to mistake for progress. A team can be genuinely busy every single week and move your product almost nowhere. The gap between motion and movement is where budgets disappear, and it stays invisible for exactly as long as you keep grading the relationship on the wrong metric.
Why activity is a bad proxy for progress
Hours logged, tickets closed, and lines of code are all measures of effort, not outcome. They go up whether or not anything a user can touch got better. A team can spend three weeks "refactoring the data layer" and close forty tickets doing it, and at the end you have the same product you started with, now with a cleaner foundation you have no way to verify and no way to value. Sometimes that work was necessary. Often it was the team building the thing that was interesting to build rather than the thing you needed shipped, which is the same failure I described in teams that ship fast and build the wrong things, just wearing an invoice.
The reason this persists with agencies specifically is that the incentives point at activity. An agency bills for time or for milestones it defines. A weekly report full of motion justifies the invoice. A weekly report that says "nothing a customer can use shipped this week, here is why" is honest and rare, because it invites exactly the question the agency would prefer you not ask. So you get theater: real work, real hours, arranged to look like momentum.
The tell is that the reports are always about inputs. Work continued. Progress was made. The team investigated. Notice how rarely the language is about a working thing that now exists and did not last week.
The questions that separate motion from movement
Stop asking what the team did this week. Ask what a user can now do that they could not do before. This single change reframes every status meeting around outcomes, and it is answerable by a non-technical founder because it does not require reading code. Either there is a screen you can click through or there is not.
Ask to see it, not hear about it. A demo of working software, even rough, is the only status report that cannot be faked. If the answer to "can you show me" is consistently "it is not quite in a demoable state yet," that is your signal, and it does not get better on its own. Working software is the unit of progress. Everything else is a promise about future working software.
Ask what is deployed where you can reach it. A feature that exists on a developer's laptop is not done; it is a claim. A feature running on a staging URL you can open is real. Insist that "done" means deployed somewhere you can see it, and watch how the pace of "done" changes once it has to survive contact with a link you can click.
Ask what got harder or slower, and listen for whether the honest answer ever appears. A team that only ever reports green is either extraordinarily lucky or managing your perception. Real projects hit walls. A partner who tells you about the wall is worth more than one whose reports are uniformly smooth, because the smooth ones are the ones that surprise you at month four.
If the answers stay vague across a few weeks, the problem is not the reporting format. It is that there is less underneath the reports than the reports imply, and the next move is a hard conversation about scope, pace, and whether you should renegotiate what you are actually paying for.
What good looks like instead
A healthy engagement produces something you can use, or at least see, on a rhythm you can feel. Not necessarily every week, but often enough that you are never four weeks from the last time you touched working software. The best agencies push their own demos on you because a working demo is the cheapest way to keep a client confident. When you have to pull the demo out of them, the relationship is already inverted.
The cleanest way to set this up is to establish it before the contract starts, which is one more reason a paid pilot beats a big first contract: a short pilot shows you the team's real cadence of shipping working software before you have committed a quarter's budget to their status decks. If you are already deep in an engagement and cannot answer "what can a user do now," you do not have a reporting problem. You have a progress problem, and it is worth a hard look before the next invoice. A second opinion on the code and the pace is what a call is for.
My agency's reports look great. Am I being paranoid?
Test it cheaply. Ask for a live demo of the current build and try to do one real user task end to end. If you can, the reports are probably honest. If the demo keeps slipping or the task breaks halfway through, the reports were measuring effort, not outcome, and you found out for the price of one meeting.
Isn't some backend work just invisible by nature?
Some is, genuinely. Infrastructure and data work does not always produce a screen. But it should produce something demonstrable: a faster page, an endpoint you can hit, a capability the next feature needs. If backend work never resolves into anything you can observe, even indirectly, ask when it will, and get a date tied to something visible.
How often should I expect to see working software?
There is no universal number, but a useful floor is that you should never go more than two or three weeks without seeing the product move in a way you can perceive. Longer gaps are sometimes legitimate for hard technical work, but they should be the exception you agreed to in advance, not the default rhythm of the engagement.