The 90-Day Custom Application Build: A Realistic Timeline

“How long will it take?” is the first question every client asks. The honest answer for a focused custom application MVP is 10–14 weeks. Here’s what those weeks actually look like - and what to watch for at each stage.

This is the timeline for a focused MVP: 4–6 core workflows, basic auth, a small handful of integrations. It’s not a 200-feature enterprise build - that’s a different conversation. But it covers what most Sydney SMBs actually want.

Week 1–2: Discovery and product definition

Nothing gets built. This phase is entirely about understanding the problem.

What happens:

• Stakeholder interviews. The CEO, the operations lead, the people who’ll actually use the tool every day.
• Workflow mapping. Every current process the new tool will replace or support, drawn out step by step.
• User journey definition. Who uses what, when, and what state changes happen at each step.
• Constraints surfaced. Compliance, data residency, integration requirements, budget ceilings.
• Out-of-scope list. As important as the in-scope list.

Deliverables: Product brief, prioritised feature list, sitemap/screen list, basic data model.

Risk to watch: Scope sprawl. Every stakeholder will have favourites. The product owner needs to be ruthless about MVP scope. Anything that isn’t strictly necessary to ship version one belongs in a “phase 2” parking lot.

Week 3: Design - wireframes and flows

Low-fidelity wireframes of every screen. Black and white. No visual polish. The goal is to validate structure, not look.

What happens:

• Wireframes drawn for each major screen
• User flows mapped through them - can the user actually accomplish each task?
• Edge cases identified (empty states, error states, loading states)
• A clickable wireframe prototype shared with stakeholders

Deliverable: Wireframe prototype (Figma).

Risk to watch: Stakeholders responding emotionally to grey boxes. (“It looks plain.”) Reassure them - visual design comes next. The wireframe is for structure.

Week 4–5: Design - visual and interaction

High-fidelity visual design. Brand applied. Real copy where possible. Real data in mockups where possible.

What happens:

• Visual design system: typography, colour, spacing, components
• High-fidelity mockups of every screen
• Interaction details: hover states, animations, transitions
• Mobile / tablet variants for any screens that need them
• A clickable, near-final prototype

Deliverables: Figma design system + screen designs + interactive prototype.

Risk to watch: Round-and-round feedback. Set a hard limit of two rounds of revisions at this stage. After two rounds, the design is approved and locked. Further changes become change requests in the build.

Week 5 (parallel): Technical architecture

While design is finalising, the engineering side starts.

What happens:

• Tech stack confirmed (often React + Node, sometimes Next.js, sometimes Laravel)
• Database schema designed
• Authentication strategy chosen
• Integration approach decided (REST, webhook, OAuth)
• Hosting and infrastructure planned
• Deployment pipeline configured

Deliverables: Architecture decision record, database schema, environment setup.

Risk to watch: Over-engineering. A 14-week MVP doesn’t need microservices, Kubernetes, or six databases. Keep the architecture as simple as the problem allows. Complexity should be earned, not assumed.

Week 6–9: Core build

The longest phase. Engineering works through the feature list in priority order.

What happens:

• Authentication and user management built first
• Core data models and CRUD operations built
• Each major user flow built end-to-end (database → API → UI)
• Weekly client demos showing real progress on a staging URL
• Bug list maintained and triaged weekly
• Integrations built in parallel where possible

Deliverables: Working staging environment, feature checklist progress, demo each week.

Risk to watch: “Just one more feature” requests. Every change request adds time and risk. The product owner should batch them into “must-have-for-launch” vs. “phase 2.” Almost everything is phase 2.

Week 10: Integration and polish

Bringing the pieces together, handling the awkward edges.

What happens:

• End-to-end testing of major flows
• Edge cases handled (what happens when X fails?)
• Email notifications, alerts, system messages
• Reports and dashboards
• Admin tooling for support
• Performance pass - load times, query optimisation
• Accessibility pass

Deliverables: Feature-complete staging environment.

Risk to watch: Discovering missed requirements. A stakeholder realises they need a report that wasn’t in scope. Discuss honestly: can it wait for phase 2, or is it truly launch-blocking?

Week 11: User acceptance testing

Real users from the client side use the system intensively.

What happens:

• Test users (not just the project sponsor) run through real workflows
• Bug reports collected
• Confusion points logged
• Critical bugs fixed immediately
• Minor polish items collected for post-launch

Deliverables: UAT sign-off, prioritised bug list.

Risk to watch: Discovery that the design didn’t match how the user actually works. Sometimes minor. Sometimes a real problem. Hard conversations happen here. The earlier the better.

Week 12: Launch prep

Production setup, data migration, go-live planning.

What happens:

• Production environment provisioned and locked down
• Data migration scripts written and tested (often the most overlooked phase)
• DNS, SSL, security headers configured
• Monitoring and alerting set up
• Backup and disaster recovery tested
• Final security review
• Launch runbook written

Deliverables: Production-ready system, launch runbook.

Risk to watch: Skipping the migration rehearsal. Migrating data from old systems should be done at least twice on staging before doing it for real. A missed mapping at this stage can corrupt everything.

Week 13: Launch

The cutover. Usually scheduled outside business hours.

What happens:

• Final data migration
• DNS switch
• Old system access frozen
• Smoke tests in production
• Team monitors actively for 24–48 hours

Deliverables: Live system.

Risk to watch: Going dark right after launch. The first 72 hours produce the most user feedback. The team should be available, not on holiday.

Week 14: Stabilisation

The first week of real use.

What happens:

• Critical bugs triaged and fixed within hours
• Quick polish based on real user feedback
• Performance monitoring under real load
• Onboarding remaining users
• Documentation handed over

Deliverables: Stable system, support process handed off.

What slips a timeline

In our experience, projects miss timelines for a small number of reasons, all of them avoidable:

1. Decision latency on the client side

Every day a design or feature decision sits with the client is a day of slip. The most successful client-side product owners answer the development team’s questions within 24 hours.

2. Scope changes mid-build

“Can we also add…” conversations should land on a phase-2 list, not in the current build. Every yes adds risk.

3. Late access to existing systems

“We’ll figure out the API access next week” is a phrase that’s killed many timelines. All third-party integrations should have working sandbox access by week 3.

4. Content and data not ready

The system needs real content and real test data by week 6. Empty databases hide problems that real data exposes.

5. Reviewer availability

The senior approver going on holiday during design review week is a common cause of two-week slips. Plan around them or empower a deputy.

What gets ignored that shouldn’t

• Backups. Configure from day one. Test restoration before launch.
• Logging. Even basic logging saves countless hours when something goes wrong in production.
• Error tracking. Sentry or similar. Configure it.
• Performance budgets. “Pages should respond within X” should be set early and tested constantly.
• The “what if a user is malicious” pass. A security audit before launch. Even a quick one.

The honest cost / time / scope triangle

If a project absolutely must ship in 10 weeks: cut scope, not quality.

If a project absolutely must include the full scope: extend the timeline.

If a project absolutely must hit a fixed budget: pick one of the above. Both at once is fiction.

The clients who finish on time on budget are the ones who accept this triangle exists and choose deliberately. The ones who try to optimise all three end up with shoddy systems delivered late and overbudget.

---

Considering a custom application? Get in touch for a free 30-minute scoping call. We’ll tell you honestly whether your idea is a 12-week build or a 6-month one.