How long custom software takes to build
Real timeline bands for custom software builds in NZ in 2026, matched to the four standard price ranges. What slows projects, what speeds them, and why 'ASAP' usually costs the most.
The six-week hope
Most owners ask the cost question first. The timeline question comes second, usually phrased as "and how long would that take?", said with the tone of someone hoping the answer is six weeks.
Rarely. And the bit nobody tells you is that the longest variable in most software projects isn't engineering, it's the client side. Decisions waiting for sign-off. Content not ready. A stakeholder who needs to see it before the next stakeholder can.
Here are the realistic timeline bands for NZ custom software builds in 2026, what actually drives them, and the parts of the project where time goes missing.
The four timeline bands
These map cleanly onto the four pricing bands we use. The two numbers move together, bigger build, longer timeline, but not perfectly. A small build with messy data can take longer than a medium build with clean data. The bands are a starting point, not a quote.
Simple business tool, 4 to 8 weeks. A focused internal tool: a quoting calculator, a job-tracking dashboard, a workflow that replaces a fragile spreadsheet. One or two user types. Maybe one integration. We've shipped these in four weeks when the client has decisions ready and content prepared, and stretched much longer when sign-off has to route through a board.
Medium custom application, 8 to 16 weeks. A multi-user web app with real workflow, multiple integrations, role-based permissions, reporting. This is the most common band and the one where timeline overruns are most common too. A clean medium build at 12 weeks is the realistic centre of the band.
Larger or multi-module build, 16 to 28 weeks. Several distinct modules, complex permissions, multiple integrations, a meaningful data migration from a legacy system. Almost always staged, module one shipping before module three exists.
SaaS product or platform, 16 to 32+ weeks to first launch. First launch isn't first version of everything; it's the smallest version that earns its place in market. After launch, the project doesn't stop. SaaS is an ongoing build with regular releases, not a project with an end.
The bands assume a single client-side decision-maker who can move quickly. They stretch when sign-off has to route through committees, boards, or three separate departments who all want a say.
They also assume sign-off happens inside the window we've clearly defined upfront. We usually book a one- or two-week period for each sign-off stage. Miss it and your developers move to other work, and your project goes back in the queue. Developers can't sit idle waiting on a single client. It's how we stay afloat.
What actually controls timeline
If you want to compress a software timeline, the engineering side is rarely the lever. The levers are mostly on your side.
Decision speed. This is the biggest single variable. A project where the client can answer "should the form save drafts or not?" within a day moves twice as fast as one where the same question waits a fortnight for a meeting that gets rescheduled twice. We've genuinely had medium builds finish faster than smaller ones because the client was decisive.
Scope discipline. Adding "just one more thing" mid-build always costs more time than it sounds like. The new feature itself is the small part. The retests, the rework on adjacent features, the re-explaining to the team, that's where the days go.
Content and data readiness. If the app needs to launch with real product data, real client records, real document templates, those have to be ready by go-live week. Almost no one has them ready by go-live week. Plan to spend the final fortnight chasing content rather than building.
Integration partner responsiveness. If your build talks to a third party, a payment gateway, an industry CRM, a courier API, a legacy system from a previous vendor, the timeline depends on a stranger's email response speed. Their two-week reply time is now your two-week reply time.
Stakeholder count. Two decision-makers is fine. Three is workable. Five is a delay-generating machine.
The thing that doesn't control timeline as much as people expect is engineering hours. Modern development with developer-led AI genuinely runs faster than it did three years ago. The constraint has shifted. It's almost always on the client side now.
Why "ASAP" usually costs more
A compressed timeline doesn't have to mean a worse build. We can usually ship the same scope at the same quality in six weeks that would have taken ten. It just costs more. We charge a rush fee to cover the cost of rearranging schedules and pulling developers off other work.
The fee also acts as a soft deterrent. We're happy to make the exception for a real business reason like a regulatory deadline or a market window. "We want it now" isn't one. If your budget is tight and the deadline is real, scoping down is almost always cheaper than paying the rush fee.
How a medium build actually unfolds
To make this concrete, here are the phases of a clean medium custom build at Urban Lightbulb. Your build will look different in the specifics, but the rhythm holds.
Discovery and design (around 4 weeks). We use this phase to build a full specification document that covers every aspect of the application. If it isn't in the specification, it isn't built. The spec is paired with a full design walkthrough of the visuals and UI/UX before we write a line of code. Skip this and you'll pay for it later in rework.
Project setup (1 to 2 weeks). Before any feature work begins, we set up the foundations. CI/CD pipelines. Linting and test scaffolds. Basic authentication. Our internal prompts and tooling tailored to the project. By the end of this phase the skeleton is deployed and ready for features to be built into it.
Phased build (3 to 8 weeks). We split the project into several discrete phases, each one a deliverable. We work through them in sequence and you see each phase delivered as it's done, not all at the end. That means usable functionality lands early, and your feedback on the early phases shapes the ones still to come.
Launch and delivery (1 to 2 weeks). Final stage. We test the deliverables together. Run final checks. Verify everything has been built to specification. Client sign-off. Production deploy. Brief handover. Maintenance period begins.
The thing that throws this off is rarely engineering capacity. It's usually content not ready by launch, or a stakeholder asking for "one more thing" mid-build, or an integration partner who's gone quiet.
What's not in the timeline (and probably should be)
Two things that almost every quoted timeline excludes, but you should plan for:
A bedding-in month after launch. Real users find real bugs in the first thirty days. Not because the build is broken, because real-world use covers paths that User Acceptance Testing (UAT) never quite does. We hold a portion of every project for this period rather than calling the work "done" at launch.
Ongoing maintenance. Software isn't a one-off purchase. After launch, there's the security patch cadence, the framework upgrades, the small workflow tweaks, the occasional new integration. Each one takes time, ours and yours, and that work doesn't fit inside the build timeline. Plan for it from week one. A build with no plan for what happens after launch quietly decays, until you're staring at a refactor-or-rebuild decision you didn't budget time for.
How to actually plan your timeline
If you're scoping a build, do these three things before you sign anything.
First, identify your real deadline, not a wished-for date, an actual one with consequences. Most "ASAP" deadlines turn out to be flexible when prodded. Real ones don't.
Second, audit your decision-making chain. Can a single person sign off the workflow questions inside 48 hours? If not, build the answer into your timeline. Two-week sign-off cycles are fine if you've planned for them. They're project-killers if you haven't.
Third, get content and data ready in parallel with the build, not after it. Whoever's responsible for those should be working on them from week one, not week ten.
If you're not sure what your timeline should be, because the scope isn't clear yet, or you're still weighing up whether custom is the right call at all, or the deadline isn't real, or you've been quoted three wildly different numbers, that's a good conversation to have before money changes hands.