Most advice about custom software is written by people selling it. This is the buyer’s side: eleven questions that decide whether a build ships, what it costs to keep, and what you are left holding if it goes wrong.
There is a specific kind of expensive mistake that happens to good businesses. Somebody senior decides the off-the-shelf options do not fit. A developer is engaged. Eighteen months later there is a system that three people use reluctantly, a maintenance bill nobody forecast, and a quiet agreement never to mention it again.
It rarely fails for technical reasons. It fails because the questions that decide the outcome were never asked out loud, and by the time they surfaced the answers were expensive.
So here they are, in the order they actually matter. If you are weighing custom against a product in the first place, the build-versus-buy decision is the page to read before this one — this page assumes you have decided to build and are about to choose who and how.
Not “what would be better”. What breaks. A number, a deadline missed, a margin lost, a person who will resign. If the honest answer is “nothing breaks, it is just annoying”, you are describing a preference, and preferences do not survive an eighteen-month build. The projects that finish are the ones where somebody could name the cost of the status quo in the first meeting.
Custom earns its cost when the process is the thing that makes you money and it is different from how everyone else does it. Estimating a job the way your estimators have learned to estimate it. Managing compliance obligations specific to your licences and sites. Routing work through your particular approval chain.
If the process is ordinary — invoicing, payroll, email, storing files — buy the product. Nobody has ever gained an advantage from bespoke expense claims.
Every build rests on one assumption that, if wrong, makes the rest worthless. The data is clean enough. The field crews will actually enter it. The legacy system can be read from. The rules can be written down.
Insist that this is tested first, cheaply, before the expensive part starts. Be suspicious of a proposal that opens with a polished interface: an interface is the easiest thing to produce and the least informative. Being shown something that looks finished is not the same as being shown that the hard part works.
Not the sponsor who signs. The person who will sit with the developers weekly, decide the arguments, tell you when the scope is drifting, and be accountable for whether anyone uses it at the end. If that person does not exist, or exists but has no time, the project has already found its failure mode. The technical work is rarely the hard part. Adoption is.
Write it down before work starts, not at the end when leverage has changed hands. Who owns the code. Who owns the data inside it. What happens to both if either side walks away. Whether you can hand the system to a different developer without permission.
A build you cannot move is a build you do not really own, whatever the invoice says.
This is the question that separates a real quote from half of one. The build cost is a one-off; the running cost is forever. Hosting. Third-party services. Model or API usage, which scales with how much you use the thing you were told to use more. Monitoring. Security patching. The hours someone spends supporting it when it misbehaves at 4pm on a Friday.
Ask for that number separately and ask what it looks like at three times the usage. It is the figure that decides whether you still want the system in year three, and it is the one most often left out.
Almost no custom system lives alone. It reads from the accounting package, writes to the scheduling tool, pulls from the ERP. Each of those is a dependency owned by somebody else who will change it without asking you.
Establish now who fixes an integration when the other side changes, and whether that is inside the support arrangement or a new quote every time.
“Documentation and training” is not an answer. Ask what a new developer would need to pick this up cold: readable code, an environment they can run, tests that prove it works, a written description of the decisions that are not obvious. Ask whether your own team will be able to make small changes without a purchase order.
Agree the measure before the build, because after the build everyone is motivated to find one that flatters it. Hours saved on a named task. Error rate. Time from enquiry to quote. Something countable, measured before and after.
This is the question specific to AI work, and it is not optional. Any system that generates, classifies or decides will sometimes be wrong. The design question is what happens then: does a human check before it matters, is there an approval gate on anything irreversible, is there a log showing what the system did and why, and can you explain a decision to a customer or a regulator afterwards?
A system that cannot show its working is a system you cannot defend. Build the audit trail in from the start; it is very expensive to add later.
Every system ends. Ask how you would get your data out in a format something else can read, what it would take to decommission, and what the plan is if the developer stops trading. You will almost certainly never use the answer. Asking the question tells you a great deal about who you are dealing with.
Custom software is slower and more expensive than buying a product, and it is worth it in a narrower set of cases than the people selling it suggest. It is right when configuration genuinely cannot reach the outcome, when the process is a real advantage, and when someone inside the business will own it.
It is wrong when a product could have done it with a week of setup, when the requirement is still changing weekly, and when nobody can name what breaks if you do nothing.
A good partner will tell you which of those you are in, including when the answer costs them the work. If you want the upstream version of that conversation, how to implement AI in your business covers choosing the bottleneck, and the readiness checklist covers the five things worth fixing before you commission anything at all.
Two different things sit under one roof here, and it is worth being clear about which is which.
The Oppermind platform is a subscription product: a workspace with the AI built into real editors, available on every plan, from Free with no card through Starter A$9.95, Pro A$29.99 and Pro Plus A$59.99 a month. If configuration can reach your outcome, that is the cheaper and faster answer, and you can test it this afternoon.
Corporate Solutions is the other thing: custom estimating, compliance, operations and CRM systems, custom AI work, and integration or modernisation of systems you already run — scoped as a project, for organisations where the process really is the advantage. The six families of business system post describes the shapes that work usually takes.
The first conversation is a diagnosis, not a pitch. If the answer is a product you already own, or a fortnight of configuration, we would rather say so.
Whatever you’re here to make, make more of it.
When the process you are automating is the thing that makes you money and is genuinely different from how everyone else does it. If the process is ordinary — invoicing, payroll, email — buy software. Custom earns its cost when configuration cannot reach the outcome, and it is a poor choice when a product could have done the job with a week of setup.
Put it in writing before work starts. Ownership of the source code, ownership of the data, what happens to both if the relationship ends, and whether you can take the system to another developer. A build you cannot move is a build you do not really own, no matter what the invoice says.
Ask for the running cost separately from the build cost: hosting, third-party services, model or API usage, monitoring, security patching, and the hours someone spends supporting it. A build quoted without a running cost is only half a quote, and the running cost is the number that decides whether you still want it in year three.
Long enough to prove the hard part and short enough that the business has not changed underneath it. Insist that the riskiest assumption is tested first rather than last. If the first thing you are shown is a finished-looking interface over an unproven core, the risk has been deferred, not removed.
Nobody inside the business owned it. Requirements were gathered once, the people who do the work were consulted late, and the system was delivered to a team that had no say in it. The technical work is rarely the hard part; the adoption is.
This article is general information about commissioning software. It is not legal, procurement or financial advice, and it does not take account of your circumstances; obtain your own advice before entering a development agreement, and have any contract reviewed by a qualified adviser. Oppermind platform prices are current as at 15 September 2026, are in Australian dollars, and are subject to the plan terms at checkout. Corporate Solutions engagements are quoted individually and are not covered by platform pricing.
Tell us where work is slow, inconsistent or expensive — we’ll identify the most practical place to start, even when the answer isn’t ours to sell.