Custom software for hosts: when it pays off

Custom sounds like the grown-up choice and is usually the expensive one. Not because building is expensive, but because maintenance is, and nobody budgets for it up front.

The rule of thumb fits in one sentence: custom pays off when you do something standard software does not know, and you do it often enough to earn the build back. Both conditions, not one.

Key points

• Two conditions: a unique process and enough volume. With only one, a subscription is cheaper.
• The real cost is maintenance, not the build.
• Many custom requests turn out, on inspection, to be an integration between existing systems.
• Software that talks to external APIs ages by itself; unmaintained, it half-works within a year.

The arithmetic nobody does

The comparison most people make is build cost against annual subscription cost. It usually favours custom, and it is wrong.

What belongs in it:

• Maintenance. Every external API you call will change. That is not a fault, it is normal. Someone has to keep up.
• You are the only user. With standard software the whole customer base pays for improvements. With custom, you fund every change alone.
• Knowledge risk. Who knows the code once the builder leaves? With a package that is the vendor, with custom it is often nobody.

Add those three and the line sits higher than the quote suggests.

What often starts as custom and is not

In practice most custom requests come down to one of these three, and none of them is custom:

"I want system A and B to know about each other." That is an integration. Faster, cheaper, and you keep benefiting from both vendors' development.

"I want one overview across all my properties." That is usually a reporting layer over existing data, not a new system.

"I want this to happen automatically." Often an existing feature that is switched off, or a missing connection.

Only when your question is none of these three does custom get interesting.

When it is the right call

There are real cases. A portfolio with a property type that does not fit standard data models. An operational process that sets you apart from competitors and that you do not want to bend to fit the software. A scale at which half a percent of efficiency is worth more than the entire build.

We build for those, but we would rather start by checking whether it really is one.

What to do before commissioning anything

For two weeks, write down which work you do by hand and how often. Not from memory, but while you do it. Almost always one or two actions turn out to eat most of the time, and surprisingly often those are solvable with an integration rather than new software.

If you want to know what your listing itself is leaving behind first: the free scan gives you a score on five components and names your biggest lever.