It ran every morning for two years. Then a field came back with a new word in it.

It had run every weekday morning for two years. Nobody had thought about it since the week it was built. A record came out of one system, got tidied, got a couple of fields filled in, and landed in another. Somewhere over five hundred mornings in a row, without a single complaint.

Then on a Tuesday a field came back with a value it had never seen before. Not a broken value. A perfectly ordinary new one. The company that runs the system had added it, and published it in their release notes. They stayed entirely within the promise they had made about not breaking anything.

The chain did not stop. It did the thing it had been told to do when it did not recognise something. That was to take the last branch. In 2024 that was the sensible thing to do, because there were only three values and the third one was the rare one.

Nine days later somebody noticed.

Nothing terrible happened in those nine days. A few dozen records went to the wrong place and were quietly put right in an afternoon. That is the usual size of this kind of failure. It is also why it is worth writing about. The expensive part was not the mistake. It was the nine days. And the nine days happened because the chain had no way of saying that something unfamiliar had turned up.

This article is about the part of a bespoke build that nobody quotes for, and it is not the code. From the moment the thing works, you own it. And everything underneath it belongs to somebody else.

What custom actually means, and when nothing off the shelf will do

Custom is not a level of ambition. It is a description of where a problem sits. There are exactly four situations where the honest answer is that no product covers it. Three of them are real, and the fourth is the one that costs businesses the most money.

One difference runs under all four, and it is the one a sales conversation blurs. So it is worth setting out on its own. A product solves the version of a problem that enough businesses share for somebody to make a living from it. Everything else is either not a real problem, or is real and too rare to be a market. Only the second of those is a case for building. Telling them apart is truly hard from the inside, because the thing capping your business always feels like it must be everybody's.

The most useful question is not whether a tool exists. It is how many other businesses would recognise the description of the step. If the answer is thousands, look harder for a product before you commission anything. That is because a product with ten thousand customers has already had its awkward edges found by people who were not paying to find them.

The quote covers the part that ends

Here is the shape of the commercial arrangement, and nothing about it is a trick. A build has a scope, a price and a finish date. What happens after the finish date has none of those three. That is not dishonesty. It is incompleteness.

That is not an argument against building anything. It is an argument for reading the quote as what it is. It is the cost of the first stage of something with no last stage.

Of those three, the second catches small businesses hardest. The polite version of it does not land, so here is the direct one. A bespoke automation is often understood by exactly one person. For a year that is completely fine. It is fine in the same way that having one set of keys is fine. The cost of that setup is not paid a bit at a time. It is paid all at once, on the day you need a change and that person is not available. And the size of the bill at that moment is set by how much of the thing was written down. It is not set by how well it was built.

There is a cheap fix, and it is easy to leave out of a scope. It is a written description of what the chain does, kept with the thing itself. It is in the language of the business rather than in the language of the software. It costs an hour at the end of a build. It is the difference between a change and a rebuild.

Everything it stands on belongs to somebody else

The part that surprises people is not that vendors change things. It is how short the promises are when you go and read them. And it is how honest the vendors are about it.

Three companies with more to lose from breaking their customers than almost anybody. All of them publish what they will actually guarantee. And the longest guarantee on that chart is two years. A brokerage does not think two years ahead about the way it runs. It thinks about the way it has always done things. That habit is older than any of these policies.

Read the exceptions rather than the numbers, though, because the exceptions are where the honesty is.

Every clause in that sentence is reasonable. A company should be able to change something to comply with the law, or to close a security hole. Nobody would seriously argue otherwise. The third one is the interesting one. A substantial economic or material technical burden is a judgment the vendor makes about its own business. It is the escape hatch that means twelve months is a policy rather than a contract term you could plan around.

The same clause carries one more thing worth knowing. It is the one that catches builds most often. The commitment does not apply to anything that has not reached general availability. Plenty of truly useful features sit in preview for a long time before they are promoted. And building on a preview is building on something the owner's own policy leaves out of the promise.

