Build or rent? A guide to owning your software

What owning your software means

Renting software means paying a vendor every month for access to a product that thousands of other companies also use. The vendor decides what it does, what it costs and what happens to your data when you stop paying. In exchange you get something that works on day one and that somebody else keeps running.

Owning means three specific things, and it is worth checking each one, because plenty of businesses that paid for custom software own less than they think.

• The code. It sits in a repository your company can open, with the right to use and change it set out in the contract.
• The data. It lives in a database you can copy in full whenever you like, without asking anyone.
• The accounts. Hosting, the domain name and any services the software depends on are registered to the company, not to a developer or an employee personally.

The price of owning is that upkeep becomes your concern. Somebody has to host it, back it up and change it. You can pay someone to do all of that, and we cover how below, but it never becomes nobody's job.

How to compare build and rent

The mistake on both sides is comparing one month of rent with the whole cost of a build. Use the same period for both. Three years is a sensible one: long enough for growth to show up in a rented bill, short enough to plan.

On the rent side

Start with what the bill scales with. A flat price stays flat. A price per seat follows hiring, a price per unit follows the size of the operation, and a fee per ticket or a share of revenue follows sales. Price the bill at the size you expect to be in each of the three years, not the size you are now. Then add the subscriptions that exist only because the main product lacks something, any set-up fees, and the staff hours spent moving information between systems by hand. Our software bill calculator does the first part of that arithmetic.

On the build side

Count the build, the monthly cost of hosting and upkeep, the time your own people will spend explaining how the business works and testing the result, and the cost of moving your data across. Ask whether changes after launch are included or charged separately, because a business that is alive will want changes.

The question that decides it

How much of the rented product do you use? General-purpose software is built for every customer at once, so any one customer uses a slice of it. If your slice is small and stable (the same few screens, the same few reports, every week) then the thing to be built is much smaller than the thing you are renting. That gap is where owning becomes cheaper. If you use most of the product, there is no gap, and you should keep renting.

Companies of ordinary size are asking this question again and acting on the answer. Two publicly reported examples:

Switching risk, and how to run two systems side by side

Price is rarely what keeps a business on software it resents. Fear of the switch is. That fear is reasonable. A failed cutover in the wrong week can cost more than years of subscription fees. The answer is to avoid the single cutover altogether.

Running in parallel means the new system does real work beside the old one until it has earned the right to replace it. It only works if the rules are set before it starts.

• Name the record of truth. During the overlap, one system is authoritative, and it is the old one. If the two disagree, the old one wins and the difference is a bug to investigate.
• Limit the double entry. Nobody can key everything twice for long. Feed the new system from the old one's exports where possible, and start with one slice of the business, such as one location, one team or one product line.
• Compare on a schedule. Pick the figures that matter, for example orders taken, payments received and jobs completed, and check that both systems agree at the end of each day or week.
• Write the exit criteria down first. Decide in advance what the new system must do, and for how long, before the old one is switched off. A full month end is a common test, since month end is where problems surface.
• Keep the way back open. Do not cancel the old subscription until after the criteria are met, and keep a final export of everything once you do.

Timing matters as much as method. Look at the renewal date and notice period of your current contract, and at your own calendar. Nobody should change a booking system in peak season or a registration system in the week sign-ups open.

Who maintains it

Software does not wear out, but everything around it moves. Hosting has to be paid for and watched. Backups have to run, and somebody has to have tried restoring one. The components the software is built on receive security updates that need applying. Outside services it talks to, such as the payment processor or the text message provider, change their own interfaces from time to time. And the business changes: a new price structure, a new location, a new report the accountant wants.

There are three workable arrangements.

• The builder maintains it for a monthly fee that covers hosting, fixes and changes. This is the simplest, provided you still hold the code and the accounts. It is how we work at Hiro: one flat monthly price, and you own the code and the data and can take both whenever you like.
• An employee maintains it. Sensible for a company that already has technical staff. The risk is that the knowledge lives in one head.
• A different developer maintains it. Entirely possible if the system was handed over properly, with documentation that lets a newcomer deploy a change without calling the person who left.

Whichever you choose, protect yourself against the builder disappearing. Hold the repository, the credentials and a short document that explains where the system runs and how to release a change. Have the contract reviewed by a lawyer so that ownership of the code is stated rather than assumed, because who paid for the work does not settle who owns it.

Data ownership and export

Your customer list, your order history and your records are the most valuable thing in any business system, and they are the part you can lose when you leave a rented one. Find out what you can take while you are still a paying customer.

• Run every export the product offers and open the files. Count the rows against what the screen says.
• Look for what is missing. Notes, attachments, activity history, custom fields and the links between records (which contact belongs to which company, which payment to which order) are the usual gaps.
• Read the agreement for what happens to your data after cancellation, how long it is kept, and whether a read-only period is available.
• Check whether the vendor may contact your customers for its own purposes. For ticketing and booking platforms in particular, this is worth knowing.

Export first, verify, and only then cancel. In that order, always. With software you own, the question does not arise, because the database is yours and a full copy is a routine request.

When not to go custom

A guide that only argues one way is a brochure. There are clear cases where building your own system is the wrong decision.

• The bill is small and flat. If the three-year total is modest and does not grow as you grow, there is nothing to win.
• You use most of the product. Rebuilding a whole mature product is a different undertaking from rebuilding your slice of one.
• The vendor is the network. Card processors, listing channels, marketplaces and online travel agencies are valuable because of who else is connected to them. Nobody can rebuild that for you. Build around them.
• A system is mandated. If a manufacturer, franchisor, league or regulator requires a specific system, it stays.
• Your process is still changing monthly. Custom software fixes a way of working in place. Settle the process first, in spreadsheets if need be.
• Nobody on your side can make decisions. A build needs one person who can say how the business works and sign off the result.
• Specialist regulated functions. Payroll, tax filing and statutory accounting carry rules that change every year. Rent those from specialists.

By industry: what is usually rented, and what can be owned

The reasoning above is the same everywhere. The details are not. Each of these pages covers what one kind of business typically rents, how that pricing scales against it, what we rebuild and what we deliberately leave alone.