Hiring a software or AI developer is a high-stakes call. Pick wrong and you lose months and budget. This guide covers the questions New Zealand business owners should ask before they sign, the red flags to walk away from, and a checklist for the call. It comes from Putti, an Auckland team that's delivered 100+ projects since 2010.
What should I ask before I hire a software or AI developer?
Three questions, and they're not the ones most people ask.
Who owns the code? Not "will I get a copy" but who owns the repository, the hosting account, the domain, the app store listings and the database on the day the project ends. If the answer is anything other than "you, from day one", keep asking until it is.
Who actually writes the code? The person pitching to you is rarely the person building. That's fine, as long as you can meet the engineers before you sign and reach them during the build. Ask where they sit, whether they're employees or contractors, and whether any of the work touches a team overseas after the contract is signed.
What happens if it stalls? Every project hits a wall at some point. Ask what the process is when a milestone slips, who tells you, and what you're paying for in the meantime. A vendor who's thought about this has a real answer. A vendor who hasn't will say it won't happen.
After those three, the rest is detail. How do they handle a scope change mid-build. What does support look like in the first year after launch. And whether you can talk to a client they finished a project for two years ago, because software earns its keep over years and that's the reference that counts.
How do I choose a software development partner in New Zealand?
Compare on four things and put price last, because the cheapest quote on a project that fails is the most expensive quote you'll ever accept.
Delivery history first. How many projects have they shipped and how many didn't make it. Putti's number is 100+ delivered and zero failed, and we'd be suspicious of a vendor who couldn't give you theirs.
Longevity second. Your software will need looking after for years, and a team that's been around a decade is more likely to still be around for that. We've been in business since 2010.
Range third. If one team can cover design, web, mobile, backend and AI, nothing gets subcontracted out the back door. If they can't, ask exactly which parts go where.
References last, and in your sector. Names you can phone, not logos on a slide. Putti's include Hydraulink, HealthNow, Motorfy, RespiTrak and Emergency Q, all with case studies you can read on this site.
Why do software projects fail, and how do I avoid it?
Rarely because of the technology. Across the rescues we've run, the pattern is almost always the same and it's almost always structural.
The scope was never written down, so every change became an argument. Communication went through an account manager, so by the time you heard about a problem it had been a problem for a month. And there was no single team accountable for the outcome, just a chain of subcontractors each responsible for one piece.
You avoid all three at contract stage. Agree the scope and the success criteria in writing before anyone writes code. Insist on direct contact with the people building it. Choose one accountable team over a chain. And confirm the support plan for the first year while you can still walk away, which is before you sign.
What are the red flags when choosing a developer?
Some things should end the conversation.
Hidden subcontracting, where the people you met aren't the people who build and nobody mentioned it. A refusal to hand over ownership of the code and the accounts, or a vague answer when you ask. A quote with no written scope behind it. Silence when you ask about support after launch. References that are always about to be available and never are. And a reluctance to let you meet the engineers before the contract, which usually means there's a reason.
None of these are subtle. The mistake people make is noticing them and signing anyway because the price was good.
The vetting checklist
Take this to the call. Five groups, and you want a clear answer in every one.
Ownership and control: do I own the code, the repository, the hosting, the domain, the app store accounts and the data from day one? Track record: how many projects shipped, how many failed, and can I see one like mine? Communication and location: who writes the code, where do they sit, and can I reach them directly during my working day? References and proof: can I phone a client from two years ago, and are there case studies I can read? Scope and support: is there a written scope with success criteria, how are changes handled, and what does the first year after launch look like?
A vendor who answers all five without hedging is worth paying more for. That's the whole point of the exercise.
Where to start
If you'd like to put Putti through this checklist, book a call and ask us every question on it. We build in Takapuna, Auckland, we don't offshore, and the engineers who scope your project are the ones who build it.
If you're still comparing, how to choose a software partner in NZ goes deeper on the selection process, and why software projects fail covers what goes wrong after the contract is signed.