Microsoft's modern lifecycle policy has the same shape. It promises a minimum of twelve months' notice where no successor product is offered. And it excludes free services and preview releases from that. Meta's is the tidiest of the three, and the easiest to misread. A Graph API version is guaranteed for two years. But the clock starts on the day the NEXT version ships, rather than on the day yours does. Build against a version that is eighteen months old and you have six months, not two years.

The change that is not a breaking change

There is a shared vocabulary for this. Learning it explains how a build can break on a day when nobody broke anything.

Semantic versioning is a published convention for numbering releases, and a great deal of software follows it. Its rule is three lines long. Increase the major version when you make incompatible API changes, the minor version when you add functionality in a backward compatible manner, and the patch version when you make backward compatible bug fixes. That gives everybody a shared meaning for a number. And it means a responsible vendor can tell you, in advance, when something will hurt.

Now here is the gap. Stripe documents it more clearly than anybody, so it is worth quoting them. In their API reference they separate two kinds of fixed-value field. A closed one has a set of possible values that is fixed and will not grow. An open one can grow. They say plainly that new values can be added as a backward-compatible change without requiring an API version upgrade. Their advice to developers follows from that. Do not assume that the documented values are exhaustive, and write code that handles a value it has never seen.

That is the Tuesday at the top of this page. A vendor described it in advance, in public, as an ordinary thing they will do. Nobody broke a promise. A new value arrived in a field, which was always allowed. And the chain had been written by somebody who assumed the list was finished.

The lesson for anybody commissioning a build is small, and specific enough to ask for by name. What does this do when it meets something it does not recognise? There are only two acceptable answers, and neither is a guess. It stops and tells somebody, or it sets the thing aside for a person to look at. A chain that quietly picks the nearest option is a chain that will one day pick the wrong one for nine days.

Who pays when software does not work

There is an old and useful piece of work on this. It comes from the American standards body rather than from anybody in the industry.

Read the chart's note for what that estimate does and does not rest on. What matters here is the direction of the split. When software does not work, the great majority of the cost lands on the business using it.

That is true of anything you buy, and it is true twice over for something built for you alone. A product with ten thousand customers has ten thousand people who might hit a fault before you do. It also has a vendor with a commercial reason to fix it. A build with one customer has you, and the fault is found on the day it costs you something.

There is a second reading of that ratio which is worth having in front of you during a quote. The people selling you a build are not the people who will carry most of the cost when it goes wrong. That is not a criticism of anybody's integrity. It is simply who ends up carrying it. It is the reason the questions further down this page are all about what happens afterwards, rather than about what gets made. And it is the reason a builder who offers those answers before being asked is worth more than one who is cheaper.

None of that is a reason not to build. It is a reason to insist the thing tells you loudly when it is unhappy. That costs almost nothing while it is being made, and it returns more than anything else on this page.

The number this page will not print

There is one statistic anybody who has read about this will have seen. It is the share of a system's total lifetime cost that goes on maintenance rather than on building it. The usual range quoted is somewhere between sixty and eighty percent. It is quoted so often that it has the feel of a settled fact.

It is not printed here. The reason is a check rather than a shrug.

The figure traces back to two places. One is a survey of data processing organisations published in Communications of the ACM in 1978. The other is an article in IT Professional in 2000. The 1978 paper is certainly real, and its catalogue record is there, with a publication date on it. Neither could actually be read. Both sit behind a publisher's wall that did not open for this article, in a browser or otherwise.

So nobody writing this page can tell you what was really measured, on how many systems, or in what industry. Those studies come from a decade when software was written and put to work in ways that no longer exist. A number nobody can check is not a cautious estimate. It is a rumour with a citation attached.

There is a second thing missing from this page for a related reason. It is more interesting, because the source IS readable. A much reproduced table in software economics shows the relative cost of fixing a defect at each stage of a project. The cost rises steeply the later it is found. It appears in the same standards report the chart above comes from. Its own caption reads Example Only. It is an illustration the report uses to explain the idea, not a measurement of anything. Drawing it would have been a fabrication with a footnote.

What can be said honestly is narrower, and it is enough. Maintenance is not a small share of what a build costs over its life. Anybody who has owned one will recognise that. And no number worth printing exists for how large a share it is.

What makes a bespoke build survivable

Five properties, and every one of them is cheap at the beginning and expensive to add later.

