Custom software vs. off-the-shelf: what you actually own

Most conversations about custom versus off-the-shelf software get stuck on features, setup time, and monthly cost. Those matter. They also miss the difference that compounds over years, which is whether the software running your business can be taken away from you.

The trap nobody mentions at signup

Picture the automations that quietly keep things moving. The rules that route a lead, flag an overdue invoice, sync two systems, generate the Monday report. On a typical SaaS or no-code platform, those rules live inside the vendor’s product rather than inside anything you hold.

That is fine until one of these happens:

• The vendor raises prices, and your whole workflow is hostage to the new number.
• They deprecate the feature your process depends on, or simplify it out of existence.
• They get acquired or shut down, and your logic goes with them.
• You decide to leave and discover that everything you built is in a format you cannot take with you.

None of this is hypothetical. It is the normal lifecycle of software you do not hold. The work walked in the door with the vendor and it can walk out the same way.

”Just own the IP” is the wrong fix

The usual advice is to buy the copyright. Own the IP and you are safe.

It is a reasonable instinct, and it is wrong in both directions.

Owning the copyright is not sufficient. You can hold the copyright to a system you cannot build, cannot deploy, and cannot hand to another developer, because the firm that wrote it never gave you the repository, the deployment configuration, or the environment variables. Copyright is a legal fact about who is allowed to sue whom. It is not possession, and it is not the ability to keep the thing running on a Tuesday.

Owning the copyright is not necessary either. Most of what runs on the internet right now runs on code its operator does not own. Every company using Linux, PostgreSQL, or nginx is operating on someone else’s copyright under a license, and nobody loses sleep over it. The license is permanent, irrevocable, and public, so there is no scenario where somebody calls and switches it off.

What to ask instead

Ownership is the wrong axis. The useful question is what would have to happen for you to lose access to the thing you depend on. That question has real answers, and all of them live in the license rather than in the sales conversation.

Can it be revoked? A license that ends when the relationship ends is a rental with extra steps. Look for the word irrevocable, then look for what has to be true before it applies.

When exactly does it become permanent? Perpetual and irrevocable are not the same word, and a license can be perpetual while remaining terminable for cause. What matters is the moment after which nobody can take it back, and what you have to do to reach it.

Do you have the code now? Not “will you receive the code at project close.” Do you have it today, in a repository you control, while the work is still happening? If not, everything else is a promise about the future made by someone with an incentive to keep you waiting.

Can you hire someone else? If you need the original firm’s permission before a different developer can touch your own system, you have not escaped anything. You have changed who holds the leash.

What survives the vendor going under? If they file for bankruptcy, can a trustee reject your license and pull the code back? US bankruptcy law has a specific provision about this, and a serious agreement will name it.

Not one of those questions is about who holds the copyright.

What we do about it

We publish the license we use with every client, so you can check all of this before you talk to us. It is here.

The short version: we keep the copyright. You get the complete source code, in a repository you control, from the first week rather than at a handover meeting. You get a license to run it, change it, hire any developer you like, take it with you if you sell the business, and publish it publicly if you want to. Once the build is paid for, that license is permanent, and after that nobody can revoke it. Not us, not a later dispute, not a bankruptcy trustee.

The part that is less comfortable to write down is in there too. We keep the right to reuse our own work for other clients, including your competitors. If you want that restricted, it costs money, because it is us agreeing to turn down work. Components that encode something specific about how you compete get listed by name in your agreement and become your property outright.

When off-the-shelf is still the right call

Not everything should be custom. For email, payroll, or a calendar, off-the-shelf is correct and building your own would be silly. The line is roughly this:

If the software encodes something specific about how your business works, it should be something you can keep. If it is a commodity everyone uses the same way, rent it.

The mistake is renting the parts that are specific to you, then being surprised when the vendor holds the leash.

The bottom line

Ask any software vendor what happens to your system if you stop paying, if you fire them, or if they go out of business. The answer should be in a document you can read on your own time, not a reassurance in a meeting.

If something specific to how your business runs is currently living on someone else’s platform, let’s talk about moving it somewhere you control.