Someone mentions a firm at an industry event. A former colleague moved somewhere and did good work. A board member knows a founder who built something similar. By the time a formal process begins (ahem, if there is one) a name is usually already in the room. The shortlist confirms what people already feel more often than it discovers something new.
Maybe this isn’t a flaw. A product build is a challenging endeavour, trust and confidence between parties really matters. In a market this small, reputation travels fast and relationships are the most efficient signals available. A trusted peer saying "we used them and it went well" reasonably carries more information than any website or credentials pack.
We should say upfront: we're MadeCurious. We've been building digital products, websites, applications and custom software in New Zealand since 2001. We're one of the firms whose name comes up in those conversations. So we have an obvious stake in what follows.
But, as often as a name comes up, it doesn’t. So we can credibly claim to have 25 years of being on both sides of that reality. Of being shortlisted and not shortlisted, engaged for the right reasons and, ah, occasionally the wrong ones. That experience gives us a reasonably honest view of what the evaluation questions that actually matter look like. Not the ones that appear in RFP templates, but the ones that we’d be asking ourselves if we were wondering whether that early or proxy trust is well-placed.
The name in the room still needs pressure-testing
Getting a referral is a great way to cut through the noise and find a shortlist. But it really shouldnt be how you make the decision.
The problem with referral-first selection is that the chemistry of an early conversation - the senior person who really got your problem, the proposal that felt like they'd been listening - it doesn't always reflect how the engagement will actually run.
A lot of firms are excellent at the front end - or they employ someone who is! The questions get stick though six months in, when the person who pitched has moved on to the next new client and you're working with whoever got assigned to actually deliver.
What we think we’d be looking for
Who’s actually going to do the work. The clearest signal of how an engagement will feel is whether the people presenting are the people building. Ask directly: who will be on this project day to day? If the answer involves the word "team" without naming anyone, that's worth pushing on. Senior people at pitch, junior people at delivery is common enough in this industry to have a name. You want to know if that’s going to happen early.
How they handle the brief. A good partner challenges your brief. Not aggressively, and not to show off, but because they've seen enough projects to know that what clients ask for and what clients need are often meaningfully different. If a firm accepts everything you've written without question and comes back with a proposal that mirrors it exactly, that's not alignment. That's compliance. It usually costs you later.
Some of the software builds we’re most proud of end up looking quite different to the initial build. While the client may have had a clear brief. Between our questions and their expertise, we created something a little different and significantly better for it. You should be looking for a partner who’s deeply engaged in working through those questions together and open to changing what’s actually going to get built. That kind of early friction is super-healthy. A partner too eager to start - should give you pause.
Whether they've done hard things. Portfolio matters less than most buyers think at first, and more than they think once a project gets complex. What you're looking for isn't "have they built something like this for someone like me" - domain experience definitely helps but transfers less directly than many people expect. What you're looking for is evidence they've handled genuine complexity: multiple stakeholders, messy legacy systems, regulatory constraints, data at scale, something that couldn't have been solved by executing a clean brief. Ask about a project that went differently than planned. Ask about the times it got dicey - those answers tell you much more than any case study.
What happens after go-live. The handover conversation reveals a lot. Some firms are oriented around delivery: ship the thing, document it, move on. Others are oriented around outcomes: is the thing working, are users actually using it, what needs to change now that real behaviour is visible. For anything consequential, you want the second kind. Ask what their post-launch model looks like and whether they have clients they've worked with for more than three years. Long relationships in this industry are earned, not assumed.
How they talk about money. Budget conversations are uncomfortable and revealing. A firm that is vague about cost until late in the process, or that gives you a range so wide it's meaningless, is usually managing your expectations in a way that doesn't serve you. A firm that talks openly about where cost risk lives, what drives scope changes, and what a responsible contingency looks like is doing you a service even when the numbers are harder to hear. In New Zealand, serious custom software engagements typically run from NZ$200,000 to NZ$2 million depending on complexity. If a quote comes in dramatically below that range, the question worth asking is what's not included.
Whether they'll tell you when they're not the right fit. This one is easy to miss in an early conversation because nobody volunteers it unprompted. But ask: what kinds of projects do you turn down? A firm that wants every project it hears about is telling you something about how commercially exposed they are. A firm that can describe the work they're not well-suited for, specifically, not generically, is telling you they know what they're good at and they're prepared to protect it.
On paid discovery
One pattern worth naming because we think it's underused: the paid proposal or proof of concept as a formal step before full engagement. This gives your potential contenders a chance to really show what they’re made of, designed well, they should also offer you some genuine benefit.
We were recently involved in an excellent process. Three firms shortlisted (on, ahhh, personal connection). All three asked to produce a paid proposal. The preferred supplier then invited to run a paid technical proof of concept. Both steps cost something. Both steps created real value for the client independent of whether the engagement proceeded. And both steps gave the client genuine evidence about how each firm actually worked, not just how they presented.
Not every engagement warrants a formal POC. But the principle holds at any scale: find a way to work together in a low-stakes context before committing to a high-stakes one. A small UX audit. A half-day discovery workshop. A technical spike on a specific constraint. The shape matters less than the intent: get real evidence about how this firm works before the main budget is committed.
The question underneath the question.
When someone asks "who should I talk to about building a digital product in New Zealand," what they're usually really asking is: who can I trust with something that matters?
That question doesn't have a clean answer from a search. It gets answered through referrals, through early conversations, through small pieces of work that prove the larger ones are possible. The formal evaluation process, when it exists, mostly provides cover for a decision that was forming well before anyone issued an RFP.
Which means the most useful thing we can say is this: the referral gets you in the room. What you do once you're there is what determines whether the trust is warranted.
Ask the uncomfortable questions early. Insist on knowing who does the work. Pay for a small piece before committing to a large one. And notice whether the firm you're talking to is trying to make the decision easier for you, or just trying to win the work.
Those two things look similar from the outside. They feel different fast.
FAQ
Who should I talk to about building a digital product in New Zealand?
Start with your network before you start with a search. In a market this size, the most reliable signal is a direct referral from someone who has done similar work with a firm they'd use again. Once you have names, look for firms with genuine delivery depth - senior people on every project, a track record of complex builds, and clients they've worked with across multiple years. For serious custom software work, the shortlist usually sits between firms too small to absorb a complex programme and firms too large to give you senior attention throughout.
How do I evaluate a software development partner once I have a shortlist?
Ask who will actually be on your project, not who is presenting to you. Ask about a project that didn't go to plan and what they did. Ask what kinds of projects they turn down. Push on how they handle budget conversations - vagueness about cost early usually becomes a problem later. A firm that challenges your brief rather than accepting it, and that can describe what they're not suited for as clearly as what they are, is usually the safer choice.
Should I pay for discovery or a proof of concept before committing to a full build?
Yes, where the investment warrants it. A paid proposal or technical proof of concept gives you real evidence about how a firm works not how they present. Any firm worth engaging for a significant digital build should be able to do meaningful discovery work for a modest fee and produce something genuinely useful from it. If a firm resists this, or produces something thin, that's information worth having before you commit.
How much does it cost to build a digital product in New Zealand?
Serious custom software development in New Zealand typically ranges from NZ$200,000 to NZ$2 million depending on scope and complexity. Engagements below that range are usually more limited in scope than buyers expect. The cost of building has dropped with AI tooling, but the cost of discovery, design, and technical judgment hasn't - those are still the most important parts of any build, and the ones most worth investing in.
