If you're having custom business software built, settle three things in writing before you sign. Your business should own the source code and intellectual property. The hosting and admin accounts should be in your business's name. And there should be a clear support arrangement, plus documentation good enough that another developer could pick the system up. With those in place, the software is an asset you control for the long run. Without them, you can end up paying for a system you can't change, move or fix without the people who built it.
This post is for owners and finance managers who've already decided custom software may fit. If you're still weighing build versus buy, our build vs buy decision framework covers that decision.
Why these questions matter more than the features
Most custom business software exists to fix a handful of problems:
- information typed in again (double entry, where the same details are keyed into two systems)
- information that stops before it reaches the person who needs it
- systems that disagree
- numbers that arrive too late to act on
A system you don't control can quietly bring those problems back. If nobody can update it when Xero or MYOB changes its API (the connection other software uses to talk to it), the integration breaks and your team goes back to re-keying.
Well-run software lasts. We've been running client systems since 2005. BuildBetter, the purchase order approval system we built for a large retirement living provider, has handled raising and approving purchase orders across that business since 2014. The same client also uses SellBetter, which we built, to manage its home sales process. Systems last that long when ownership, hosting and support are sorted out early.
Who owns the source code and IP
Source code is the human-readable set of instructions the software is built from. Without it, you can run the software but nobody can change it. Intellectual property (IP) is the legal right to own and use that work.
Many buyers are surprised by how ownership works. In Australia, copyright in software generally belongs to whoever wrote it, or their employer, unless a written agreement says otherwise. Paying the invoice doesn't by itself make you the owner. Check the detail with your lawyer, but in practice you want:
- An IP assignment clause. This transfers ownership of the code written for you to your business, usually on payment.
- Clarity on reusable components. Developers often reuse their own building blocks across projects. If they keep ownership of those pieces, you should get a permanent, transferable licence to use them in your system.
- A list of third-party and open-source components. These are libraries written by others, each with its own licence. You won't own them, so you need to know what they are.
- Access to the code repository. A repository is where the code and its full change history are stored, usually in version control software such as Git. Ideally it sits in an account your business owns.
The trap is vendor lock-in, where leaving a supplier is so hard that you're effectively stuck. It's rarely deliberate. It usually happens because nobody wrote these points down.
Who hosts it, and in whose name
Hosting is where the software actually runs. That might be a cloud platform such as Microsoft Azure or AWS, or a server on your premises. The bigger question is whose account it lives in.
We recommend that hosting accounts, domain names and admin logins are registered to your business, with your developer given the access they need. If the developer hosts the system in their own account, the agreement should spell out:
- where the system and data are hosted, and how often backups run
- who pays the hosting bill
- how quickly you can get a full copy of your data and system if you leave
- that your business holds the admin passwords too
For example, if your system pulls jobs from your CRM and posts invoices to Xero, the connection keys for both should be under your control. Otherwise, the day you change developers is also the day your invoicing stops.
Documentation and handover
Documentation is what turns a system from something only the developer understands into something your business owns in practice. It's the same key-person risk (the business depending on one person's knowledge) we cover in only one person knows how it works, applied to software.
At handover, expect at least:
- A plain-English overview of what the system does, the business rules it follows and who uses it.
- A technical guide to how it's built, how it's deployed (put live), where the data lives and how integrations work.
- A runbook, a short set of instructions for routine tasks and for what to do when something goes wrong.
- Access details stored somewhere your business controls.
Use a simple test. Could a competent developer who has never seen the system set it up and make a small change using only the documentation and the repository? If not, the handover isn't finished.
Support over ten years, and if the developer stops trading
Software doesn't stand still. The tools it's built on get security updates, Xero and MYOB update their APIs, and your processes change. Leave those updates too long and you build technical debt (postponed updates and shortcuts that make every later change harder). A sensible support agreement covers:
- what's included (fixes, updates, monitoring) and what's quoted separately (new features)
- how you report problems and how quickly they're answered
- a regular schedule for keeping the underlying technology current
Choosing mainstream, well-supported technology at the start helps too. Boring tools tend to still be maintained a decade later.
Ask every developer what happens if they stop trading. If the code is in your repository, the hosting is in your accounts and the documentation is current, it's an inconvenience rather than a crisis. Some businesses also use source code escrow, where an independent third party holds a copy of the code and releases it to you if the developer goes out of business.
When all of this is sorted, you can log in to your own hosting account, see the code and its history, and open a runbook that explains how it works. If you ever needed to, you could brief a new developer on Monday without asking anyone's permission.
For an independent view of a system you already rely on, our $5,000 Process & Systems Audit maps your processes and systems and gives you a written report. For new builds, see our custom software development service.
Frequently asked questions
Do I automatically own custom software I paid for?
Not necessarily. Copyright generally sits with whoever wrote the code unless a written agreement transfers it. Make sure your contract includes an IP assignment, and check it with your lawyer.
Should the developer host our custom software?
They can. We still recommend the hosting account, domain and admin logins are in your business's name, so you never depend on one supplier to reach your own system or data.
Is source code escrow worth it?
It's most useful when the developer keeps ownership of the code. If you own it and the repository sits in your account, escrow usually adds little.
How much does it cost to support custom software?
Costs vary widely depending on the size of the business, how many systems are involved and how much needs to be custom-built - so we scope every project first and give you a fixed quote after a free initial chat.
Can we switch developers later?
Yes, if you own the code, control the hosting and have proper documentation. Those three things make switching a handover rather than a rebuild.
If you're planning custom business software, or you're uneasy about a system you already depend on, book a free initial chat. We'll talk through ownership, hosting and support for your situation, with no obligation.