Your business is the integration layer

A field service company with twelve people out on the road runs on something like this. A field service platform for scheduling, quoting and invoicing. Accounting software. A payment processor. Something for email. A shared drive for job photos and documents. And a spreadsheet, because none of the above handles the one thing the business is actually unusual about.

Every one of those is a good product. None of them is the expensive part.

Six systems, six customers

Each of those products has a customer record. So the business has six customers named Thompson Property Group, with six addresses that were each correct on a different date, and six opinions about whether the account is on hold.

Nothing keeps them in step except a person. When a customer moves, somebody changes it in the scheduling tool and either remembers the accounting system or does not. When a payment lands, somebody marks it twice. When a crew photographs a finished job, the photos go to the drive and the link — if anybody makes a link — goes in a note field that nothing can search.

In a large company that work has a name. It is called integration, it has a team, and it has a budget line. In a twelve-person company it has no name and no budget, it is distributed across everybody’s day in ten-minute pieces, and it grows with revenue.

The bill is not nine hundred a month for six tools. It is nine hundred a month for six tools, plus some unmeasured fraction of a salary spent keeping them in agreement.

“Your data is portable” is true and nearly useless

Every one of those vendors will export the data. That is a real commitment and they honour it. What arrives is a set of CSV files: customers, jobs, invoices, payments, each a clean table.

The export gives you the nouns. It loses the verbs. Which quote became which job. Which job generated which invoice. Which payment settled it, partially, in two instalments. Which of the customer’s eleven sites it was for. Those relationships are the business, and they exist as foreign keys inside each vendor’s schema. There is no column in a CSV for “this is the same job as that one over there”.

The lock-in was never the data. It is the joins.

What one system actually means

The mistake, when a business decides to build, is to picture one enormous application that does everything the six products did. That is the version that fails, usually as a single screen trying to serve a dispatcher, a technician on a phone in the rain, and an owner looking at margins.

What it actually means is narrower and more structural. There is one place where the handful of things the business genuinely deals with exist exactly once — the customer, the site, the job, the quote, the invoice, the technician, the piece of equipment — defined once, with real relationships between them.

Everything else is a view. The dispatcher’s morning board, the phone screen with today’s three stops, the Friday invoice run, the owner’s Monday numbers, the page a customer gets with a tracking link: those are windows onto the same objects, not separate products holding separate copies. Adding a seventh view costs a week. Adding a seventh product costs another integration, forever.

The modelling decision the whole thing rests on

Businesses writing their data model down for the first time almost always put the customer at the centre. It feels obviously right. The customer is who signs and who pays.

For service work it is usually wrong, and it is wrong in a way that does not show up until the system is in use.

Take a property management company with forty buildings. The customer is one account. The work is per building. Hang job history off the customer and a technician arriving at building nineteen is handed forty buildings’ worth of history to scroll. Hang it off the site and he gets the three previous visits to that address, including the note about which gate code works and the panel that is labelled wrong.

The same decision appears everywhere, wearing different clothes, and the right answer is rarely the one that matches the invoice:

• A multi-site customer. The contract is with the group; the work, the access notes and the history belong to the location.
• Serviced equipment. If the boiler gets replaced, its service record should follow the boiler, not the building. The asset is the entity and the address is an attribute of it.
• Recurring versus one-off work. A maintenance contract is not a job. It is a thing that produces jobs, and modelling it as a job with a repeat flag is a decision that gets expensive about eight months in.
• The tenant who is not the customer. The person at the door, the person who approves the work and the person who pays are often three people. One contact field means two of them live in a note.

Getting this right is most of the difference between a custom system people reach for and one that is worse than the product it replaced. It is also exactly the decision a general-purpose product cannot make on anyone’s behalf. It has to choose the model that is least wrong across every business that might buy it, which guarantees it is not quite right for any of them.

What per-seat pricing does to the way a business works

This one is subtler than the invoice and does more damage. Priced per seat, access becomes something to ration.

The bookkeeper who comes in two days a week does not get a seat, so she works from exports and her corrections arrive by email. The subcontractor does not get a seat, so he gets texted and somebody enters his work afterwards from a photo of a handwritten sheet. The owner’s partner, who does quotes at the weekend, shares a login, which means the audit trail now attributes her work to him.

Every seat not bought turns into a manual process. None of those processes appear anywhere as a cost. They appear as “how we do it”.

Software a business owns has no marginal cost per person. That sounds like an accounting detail and it is not. The subcontractor gets a login scoped to his own jobs. The bookkeeper gets read-only. The seasonal hire gets an account on day one instead of week three. The data gets better, because the people who actually know things are the ones entering them.

The trap is not software that fails

A tool that does not work gets replaced. That situation is unpleasant and it resolves.

The expensive position is a tool that is eighty-five per cent right. That one gets kept, and the remaining fifteen per cent gets handled by a person with a spreadsheet. The trouble is that the fifteen per cent is rarely trivia. It is usually the pricing rule, the approval step, the way one particular kind of job gets scheduled — which is to say the thing the business does differently from its competitors.

So the differentiation ends up living outside the software, in a file with one owner, no backup and no audit trail. The parts of the operation that are generic are well systematised. The part that is the actual business is held together by somebody’s attention.

The arithmetic, honestly

Rented software is an operating cost that rises with headcount and with whatever the vendor decides to charge next year. Owned software is a capital cost up front and a maintenance cost after — smaller than the build, larger than zero, and never zero.

That means there is a crossover, and it is a number rather than a philosophy. It arrives sooner with more seats, with a longer horizon, and with more of the process falling outside what the product covers. At three people on a standard process it does not arrive at all. At twenty-five seats over five years it has usually already passed, and the business has not noticed because the subscription is a small number appearing monthly rather than a large number appearing once.

None of which makes building the default. What gets given up is real:

• Somebody else’s roadmap. Features arrive without being asked for. On an owned system, nothing arrives that nobody asked for — which is the point, and also a loss.
• Somebody else’s security work. A vendor has people whose whole job is patching, penetration tests and compliance paperwork. That work does not disappear; it moves.
• The ability to leave. A product that disappoints can be cancelled at the end of the month. A system a business owns is the business’s problem.
• Ten thousand other businesses finding the bugs. A mature product has been tested by everyone who uses it. A custom one has been tested by one company.

Building is right when the process genuinely differs, when the gap is being paid for in people’s time, and when the arithmetic clears with room to spare. It is wrong when the product fits and the bill is merely irritating. An annoying invoice for software that actually works is one of the cheapest things a business will ever buy.