Why 'How's It Going?' Is the Wrong Question
The business owners who have the smoothest software projects are not the ones who trust their agency the most — they are the ones who ask the best questions at the right moments. This is not about micromanaging. It is about knowing what to look for at each stage, so that small problems get caught early instead of turning into expensive ones late.
Most non-technical clients ask strong questions before signing: What's your process? Who will be on my project? What does the timeline look like? Those questions matter. But once the project starts, many clients go quiet — partly because they don't want to seem difficult, and partly because they genuinely aren't sure what to ask. So they check in with 'how's it going?' and accept whatever answer they get.
'How's it going?' almost always gets a positive answer. It tells you almost nothing. What follows is a stage-by-stage checklist of questions that actually surface the information you need — whether things are on track, where the risks are, and what decisions only you can make.
During Discovery: Before a Line of Code Is Written
A proper discovery phase — where your agency maps your requirements, defines the scope, and produces a specification — is the single most valuable thing you can do before development begins. It is also where the most important questions belong.
What will I receive at the end of discovery, and how specific will it be? The output of a good discovery phase is a detailed specification document: user flows, defined features, edge cases, API dependencies, and a pricing estimate tied to specific deliverables. If the answer is vague, the estimate you receive will be too.
What have you learned about my project so far that surprised you? Any agency doing real discovery will have encountered at least one complication or open question. If everything was exactly as expected, they probably haven't dug deep enough.
What is in scope, and what did you explicitly leave out? Scope boundaries are where cost overruns are born. A professional agency can name exactly what is not included — and why — before you commit to a number.
Key Takeaways
- Ask for a written scope document with named exclusions before approving any estimate
- Surprises during discovery are a good sign — they mean the agency is actually looking
- If the estimate arrived in under 48 hours without a discovery phase, it is a guess
At Your First Sprint Review: The Early Signal
The first two to four weeks of a project tell you more about how an engagement will go than any proposal. What ships in the first sprint — and how the team handles anything that didn't — is a reliable signal of how the next six months will look.
What did we commit to this sprint and what was delivered? Ask for a direct comparison between planned and completed work. Slippage in sprint one, without a clear explanation, tends to compound.
What is the biggest open question or risk right now? A team that cannot name a risk at this stage either hasn't thought about it or isn't comfortable telling you. Both are problems worth addressing early.
Can I see what's been built, even if it's incomplete? Requesting access to a staging environment or a screen recording of the current state is reasonable and reasonable agencies expect it. If early builds are not available for review, ask why.
Key Takeaways
- First sprint delivery quality predicts the rest of the engagement more reliably than any kickoff conversation
- Teams that can name risks proactively are teams that will surface problems early instead of late
- Staging environment access should be available from the first sprint — not only at the end
At the Mid-Project Checkpoint: Before It's Too Late to Change Course
Somewhere around the halfway point of a project — ideally before you've spent more than 60% of your budget — there should be a structured checkpoint that is distinct from a regular sprint review. This is where the most consequential questions belong.
Are we still on track to hit the original launch date and budget? Ask for a current estimate-to-complete, not a reassurance. If the honest answer is that you're trending over, you want to know now — when there is still time to adjust scope rather than absorb the cost.
What decisions have been made that I should know about? Technical decisions made mid-project — which database to use, how to handle a particular integration, how authentication was implemented — affect maintainability, future costs, and your ability to change vendors. You do not need to evaluate them technically, but you should know they were made and that someone documented them.
If we had to cut 20% of scope to hit the deadline, what would you recommend cutting? This is one of the most revealing questions you can ask. It tells you whether your agency understands your business priorities — and whether they are willing to have an honest conversation about tradeoffs.
Key Takeaways
- A mid-project estimate-to-complete is more useful than any status update
- Architectural decisions made without your knowledge can lock you into tech debt or vendor dependency
- An agency that can answer the 'what would you cut?' question honestly understands your priorities
Pre-Launch: The Week Before Go-Live
The week before launch is not the time for surprises. If your agency is doing their job, this should be a confirmation of preparation rather than a discovery of problems. A few questions make sure you're genuinely ready.
What has been tested, and what hasn't? Ask for a specific list of what was tested, by whom, and what the pass criteria were — not a general statement that QA is complete. Edge cases and failure scenarios matter as much as the happy path.
What happens if something breaks on launch day? Your agency should have a defined incident response process: who is on call, how to reach them, how quickly they can deploy a fix, and what the rollback procedure is if needed. If they don't have answers, you have a risk.
What do I need to own after launch? Before you go live, you should have a clear picture of what requires ongoing maintenance, what your hosting and infrastructure costs will be, and what happens if you need to make changes after the engagement ends.
Key Takeaways
- Request a written test coverage summary, not a verbal sign-off
- An incident response plan — including rollback procedures — should exist before go-live
- Post-launch ownership responsibilities should be documented before the project closes
After Launch: The Questions Most Clients Forget to Ask
Most business owners stop asking questions the moment the product is live. That is exactly when a different, underrated set of questions becomes important.
Is everything running the way you expected? The first two weeks in production often surface things that testing didn't catch — performance under real traffic, edge cases real users find, integration behavior at scale. Your agency should be monitoring proactively, not waiting for you to report problems.
What would you do differently if we built this again? The answer to this question tells you how honest and technically mature your agency is. Every project produces lessons. Agencies that share them are partners. Agencies that have no answer weren't paying attention.
What are the highest-risk parts of what we built, and what should we address next? Every system has technical debt and known fragile points. A good agency can name them — and should, before they become incidents.
These questions are not just about the current project. They are how you evaluate whether this agency is worth continuing with, and what the next phase of your product should prioritize.
Key Takeaways
- The first two post-launch weeks should include active monitoring from your agency, not just availability
- Agencies that share lessons from the project are partners; agencies that don't were executing tickets
- Known technical debt should be documented before the engagement closes — not discovered later
The Bottom Line
The difference between a software project that delivers and one that disappoints is rarely technical. It is almost always about communication, accountability, and whether the right questions were asked at the right moments. You do not need to be able to read code to run a good software engagement. You need to know what to ask — and to ask it at every stage, not just at the beginning. If you are planning a custom software or AI development project and want to work with a partner who welcomes this kind of scrutiny at every milestone, we'd be glad to walk you through exactly how we run our engagements — and what you should hold us to.
Building a team in Eastern Europe?
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 conversation