How long does custom software take to build?

The honest ranges, from a studio that ships this stuff weekly:

Project type	Typical timeline	Calendar reality
Small tool or automation	1 – 3 weeks	Idea this month, using it next month
Internal system (portal, dashboard, booking)	4 – 10 weeks	A quarter, end to end
Customer-facing product / MVP	3 – 6 months	Two quarters with launch buffer
Complex platform	6 – 12+ months	A funded program of work, not a project

Two caveats make those numbers trustworthy rather than optimistic. First, they assume the smallest useful version — the discipline of cutting scope is where fast timelines actually come from. Second, they’re calendar time, not effort: a three-week tool might be 60 hours of work, but feedback loops, testing against real data, and waiting on answers spread it across weeks. Both halves matter when you’re planning around it.

Where the time actually goes

People imagine software time is mostly typing code. A realistic split for a mid-size project:

• Discovery and scoping (10–15%). Understanding the real process — not the documented one, the one with the workarounds. Skipping this doesn’t save time; it relocates it to expensive rework later.
• Building (40–50%). The visible part. Modern frameworks have made this genuinely faster than a decade ago — this is why small tools now take weeks, not months.
• Edge cases and integration (20–30%). The invoice with no ABN, the duplicate customer, the API that times out monthly. “It works in the demo” to “it survives your messiest Tuesday” is a real phase, and it’s the one cheap quotes silently delete.
• Testing, migration, deployment (15–20%). Moving your existing data in, running parallel with the old process, training, go-live.

What makes projects fast

From our side of the table, the fast projects share five traits — most of them are things the client controls:

1. One decision-maker who answers within a day. This is the single biggest factor, bigger than any technical choice. A question that waits four days stalls everything behind it.
2. A written description of the current process. One page of “here’s what happens, step by step, including the dumb parts” can replace two weeks of discovery meetings.
3. Small scope, sequenced. “Replace the quoting tab” ships in weeks. “Replace the spreadsheet” ships in months. “Digitise our operations” never ships.
4. Real data available early. Building against your actual messy spreadsheet beats building against a tidy sample and discovering the mess at migration.
5. Boring, proven technology. Novel tech stacks are where schedules go to die. For small-business software there is almost never a reason to be a pioneer.

What blows timelines out

The classic schedule-killers, in the order we see them:

• Scope creep with no trade. Every “while you’re in there, could it also…” is fine — if something else leaves the version-one list. Additions without subtractions compound into months.
• Decision committees. Three people who must all approve each screen roughly doubles elapsed time. (It also adds 30–50% to cost — the same dynamic we flag in our cost guide.)
• The integration nobody scoped. “It just needs to pull from the old system” — and the old system turns out to have no API, an unreadable export, and a vendor who answers support tickets quarterly.
• Dirty data. Migration is fast when the data is clean and glacial when ten years of inconsistencies need untangling. If your data is messy, say so upfront; it changes the plan, not the feasibility.
• Disappearing client. Projects need your feedback at specific points. Every week a test build sits unopened is a week added, and momentum lost costs more than the week.

A realistic walkthrough: a 6-week internal tool

What a typical internal-system build actually looks like:

• Week 1 — Discovery. Map the process, agree the version-one scope in writing, settle what’s explicitly out.
• Weeks 2–4 — Build, with weekly check-ins. You see real screens by week 2. Weekly look-ins (30 minutes) catch misunderstandings while they’re cheap.
• Week 5 — Your data, your edge cases. Migration, integration, and the parade of weird historical records. Always the humbling week.
• Week 6 — Parallel run and go-live. Team uses the new tool alongside the old process, final fixes, switch over. The old spreadsheet is archived, not deleted — trust is earned, not declared.

Most of the small tools in our portfolio compressed this to two or three weeks; the PDF text replacer for the law firm took less time to build than the task it replaced used to take per quarter.

”Can it be faster if we pay more?”

Mostly no, and it’s worth knowing why. Software has a famous law (Brooks’ Law) that adding people to a late project makes it later — coordination overhead grows faster than output. What genuinely compresses timelines isn’t money, it’s the list above: faster answers, smaller scope, cleaner data. The good news: those are free.

The one place money legitimately buys speed is queueing — a studio can sometimes start sooner or dedicate a developer fully rather than splitting attention. Ask about start date and focus, not about “rushing”.

How to plan around a software timeline

• Add your own buffer for the human side — training, habit change, the fortnight where Karen still updates the old spreadsheet “just in case”.
• Don’t schedule go-live against a hard external deadline (EOFY, peak season, a contract start) with zero slack. Software arrives on time far more often when on time has a week of give in it.
• Judge week one, not the contract. A team that ships something visible in the first fortnight will probably ship the whole thing; a team that’s “setting up architecture” for a month probably won’t.

The bottom line

Small tools take weeks, systems take a quarter, products take half a year — and the levers that make your project land at the fast end of its range are mostly in your hands: one decider, written process, small scope, early data. Pair this with what those builds cost and you can plan a project on real numbers end to end.

Got a deadline in mind? Tell us what you need and when — we’ll tell you honestly whether the timeline is realistic, and what version one would have to look like to hit it.