The short answer
A software build is on track when you receive working software to review on a predictable schedule, the scope of what is being built matches what was agreed, and your team can explain any deviation from the original plan with specifics rather than vague reassurances. If those three conditions are met, the project is healthy. If any one of them is missing for more than a week, ask direct questions before costs compound.
Why this is harder than it sounds
Most founders judge progress by how busy their developer seems. Lots of messages, busy-sounding updates, and Figma screens with arrows on them can all feel like momentum. None of them are proof that code is being written, tested, or shipped.
The problem is structural. Software is largely invisible until something is running on a real device. A team can spend two weeks making architectural decisions that produce nothing you can click on, and that work might be entirely legitimate. Or it might be stalling. Without a baseline for what normal looks like, you cannot tell the difference.
To give yourself that baseline, you need to track three separate dimensions: delivery cadence, scope fidelity, and communication quality.
Delivery cadence: the most reliable signal
In a well-run build, you should be seeing a deployable build or a meaningful update to an existing build at least once a week. This is not arbitrary. Weekly delivery forces developers to break work into completable chunks, surfaces integration problems early, and gives you something concrete to react to.
If your team is working in two-week sprints, you should still see a mid-sprint demo or staging deployment. A two-week gap with no working software to review is a red flag regardless of how many Slack messages you received.
What "a build" actually means
A build does not have to be a finished feature. It can be:
- A login screen that authenticates against a real database
- A dashboard with placeholder data but functioning navigation
- A payment form wired to a test environment
What it cannot be is a screenshot, a prototype in a design tool, or a description of what will be built next. Those are outputs of planning, not development.
Scope fidelity: are they building what you agreed?
Every project has a scope document, brief, or feature list that was agreed before work started. At any point in the build, you should be able to map current progress against that document and answer two questions:
- Which features are complete, in progress, or not yet started?
- Has anything been added, removed, or changed without a formal conversation?
Scope creep in either direction is a warning sign. Features added without discussion inflate cost and timeline. Features quietly deprioritised without explanation can mean the team is running into technical problems they have not disclosed.
Ask for a status breakdown against the original scope list at the start of each week. A simple table is enough.
| Feature | Status | Estimated completion | Notes |
|---|---|---|---|
| User registration | Complete | — | Deployed to staging |
| Profile editing | In progress | End of week | Blocked on image upload |
| Notifications | Not started | Week 3 | Awaiting API credentials |
If your team cannot produce something like this, that is itself important information.
Communication quality: the difference between updates and answers
Good project communication is specific. Bad project communication is optimistic.
Specific updates sound like: "We finished the authentication flow. The remaining issue is that password reset emails are going to spam — we are working on the SPF record configuration and expect it resolved by Thursday."
Optimistic updates sound like: "Things are going really well, we are making great progress and should have something to show you soon."
The second type is not always dishonest, but it is useless. You cannot act on it, adjust your plans around it, or use it to make decisions. When updates are consistently vague, it usually means one of three things: the team is behind and avoiding the conversation, they are uncertain about the timeline and reluctant to commit, or there is no one on the team whose job it is to communicate with you clearly.
All three of those situations require the same response: ask a direct question and expect a direct answer. "What is the one thing blocking the fastest path to a testable build this week?" is harder to deflect than "How are things going?"
Five concrete checks you can run right now
1. Ask to see the staging environment. Any modern web or mobile build should have a staging or test environment running. If you cannot be given a link or a TestFlight invite to something real, ask why.
2. Request the task board. Most development teams use Jira, Linear, Trello, or a similar tool. Ask for read access. You do not need to interpret every ticket, but you should be able to see whether tasks are being completed or accumulating.
3. Count the commits (roughly). If you have access to a GitHub or GitLab repository, look at the activity graph. A healthy build has daily or near-daily commits. A flat line for several days during what should be active development is worth questioning.
4. Test the build yourself. Install the app on your own device. Try to break things. If it crashes immediately or features described as complete do not work, say so clearly. You do not need technical knowledge to notice that a button does nothing.
5. Check blockers against your own actions. Developers frequently need things from founders: copy, credentials, design decisions, third-party accounts. If the build has slowed, check whether an outstanding request from your team is sitting in your inbox unanswered. The block is sometimes yours.
For more on how to make your feedback count once you are testing builds, see How to Give Feedback on a Software Build.
Warning signs versus normal friction
Not every delay is evidence of a failing project. Some slowdowns are genuinely routine. The table below separates the two.
| Situation | Normal friction | Warning sign |
|---|---|---|
| Build delayed two days | Dependency issue with a third-party API | No explanation given after asking |
| Feature looks different from mockup | Design adjusted during implementation | Scope changed without discussion |
| Week without a testable build | Sprint planning or environment setup at project start | Recurring pattern after the second week |
| Team asks for more information | Normal clarification during build | Same question asked multiple times |
| Timeline extended once | Reasonable if scope expanded | Extended repeatedly with no scope change |
What to do when something feels off
Start with a specific question rather than a general concern. "I notice we have not had a testable build since last Tuesday. What is the current blocker and when do you expect to resolve it?" is more useful than "I am worried the project is behind."
If the answer is vague or the pattern continues, escalate to a structured check-in. This does not have to be confrontational. Ask for a 30-minute call where the team walks you through the current state of the build on screen, explains what is complete, and names the specific date when the next milestone will be testable.
If you are not getting that level of clarity, you may have a communication problem rather than a development problem. The solution is the same: be direct, be specific, and document what you are told so you can follow up against it.
Understanding the full arc of what a build looks like from the inside is covered in What Happens After You Hire an App Developer. That article explains the stages in order and what each one should produce, which makes it easier to calibrate whether what you are seeing is appropriate for where you are in the process.
FAQs
How often should I receive a build update from my development team?
At minimum once a week. A testable build or staging deployment should arrive on a predictable schedule. If your team is working in two-week sprints, ask for a mid-sprint demo at the halfway point.
What should I do if my developer says everything is fine but I cannot see anything working?
Ask for a screen-share or a link to the staging environment. If the build exists, showing it takes five minutes. If it cannot be shown, that is the answer you needed.
Is it normal for a build to go silent for a week?
In the first few days of a project, some silence is expected as the team sets up infrastructure. After that, a week with no update and no testable build is worth questioning directly.
I do not understand the technical updates I am getting. How do I know if they mean real progress?
Ask the team to translate each update into something you can verify yourself: a screen you can tap, a form you can submit, a page you can load. If the work cannot be demonstrated, it either is not done yet or it is foundational infrastructure. Both are valid, but your team should be able to say which.
How does the kickoff meeting affect how easy it is to track progress later?
Significantly. A kickoff meeting that produces a clear scope list, a milestone schedule, and agreed communication cadences gives you the baseline you need to measure against throughout the build. Without that foundation, tracking progress becomes guesswork. See What Is a Development Kickoff Meeting? for what a good one should cover.