It fails loudly. The ending to plan for is not an error. It is silence, and silence looks exactly like having nothing to do. Something has to shout, somewhere a person actually looks.

It refuses rather than guesses. When it meets a value, a document or a case it does not recognise, it puts it aside for a person. This is the same rule every other build on this site rests on. It is the one that prevents the expensive kind of failure rather than the annoying kind.

It is described in your own words. One page, kept with it, saying what it does and why. It is in the language somebody in your office would use. This is what turns the next change from a rebuild into a change.

It has a named owner. Not somebody who looks after the code. A person in your business who would notice it stopping, and whose job it is to care. Where there is nobody, there is no build worth making.

And it has a review date. A date in the calendar, once a year, where somebody asks whether this is still worth having. That is the only mechanism that ever retires anything.

What happens on the day you want to change it

Every conversation about a build is about the first version. There is nearly always a second version, because businesses move. What the second version costs is decided almost entirely by choices made during the first. And almost none of those choices feel important at the time.

The first is whether the rules live in one place or are scattered through the thing. Say the decisions are gathered in one step, written the way a person would write them. Then a rule can be changed by somebody reading it and editing a line. Say the same decision is written in four places, slightly differently. Then it cannot be changed at all until somebody finds all four again. And finding them again takes longer than writing them did.

The second is whether anybody can see what it did. Say a build keeps a plain record of every run, what came in, what it decided and what it wrote. Then anybody can debug it. A build with no record has to be reproduced before it can be understood. And reproducing something that only happens when a particular kind of record arrives is most of the work.

The third is the one people find hardest to hear. The more the first version was made to fit exactly how you worked in the month it was written, the more expensive the second version is. That is because every special fitting is a thing the next change has to be careful of. There is a real tension here, and it should be said out loud rather than smoothed over. The case for building rather than buying is precisely that it fits you, and fit is also what makes it hard to change. The answer is not to build something generic, which would defeat the point. It is to be specific about the rules and plain about everything else.

None of this is exotic engineering. It is three habits. They cost nothing during a build. And they are the difference between a second version that takes an afternoon and one that gets quoted as a rebuild. Ask for them by name.

When not to commission one at all

Four situations, and none of them are about the technology not being ready.

When the process is still moving. A chain wired to a way of working that is being redesigned spends its life being rewired. And the rewiring is not cheaper than the build was. Wait until the shape has stopped changing. Judge that by whether anybody has moved a step in the last few months, rather than by a date.

When you cannot describe it in a paragraph. Not because a builder needs the paragraph, but because being unable to write it means the decision inside it has not been made. And software will make that decision for you by accident, and then hide it.

When nobody would notice it stopping. This is the shortest test in this article. It removes more candidates than any of the others. Something nobody would miss for a month is one of two things. Either it is not worth automating, or it is worth automating and nobody has been made responsible for it. Both of those are answered before a build rather than by one.

And when the honest reason is that a product exists and you do not like it. Sometimes that is a real reason, because a tool you will not use is worth nothing. More often it is an expensive way to avoid a fortnight of getting used to something.

How to test a builder before you hire one

Four questions, and the first two are worth more than everything else you could ask.

Ask what it does when it meets something it does not recognise. Listen for whether the answer contains a person. Anything that describes a sensible default is describing the failure at the top of this page. The follow-up question is what the default was chosen against, and who decided.

Ask how you would find out it had stopped. Where the answer is that the missing output would tell you, ask what that output looks like on a quiet week, and watch what happens.

Ask what happens to it if this relationship ends. The answer should involve the thing running somewhere you control. It should be described somewhere you can read, in a form somebody else could take over. Anything that lives only in an account of theirs is a build you are renting.

Ask what they would talk you out of. A builder with nothing on that list has either never seen one of these go wrong, or is not going to tell you about it.

What it costs, and how long it takes

The build splits into two shapes with very different prices. Which one you have is decided by the systems rather than by the logic.

Where every system involved has a decent published way in, the work runs to days instead of weeks. A good share of it is agreeing the rules rather than writing anything. That is the boring, good version of this work.

