Twelve questions, and most of them are about ownership rather than technology. Who owns the code, whose accounts it runs in, what the fixed scope says in writing, what done means, what they have built before and what it cost, and who pays them besides you. A builder answers all twelve in a sentence each. A reseller changes the subject.
Automation is easy to sell and hard to hand over, and the gap between the two is where the money goes. These are the questions I would ask, in the order I would ask them, with the answer I would want back. The last section is me sitting the same exam.
Ownership, and why it comes first
Four questions. Get these wrong and the rest stops mattering, because you will be renting your own business process back from someone else.
1. Who owns the code when it is finished? The answer you want: you do, and here is the repository it lands in. A weak answer talks about a licence, a platform fee, or a managed package you cannot open. If the code lives somewhere you cannot reach, you have bought a subscription with a build fee attached to it.
2. Whose accounts does it run in? The answer you want: your Microsoft tenant, your Xero, your hosting, your bill. A weak answer is a shared login belonging to the consultancy, or an API key nobody will name. Accounts are where lock-in hides, because moving code is a weekend and moving accounts is a project.
3. What happens when you leave? Ask it plainly. A good answer names the documentation, the handover session and the person inside your business who ends up holding it. A weak answer is a reassurance about how long the firm has been around, which tells you about their past and nothing about your handover.
4. Could another developer pick this up? The answer you want: yes, and here is what they would read first. Anything on a mainstream stack passes this. Anything built inside a proprietary tool that one firm resells does not, however quick the demo was.
Scope and money, in writing
Three questions, and all three should have a document behind them before you pay anything.
5. What exactly is in the fixed scope? A fixed price with no written scope is a number attached to a conversation. A good answer hands you a list: what gets built, what the software does on the day it lands, and what has been left out on purpose. The exclusions matter more than the inclusions, because that is the list an argument gets fought over in week five.
6. What does done mean, and who decides? A good answer describes acceptance: something you sit in front of, a list you tick, a date it happens by. A weak answer leaves done as the builder's opinion. Fixed price or hourly for custom software works through how each model moves that decision around.
7. What happens when I change my mind halfway? Requirements move, on every build I have run. A good answer has a change process with a price attached, so a new idea becomes a decision. A weak answer is "we'll sort it out", which turns into either a grudge about free work or an invoice you did not expect.
The arithmetic behind question six. Take a single automation at $6,000, the middle of the $4,000 to $8,000 band on the services page. Split it half on signing and half on acceptance and you pay $3,000 to start, then $3,000 once you have seen it work. If it never works, your exposure is $3,000. Pay the whole $6,000 up front and the builder carries no risk at all once the invoice clears. That split is the entire argument, and it is worth one question.
Evidence, and how to ask for it
8. Show me one thing you built, and tell me what it cost. One real example with a number on it beats a portfolio. If everything sits under an NDA, ask for the shape instead: what it did, how long it took, what it cost, what broke afterwards. Someone who builds can describe a build they got wrong.
9. What will you not build? A good answer is a short, specific list. Anyone who will build anything is selling hours. My list is on the services page, and it includes marketing stacks, website projects, generic AI strategy workshops and chat widgets with no workflow behind them. If your own AI use right now is loose ChatGPT prompts and hoping, ChatGPT for tradies covers what that's genuinely good for before you pay anyone to build something bigger.
10. Who does the work? The person in the meeting is often a different person from the one typing. That can be fine, as long as you know before you sign. Ask who writes the code, who you ring when it breaks at 7am, and whether those two are the same human being.
Incentives, the two that get skipped
11. Which tools do you get paid by? Plenty of firms hold partner status or reseller margins, and there is nothing wrong with that as long as it is on the table. What you want to know is whether the recommendation survives the margin disappearing. Ask it directly: if this product paid you nothing, would you still put it in front of me?
12. What happens in the first sixty days after handover? The first two months is when the real defects surface, because that is when people use the thing under pressure with a customer waiting. A good answer names a warranty period and what it covers at no charge. A weak answer sells you a support retainer that quietly covers their own bugs.
Nine of those twelve questions are about ownership, paperwork and incentives. None of them are technical. The technical questions sort themselves out once you know who owns the result.
My answers to the ones aimed at me
Fair is fair. Kove against its own list, and all of it is on the services page where you can hold me to it.
- Code and accounts. Source code in your GitHub, credentials in your accounts, hosting on your bill. No lock-in.
- When I leave. Documentation and team training are part of the build, and I do not count a project finished until people are using it without me.
- Fixed scope. Builds run four to eight weeks against an agreed plan. That plan comes out of a Workflow Review at $3,500, and the written report is yours whoever ends up building from it.
- Done, and the money. Half on signing, half on acceptance. If you do not accept it, you do not pay the second half.
- Warranty. Sixty days after launch, anything that breaks I fix at no charge. There is no retainer wrapped around that, and ongoing support is a separate decision you make later.
- What I will not build. Marketing stacks, websites, generic AI strategy workshops, chat widgets with no workflow behind them, and anything I do not believe will pay for itself.
- Who pays me. You do. I do not resell Tradify, Fergus, ServiceM8 or NextMinute, and Microsoft pays me nothing for putting Power Platform in front of you. When the right answer is to buy the off-the-shelf tool, saying so costs me a build, which is why four situations where Power Platform is the wrong answer is on this site at all.
- Who does the work. Me. Kove is one person in Christchurch, and I run two or three builds at a time so that stays true.
When twelve questions is too many
This much scrutiny suits a build in the $4,000 to $8,000 band or above, and the $10,000 to $22,000 range even more. It is too much for a two-hour job. If someone is connecting an app you already run to Xero for a few hundred dollars, ask three: whose accounts does it run in, what happens when it breaks, and what is the fixed price.
The list also will not help until you know whether a build is worth doing at all, which is a numbers exercise and comes first. The ROI calculator turns the hours the job eats now into a payback in months, and what custom automation costs a Canterbury trades business sets out the bands.
Ask me the twelve
Book a free 30-minute call and put the list in front of me. If any of my answers make you uncomfortable, you have spent half an hour and learned something useful about what to ask the next person.
Questions about hiring someone to build it
What should I ask an automation consultant before hiring them in NZ?
Start with ownership: who owns the code when it is finished, whose accounts it runs in, what happens when they leave, and whether another developer could pick it up. Then scope and money: what is written into the fixed scope, what done means and who decides, and what a change costs halfway through. Then evidence: one thing they built and what it cost, what they will not build, and who does the actual typing. Finish with incentives: which tools pay them a margin, and what the first sixty days after handover covers.
Who owns the code when a consultant builds custom software for my business?
That depends entirely on what you agreed, which is why it is the first question. The answer you want is that the source code lands in your repository, the credentials sit in your accounts and the hosting is on your bill, with no licence tying the software to the person who built it. If the code lives somewhere you cannot reach, you have bought a subscription with a build fee attached.
How do I tell a builder from a reseller?
Ask which tools pay them. Partner margins and reseller commissions are legitimate, and the test is whether the recommendation would survive the margin disappearing. A builder can describe a project that went wrong, name the things they refuse to build, and answer the ownership questions in a sentence each. A reseller moves the conversation back to a product demo.
Do I need to ask all twelve questions for a small job?
No. Twelve is the right level of scrutiny for a build in the $4,000 to $8,000 band or above. For a two-hour connector job costing a few hundred dollars, three will do: whose accounts does it run in, what happens when it breaks, and what is the fixed price. The rest is ceremony at that size.