From Brief to Go-Live: How Custom Software is Built in New Zealand

You have an idea — or more likely, a problem. Something in your business that software could solve, if only the right software existed. You've decided to explore building something custom. But what actually happens next?

Most business owners have never commissioned custom software before. The process can feel opaque — you describe your problem, a developer disappears for a few months, and a system appears. Or doesn't, quite the way you imagined. Or costs more than expected.

It doesn't have to work that way. Here's a plain-English walkthrough of how a well-run custom software project actually works, from first conversation to a system your team is using.

Phase 1: Discovery — Understanding the Problem Properly

The most important phase of any software project is also the one most often skipped or rushed: discovery. This is where a developer works with you to understand your current process in detail, identify the real problem (which isn't always the same as the stated problem), and define what the software needs to do.

A good discovery process involves structured conversations — sometimes called requirements workshops — where the developer asks detailed questions about how your business operates. Who does what? What triggers a task? What happens when something goes wrong? What are the exceptions? What does your team need to see to make a decision?

The output is a brief or specification document: a clear, agreed description of what the software will do, how it will work, and what's out of scope. This document becomes the basis for an accurate quote and the reference point for the entire project.

Discovery typically costs $1,500–$4,000 for a small to mid-range project. It's money well spent — a vague brief produces an inaccurate quote and sets up a project for scope creep and disappointment. A clear brief produces a predictable project.

One thing to be prepared for: discovery requires your time. You'll need to be in conversations, answer questions, review drafts of process maps and wireframes, and keep communication moving. The developer can't discover what they don't know — and you know your business better than anyone.

Phase 2: Design — How It Will Look and Work

Once the requirements are clear, the next step is design. This is where the abstract "what it needs to do" becomes concrete "here's what you'll actually see and click."

Design work varies by project. For some tools — internal automations, API integrations, backend processes — there's minimal visual design work because the interface is simple or secondary. For client-facing portals, intranets, and anything with a significant UI, design is a major phase.

Wireframes are low-fidelity mockups that show layout and flow without colour or styling — they're quick to produce and quick to change, which makes them ideal for working out the structure before committing to anything. After wireframes are approved, visual design adds the look and feel.

Your involvement here is critical. This is your chance to say "that's not how our team thinks about this" or "we actually need this information here, not there" before a line of code is written. Changes are cheap at this stage. They're expensive after build.

Phase 3: Build — Where the Software Gets Made

This is the phase most people think of as "the project" — the actual coding work. In practice, build is smoother when discovery and design were done well. A developer with a clear brief and approved designs can work efficiently and predictably.

Most modern development works in short cycles called sprints — typically one or two weeks long. At the end of each sprint, there's something to show: a working feature, a completed section, a piece of the system that behaves as specified. You'll usually have access to a development environment where you can see and test the work as it progresses.

This iterative approach is better than big-bang delivery — it surfaces misunderstandings early, gives you something tangible to react to, and keeps the project from drifting in the wrong direction over months.

During build, the developer will have questions. Some are technical; others require business decisions from you. Staying responsive — ideally same-day response time on questions — keeps the project moving. Delays in getting answers add up quickly.

Phase 4: Testing — Making Sure It Works

Testing happens at two levels. The developer tests throughout the build — unit tests, integration tests, checking that each piece works as intended. But user acceptance testing (UAT) is when you and your team actually use the system, checking that it works the way your real process works.

UAT is often underestimated by clients. It's not just clicking around to see if it looks right — it's running your actual scenarios through the system, finding the edge cases, and verifying that the software behaves correctly in the situations your business actually faces.

Budget real time for this. A week of UAT for your team is not unusual for a mid-range project. The bugs and adjustments found during UAT are much cheaper to fix now than after go-live.

It's also worth testing with the actual people who will use the system daily, not just the person who commissioned it. Staff who weren't involved in the build will find things no one thought to look for.

Phase 5: Launch — Going Live

Launch is the moment the system goes from testing to real use. For internal tools, this usually means deploying to a production environment, setting up user accounts, and running a training session or two. For client-facing tools, it might involve migrating data from old systems, communicating with clients about the change, and a parallel run period where both old and new systems operate simultaneously.

A good developer will help you plan the go-live carefully — especially if there's data migration involved, or if downtime during the switch would affect your operations. For business-critical systems, a staged rollout (starting with one team or one location) is often lower risk than switching everyone at once.

Expect some turbulence in the first few days. Even with thorough testing, real-world usage finds things that testing missed. This is normal. The key is having clear communication with your developer so issues can be logged and addressed quickly.

After Go-Live: The Work Continues

Launch isn't the end — it's the beginning of a new phase. Once real users are in the system doing real work, you'll learn things you couldn't have learned in testing. Some features will be used differently than expected. Some things you thought were important turn out not to matter. Some things you didn't think to include will turn out to be needed.

Build a feedback period into your project plan — a structured window, usually four to eight weeks after go-live, where you collect feedback, log requested changes, and then prioritise what to address. Not everything needs to be done immediately; some requests will be "nice to have" and can be batched into future development.

Most businesses end up with an ongoing relationship with their developer — either a retainer for regular small updates, or a model where development happens in project chunks every few months. This is healthy. Software that doesn't evolve with your business becomes stale and starts to feel like the off-the-shelf tools you moved away from.

What Makes Projects Go Well (and What Doesn't)

After working with a range of NZ businesses on custom software, a few patterns stand out for what makes projects succeed:

Projects that go well have a clear brief developed upfront, a client who stays engaged and responsive, realistic timelines that account for feedback rounds, an MVP-first mindset (build the core first, add complexity later), and a developer who communicates proactively about progress and blockers.

Projects that struggle typically have a vague initial scope, a client who's hard to reach when decisions are needed, scope that expands mid-project without adjusting the budget or timeline, expectations of a perfect system on first delivery, or a developer who goes quiet for weeks at a time.

The client's side of the equation matters as much as the developer's. Custom software is a collaborative process — you're not ordering a product off a shelf, you're building something together. The businesses that get the most out of custom software are the ones who treat it that way.

Finding the Right Developer in New Zealand

New Zealand has a relatively small pool of custom software developers, which means you can often get referrals and references from people you know. When evaluating options, ask to see examples of previous work in your domain (industry or project type), talk to previous clients directly, and understand who will actually be working on your project — not just who you're meeting in the sales conversation.

Clear contracts matter. You should own your code. You should understand exactly what's in scope and how changes are handled. You should know what the support arrangement is after go-live. A developer who's reluctant to be specific about any of these is a developer worth being cautious about.

The best first step is usually a conversation — not a formal brief, just a discussion about your situation. A good developer will tell you honestly whether what you're describing is a custom software problem or something that could be solved another way. That honesty, before any money changes hands, is usually a good sign of how the whole project will go.