After you hire an app developer, the project moves through four broad phases: discovery and scoping, design and architecture, build and iteration, and handoff. Each phase has a defined output, a set of decisions you must make as the founder, and a realistic timeframe. Knowing what to expect at each stage is the difference between a smooth delivery and an expensive stall.
The First Week: Discovery and Kickoff
The contract is signed, the deposit is paid. What happens on day one?
Most development partners begin with a discovery session, sometimes called a kickoff call or scoping workshop. The goal is to translate your idea into a shared understanding specific enough to build from. Expect the team to ask about your target users, the core problem the app solves, the features you consider essential versus nice-to-have, and any technical constraints such as existing systems the app must connect to.
This is also when the team confirms the project scope in writing. If you signed a fixed-price contract, the scope defined here is the scope you paid for. Changes after this point typically affect price or timeline. If you are on an hourly arrangement, scope changes affect your total bill. Either way, clarity at discovery protects you.
What you need to provide during discovery:
- A written summary of the problem your app solves and who it solves it for
- A rough list of features, even if loosely described
- Any examples of apps you admire, with notes on what specifically you like
- Login credentials or documentation for any third-party services the app must integrate with
- Access to any brand assets: logo files, colour codes, font names
Founders who arrive at discovery unprepared slow themselves down, not the developer. A two-hour kickoff that gets everything on the table saves days of back-and-forth later.
Weeks One to Two: Design and Architecture
Once the scope is confirmed, the team moves into two parallel tracks: user interface design and technical architecture.
What the Design Track Produces
Most teams deliver wireframes first, which are low-fidelity screen layouts showing structure without colour or final visuals. After you approve the wireframes, a designer applies your brand to produce higher-fidelity mockups. Some teams skip wireframes and go straight to mockups; others build interactive prototypes you can click through.
Your job during this phase is to give clear, specific feedback. "I don't like it" is not actionable. "The main navigation feels buried, can it sit at the bottom of the screen instead?" is. Vague feedback leads to revision cycles that push your launch date.
What the Architecture Track Produces
On the technical side, the lead developer or architect maps out the database structure, chooses the technology stack, and identifies any third-party services needed (payment processors, authentication providers, email platforms, and so on). You will rarely see this work directly, but it should be documented. If you ever change development partners, that documentation is what a new team needs to continue without starting from scratch.
If you have questions about who will own the underlying code once the project is done, sort that out before this phase begins. Ownership terms vary significantly between providers. The article Who Owns the Code From an AI Dev Service? covers the standard arrangements and what to watch for in your contract.
Weeks Two to Six: Build and Iteration
This is the longest phase and the one founders find most disorienting because visible progress can seem slow even when real work is happening.
Development typically runs in sprints, usually one or two weeks long. At the start of each sprint, the team commits to a set of features. At the end, they demonstrate what was built. Your role is to review each sprint demo and give feedback before the next sprint starts.
A Typical Sprint Cycle
| Stage | Who Acts | Output |
|---|---|---|
| Sprint planning | Dev team | A list of features to build this sprint |
| Build | Dev team | Working code |
| Internal testing | Dev team | Bug-fixed build |
| Demo | Both parties | Live walkthrough of what was built |
| Founder review | Founder | Written feedback or sign-off |
| Revisions | Dev team | Adjusted build |
Founders who go quiet during this phase create problems. If you take ten days to review a sprint demo, the developer either sits idle or moves forward on assumptions. Neither outcome helps you.
How to Tell If Progress Is Real
The only reliable indicator of real progress is working software. Ask to see the app running, not a screenshot or a slide deck. A legitimate development partner will show you a staging environment, which is a live but password-protected version of the app, after the first sprint. If you are three weeks in and cannot click through a single screen, ask why directly.
Other useful signals:
- The team is meeting the sprint commitments they set themselves. Occasional slippage is normal; consistent slippage is a warning sign.
- You are receiving specific questions about business logic, not vague updates. "What should happen if a user tries to book a slot that's already taken?" means the developer is building your actual app.
- Bug counts are decreasing over time. Early sprints will surface many small issues. Later sprints should surface fewer.
Understanding What You Actually Paid For
Mid-project is when scope confusion tends to surface. You assumed a feature was included; the developer assumed it was out of scope. These disagreements are expensive and stressful.
The best prevention is reading your quote carefully before signing. A well-structured quote specifies not just the price but what deliverables are included, what the acceptance criteria are, and what is explicitly excluded. The article What Is Included in a Software Dev Quote? breaks down each line item you should expect to see.
If a feature you consider essential is missing from the quote, raise it before the build phase begins. Adding it mid-sprint is always more expensive than scoping it in from the start.
The payment structure also shapes your risk during the build phase. Fixed Price vs Hourly: Which Is Safer for Founders? explains how each model affects what happens when scope changes or timelines slip.
Final Phase: Testing, Handoff, and Launch Prep
Once the core build is complete, the project enters a testing and stabilisation period. The development team runs structured quality assurance, checking for broken flows, edge cases, and performance issues under load. You should also conduct user acceptance testing, which means putting the app in front of real people (even just five to ten) and watching them use it.
Handoff includes several components founders often forget to ask for:
- Access to the code repository (GitHub or equivalent)
- Credentials for all hosting and infrastructure accounts
- Documentation covering how to deploy updates and manage the app going forward
- Any third-party API keys the app depends on
Do not wait until the final invoice to ask for these. Confirm at the start of the project that handoff deliverables are spelled out in the contract.
App Store Submission
If the app is going to the Apple App Store or Google Play, build in extra time. Apple's review process alone typically takes one to three days but can run longer if the reviewer requests clarifications. Both stores have guidelines your app must meet before submission, and a rejection sends you back to the development team for fixes.
For web apps, the launch process is simpler but still involves domain configuration, SSL certificates, and environment variables that need to be set correctly. A rushed launch with missing configuration is a common source of day-one bugs.
What Founders Get Wrong Most Often
The most frequent mid-project mistake is disappearing. Founders who are hard to reach slow their own projects. Developers waiting on decisions about a feature cannot move to the next sprint cleanly, and the delay compounds.
The second most common mistake is requesting significant new features during the build phase without understanding the cost. Every major addition mid-build forces the team to re-examine the architecture, rewrite tests, and adjust timelines. Treat the build phase as sacred: if an idea comes to you, write it down for version two rather than adding it to the current sprint.
The third mistake is confusing activity for progress. Long status emails, frequent calls, and detailed Jira boards are not substitutes for working software. Ask to see the app running, and do so at least once per sprint.
FAQs
How long does it take to build an app after I hire a developer?
Timeline depends on scope. A focused MVP with five to eight core features typically takes six to twelve weeks from kickoff to launch-ready build. More complex apps with integrations, custom workflows, or multiple user roles take longer. Providers using AI-assisted development can compress certain phases, particularly the initial build, but discovery and testing still require real time.
How much input do I need to give during the project?
More than most founders expect. Plan to spend two to four hours per week reviewing progress, answering questions about business logic, and giving feedback on design and functionality. This is not optional overhead; it is the work that keeps the project moving.
What if the developer builds something different from what I asked for?
This almost always traces back to an under-specified scope at discovery. If the delivered feature genuinely does not match the agreed specification, raise it against the written scope document. If the scope was vague, the disagreement is harder to resolve. The clearest protection is a detailed brief and a signed scope document before any code is written.
Can I add features once the build has started?
Yes, but expect the addition to affect cost, timeline, or both. Most development partners handle additions through a change order, which is a short written document that specifies what is being added, what it costs, and how it affects the delivery date. Signing a change order before the work starts protects both parties.
What does handoff actually mean?
Handoff means you leave the engagement with everything you need to run, update, and transfer the app independently: source code in a repository you own, credentials for all accounts, deployment documentation, and any API keys. If a partner's contract does not mention handoff deliverables explicitly, ask for them in writing before you sign.