Skip to main content

"How long will this take?" is a fair question. The "it depends" answer is unsatisfying. So here's a real breakdown, by week, by feature size, for a typical Australian web app build in 2024.

Three honest sizes

  • Internal tool / spreadsheet replacement: 4–6 weeks. One workflow, ~25 users, basic auth, no public-facing surface.
  • Customer portal / B2B web app: 10–14 weeks. Multi-tenant, RBAC, three integrations, real onboarding.
  • SaaS or platform: 14–24 weeks. Billing, multi-tenancy, admin tools, audit, real performance budget.

What happens in those weeks

For a 12-week production build:

  • Weeks 1–2: Discovery and design. Workshops with your team, user flows, Figma prototypes. Sign-off on screens.
  • Weeks 3–4: Foundation. Auth, schema, deployment pipeline, staging environment, the "boring 80%."
  • Weeks 5–8: Feature build. Core flows shipped, two-week sprints with Friday demos.
  • Weeks 9–10: Integrations and polish. Third-party connections, edge case handling, real data tests.
  • Week 11: Beta. First real users on staging, you fix what breaks.
  • Week 12: Launch + warranty starts. Production deploy, training, and the bug warranty clock starts.

This is the honest cadence for a healthy project. Real projects deviate by 1–2 weeks in either direction; anything more is a sign of trouble.

The silent time-killers

Five things that quietly extend timelines:

  • Stakeholder review cycles. If five people need to approve every screen, you'll lose 1–3 days per cycle. Add it up across 8 weeks and you've lost a fortnight.
  • Slow third-party APIs. Xero, Stripe, MYOB, all reliable, all sometimes slow. Each integration has a multi-day "we're waiting on documentation/keys/sandbox access" delay.
  • Late copy. The product is built but the marketing copy isn't. Launch slips two weeks while you write.
  • Late data. The migration set is "coming next week" for six weeks.
  • Founder scope creep. "Just one more thing" added every Friday is the single biggest schedule risk on most projects.
Software is built late not because developers are slow, but because decisions are slow. Speed up the decisions, ship faster.

How to compress the timeline

The interventions that actually work:

  1. Single decision-maker per area. Not a committee. One person signs off design, one person signs off content, one person signs off scope changes.
  2. Daily, not weekly, demos in the final two weeks. The compounding feedback shaves 3–5 days.
  3. Pre-write the copy. By week 8, the copy should be ready, not in draft.
  4. Cut the integration that's blocking everything. If the third-party API is blocked, ship without it. Add it in v1.1.
  5. Stop adding features at week 8. Hard stop. Anything new is v2.

What "fast" actually looks like

The fastest production builds I've seen on FindDevs are 6–7 weeks. They share three traits:

  • The founder had pre-validated the product (real users waiting at launch).
  • The scope was brutally cut, not 12 features, six.
  • Decisions were made same-day, not next-week.

None of those are about the developer being faster. They're about the founder being decisive.

The bottom line

A simple internal tool: 4–6 weeks. A customer-facing portal: 10–14 weeks. A real SaaS: 14–24 weeks. The variable is mostly your decisiveness, not the engineering.

If you want three quotes that include realistic timelines (not the optimistic ones), FindDevs gets you those. Free, in 24 hours.

Jeff Ringer, founder of FindDevs

Founder of FindDevs, Australia's #1 developer quote network. Jeff has spent the last decade scoping software projects for Australian businesses, from solo founders shipping MVPs to enterprises rebuilding decade-old systems.

More from Jeff Ringer
Ready when you are

Compare three Australian developers. Free.

Two-minute brief. Three tailored quotes within 24 hours.

Joshua from Logan City just received three quotes for Mobile App development. Get your 3 quotes now
7 minutes ago