Sometimes something has to read a document, or deal with a system that has no proper way in, or wait on an office that is not yours. Then the price is set by that obstacle and not by the rest. Treat it as its own project, with its own shape. And treat any quote offered before the obstacle has been looked at as a guess.

Then there is the running cost, and it has two parts that are usually rolled into one. The infrastructure is small. This kind of thing does not use much of anything. The ownership is the real number, and this article does not quote it on purpose. That is because it is your hours and not our invoice. Size it with the calculator above rather than with a guess. And if the answer looks small, that is because it is small per year and permanent.

What it does not do, and should not pretend to

It does not spare anybody from understanding the work. Automating a step you cannot explain moves the confusion rather than clearing it up.

It does not survive a process that keeps changing. A chain wired to a workflow that is redrawn every month spends its life being rewired. That cost is real, and it comes round again and again.

It does not take the person out of the steps that need one. Any step that guesses where it ought to have asked will, on some future day, be confidently wrong to a client's face. And it will leave a record of it.

It does not protect you from other people's release schedules. It exposes you to them, permanently. That exposure is part of what you are buying, rather than a risk somebody can price away.

And it does not retire itself. Nothing does. Only one thing ever switches one of these off. It is a date in somebody's calendar, plus a person willing to ask the question on that date.

Common questions, answered honestly

What is custom automation, in plain terms?

It is a chain of steps built around how your business really works, rather than a product you configure. The pieces are ordinary and mostly already exist. They are reading from one system, and checking or enriching something. They are applying a rule you decided, and writing into another system. And they are telling a person when it cannot go on. What makes it custom is the arrangement and the rule, both of which are yours.

Why would anybody build this rather than buy something?

Because a product solves the version of a problem enough businesses share to be worth making a living from. And the step capping you is often not that version. The honest order is to look hard for a product first, and to build only where the search truly comes up empty. That is because a product with thousands of customers has had its awkward edges found by people who were not paying to find them.

When should I not commission a custom build?

Four cases. The process is still being redesigned. You cannot describe the step in a paragraph, which usually means a decision has not been made. Nobody in the business would notice it stopping. Or a product exists and the real objection is that you would rather not learn it. The third one removes the most candidates, and it is the quickest to check.

What happens when the software it connects to changes?

Usually nothing, occasionally something. The awkward middle case is a change that is not officially a breaking change at all. Vendors are allowed to add new values to fields without changing an API version. They say so in their own documentation. That is why the most important thing to specify in any build is what it does when it meets something unfamiliar. And it is why the only good answers involve stopping and telling somebody.

Who fixes it when it breaks on a Friday night?

Ask that before you sign anything, because the answer is a commercial arrangement rather than a technical one. What matters more is that most of these failures are not urgent in the way an outage is urgent. The honest requirement is usually that somebody notices within a day, not within an hour. Which is why loud failure is worth more than a fast response.

Who owns it if we stop working together?

You should, and it should be true rather than promised. That means it runs somewhere you control, using logins that are yours. And there is a written description of what it does, in language somebody else could pick up. A build that lives only inside a supplier's account is a build you are renting, whatever the invoice says.

How is this different from workflow automation?

The workflow article on this site is about finding the steps worth connecting, and what the manual versions cost you. This one is about what happens after one has been built. It is about who owns it, what it stands on, and what it costs every year afterwards. Same parts, different question. And the second question is the one that decides whether the first one was worth answering.

Is it worth it for a one or two person business?

Sometimes, and the deciding factor is not headcount. It is whether the step is frequent, whether the underlying rule has really been decided, and whether anybody would notice it stopping. A two person business often scores better on the first two than a larger one. That is because the rule lives in one head and is truly steady. It scores worse on the third, because there is nobody spare to be the person who notices.

What to do about it

One page, tonight, and it is not a specification.

At the top, the step you would most like to hand over. Write it as a paragraph you could give to somebody starting on Monday.

Underneath, every system it would have to touch, by name. Count anything with its own login.

Underneath that, one name. It is the person who would notice if it silently did nothing tomorrow.

If the middle list is long and the bottom line is empty, you have not found a build yet. You have found something that has to be decided first, and deciding it costs nothing.