Does custom software still deserve the stigma?

Every complaint about custom software is really a complaint about custom solutions, and the workflow on your sanctioned automation platform is one of those. Of the two, code is the one you can control.

Say you get asked to fix something at work. There is a queue of exceptions, the ones no rule handles, and the person working it is drowning. So you scope out an exception-handling tool. It has to remember how the last cases went, add them up, show a person the options, and let that person decide. Nothing exotic. It has to hold state, keep history, and put a screen in front of somebody.

So how do we build this? Let's consider our options. We can assemble it on the automation platform the company already pays for, one of the drag-a-box-onto-a-canvas tools like n8n or Make.com or Workfront Fusion. Or we can write it as code.

For most of the last decade this was not much of a decision. Code meant typing every line, wiring every integration, writing the test fixtures, and then doing the whole thing again by hand when a rule changed. Dragging a dozen boxes beat that, and it came with things you would otherwise have to build yourself: somewhere to keep credentials, a record of every run, an admin console a stranger could log into.

Things are different nowadays. A coding agent can write v1 in a few hours and any required changes are now nominal. Nothing on the platform side moved at all. You still drag the boxes, you still wire the branches, you still copy the branch again for every kind of case, and you still come back next quarter and do it once more when the rule changes.

And this particular tool is the kind canvases are worst at. It has to hold state across cases, add up its own history, and put a screen in front of a person.

So you write it as code. You build enough of it to demonstrate, and you take it to the meeting.

Your proposed solution is not approved. Nobody in the meeting argues that your version is flawed. The problem is that it's a custom solution, and the company does not do custom. You are instead asked to implement your solution in one of those automation platforms.

Why? Well, custom software is seen as opaque, prone to overengineering, messy, undocumented, invisible to whoever is supposed to be watching the credentials, impossible for an auditor to reconstruct after the fact, and always one resignation away from belonging to nobody. Are these valid? Absolutely. You cannot argue that custom software does not come with these shortcomings.

What I am going to argue is that every gripe on that list is a gripe about custom solutions in general, and that a workflow built on an automation platform is a custom solution. It encodes your company's rules, it was assembled for you, and nobody else on earth runs it. When the builder leaves it belongs to nobody, exactly as advertised. And, crucially, I believe that custom software, when architected correctly from the start, hands an organization more control than the platform version ever will.

Pulling back the no-code mask

Let's take an example. An n8n workflow decides which vendor invoices get paid without a human looking at them: it matches each invoice against its purchase order and its receiving record, releases the clean ones for payment, and routes the mismatches into a review queue with a reason attached. This is typical production automation, the kind of thing that sticks around for years. Now let's say that the builder has left the company. Then a change is required (finance wants a class of invoices held that used to release on their own), and somebody has to log on and try to make the workflow do it.

Every node is visible. Whoever logs on can see filters, mappings, branches, copied expressions, joins, and outputs, all of it sitting there in the open. What they cannot see is where the business rule lives, because it does not live in one place. Part of it sits in a filter, part in a mapping, part in an expression copied into another branch, and part in the shape of the data passed between nodes.

Which piece should be changed? What else depends on it? How do you test the changed rule without touching the live workflow? You can duplicate the scenario, certainly, then edit the copy, reconnect whatever the duplication did not preserve, feed it test data, and remember to carry the successful change back to production. You also have to remember which copy is authoritative (a small administrative detail with an impressive appetite), and whether a later repair was made in the live scenario, the test copy, or both.

The person stuck with the task wants to know why an earlier result occurred. The canvas shows what nodes exist now. It does not necessarily show the reasoning behind the version that ran then, the policy in force at the time, or the sequence of reviewed changes that produced it.

And there you are. This workflow is on the sanctioned platform, built the approved way by an approved person, and every complaint on that list applies to it. The no-code mandate did not prevent this morning and never could have, because it was never a rule about opacity, or ownership, or who you call on a Saturday It was a rule about which tool you were allowed to open. The thing on that canvas is the company's own rules about purchase orders and receiving records, encoded by somebody who is gone.

I can see it all and still understand nothing

I have built these in n8n myself: a city monitoring job that checks about seventy markets every morning for weather, public health, and recall signals, and a domain audit that watches 481 domains, ties each one to what it costs, and found $354 a month going to domains nobody was using. So I am not writing from the position that canvases are toys or that serious people should recoil from boxes connected by lines. Platforms can be excellent. They give admins a centralized place to inspect credentials, and they provide a complete run record for every execution without requiring the builder to configure logging, storage, retention, and access deliberately.

Still, visibility and legibility are different properties. Legibility comes from structure, names, history, interfaces, tests, and some account of why the thing was built the way it was. A canvas can have those, or approximations of them, but the fact that its nodes are sitting there in the open does not supply them.

Let's talk speed for a second. Platforms had a clear speed advantage when writing code meant typing every line, assembling every integration, finding every syntax mistake, creating test fixtures, and revising the result by hand. Coding agents have reduced much of that cost, particularly the cost of producing a first implementation, adding tests, making a bounded revision, and explaining an unfamiliar repository. They have not reduced the cost of dragging a canvas node into place, rewiring branches, duplicating scenarios for tests, or reconciling copies after they drift. LLMs can describe the manual canvas work with great confidence (and most times little accuracy), but the canvas still has to be changed.

Truly useful internal automation has a habit of maturing. A trivial trigger becomes a process that retains state, state becomes history, history invites aggregation across prior cases, and somebody eventually needs judgment, approval, and a genuine user interface. Those are precisely the places where canvas workflows become costly and brittle, while ordinary application code starts to look less like an indulgence and more like the appropriate material.

The admin console still matters

Isn't the platform easier for a stranger to enter? Oh yeah. A new admin can enter one environment, see the scenarios, inspect execution records, find centrally managed credentials, and gain a rough map of the estate. A codebase does not provide that orientation automatically. Somebody has to configure the logs, credential authority, access path, deployment controls, and an index that lists what tools exists.

A complete run record is not forbidden to code. Centrally controlled credentials are not forbidden to code. Reviews, automated tests, deployment approval, and readable change history are especially not forbidden to code. The organization can require those controls and reject any proposal that omits them. What it cannot claim is that a canvas comes with control built in while a repository is barred from having any.

Again, both of these are custom solutions, and both can carry the same operating wrapper: version control, review, tests, readable history, credentials somebody owns, run records, a named owner, and a written procedure. A solution with those is governable. One without them is a wager on memory, whether its logic appears as text or as pastel rectangles. Yes, a platform gives you many of these right out the box. But it sure as hell doesn't mean that your software cannot be built with them.

Procurement likes a platform name

A procurement-friendly requisition is drafted around a platform name because the title looks easier to approve than "developer who can operate this system." The platform specialist appears bounded, certifiable, and legible to a purchasing process, while "developer" sounds like an invitation to build anything at all (including, management fears, an empire with a login page).

That comfort buys access to a thinner labor market. SlashData put the global developer population at 47.2 million in early 2025, and Evans Data, counting only paid professionals, put it at 26 million. Take the lower one if you like. For platform specialists, there is no comparable figure anywhere on the internet. Nobody publishes it.

So, let's look at the job market instead. In late August 2026, 556,464 live job postings from 12,599 employers included 21 automation platforms in 7,716 postings, while five programming languages appeared in 62,132. Python alone appeared in 39,064, more than all 21 platforms combined. (If you're wondering, I maintain a job posting database for another project. It comes in handy for a lot of stuff.)

The platform side of that comparison is stacked generously. It includes ServiceNow, Microsoft Power, UiPath, Workato, MuleSoft, and sixteen others. ServiceNow, the largest single-platform labor market in the data (keep in mind that ServiceNow also extends far beyond its automation platform), appeared in 3,454 postings, and TypeScript still exceeded it. Across employers, 5,621 wanted Python skills, while 204 wanted Workato skills.

What does that mean for the handoff fear? It means the mandate intended to make staffing easier may require rarer and more expensive specialists, while excluding a much larger and more liquid pool of developers who already know repositories, tests, review, deployment, and operational code. The approved title may be easier to write. The replacement may be harder to find.

Nor are the labor pools cleanly separate. 42 percent of automation-platform postings also name one of the five languages, which suggests that many organizations buying platform expertise still want coding skill alongside it. The platform does not remove code from the work so much as put a branded gate in front of some of it.

I would not turn posting liquidity into a claim about the exact number of capable specialists. That number remains unknown. What is known is what employers are asking for, across how many employers, and how much broader the language market is than the named-platform market.

The procurement label is tidy. The labor market is not.

The Saturday test

The above data suggests that you'll have an easier time hiring someone for code rather than hiring someone for a platform. But it does not guarantee that a position will always be staffed. Which brings us to the worst possible case.

Consider a different automation, one where a weekend is not a quiet time. A reordering tool watches stock levels, places the routine purchase orders itself, and escalates the questionable ones to a person. The person who built it does not work here anymore. It's a Saturday, and it begins over-ordering for an unknown reason. Those purchase orders are with the vendors. A purchase order is a commitment, nobody is going to un-send them, and another goes out every time the thing runs. Nobody in the department is an engineer, and there is certainly no on-call rotation.

All of the order confirmation emails are being sent to a manager, who decides that something needs to be done immediately to resolve this. Can they work out which tool is doing it? Can they figure out how to fix the bug? Or at the very least, can they stop the automation without stopping the business? That is the test.

Let's say the reordering tool is an n8n workflow. What does the manager see when they first log in? In all likelihood, a mess of workflows, projects, and folders (there is a reorder_v2, and a reorder_v2_FINAL, and one just called new, and one called Copy of new). They open one. It's a canvas of boxes labeled IF and Merge and Code, joined by lines, and nothing visible on it tells them whether this workflow sends purchase orders to vendors or files a weekly report. They ask Copilot how they should proceed and are told to check for recent failed executions of each workflow. They finally find the right one, and after Copilot tells them how to disable the workflow, the crisis is over.

Then Monday comes around. The reordering tool that the company depends on is now off. Nobody can say what it would have ordered this week. The reorder points and the quantities and the vendor preferences live in the workflow, spread across the same filters and expressions nobody could read on Saturday. Back to Copilot, which now suggests exporting the workflow and feeding the JSON back so it can explain the business logic (if it's a platform with no export feature, godspeed my friend). This works, more or less. It's now clear what manual work should be done. But there is still no confidence anywhere that this workflow can be reliably fixed and returned to service. There is no procedure to open, no name in any field anywhere, and nobody whose job this is.

Now suppose the tool had been code and nobody had planned for a bad morning. Again, the builder is gone. Fortunately, we don't have to dive much deeper into this scenario. It goes worse, much worse. It's extremely unlikely that the manager is able to turn the automation off, much less finding and fixing the issue at hand.

So was management right after all?

If you simply compare the two above scenarios, absolutely. We saw the two distinct outcomes: the disabled workflow, and the one that kept ordering all weekend because there was no way in. It all came down to accessibility. And a platform is always more accessible than custom software, right?

Well, not so fast. Custom software built without a care in the world really is that inaccessible, and management is right to be afraid of it. Custom software built with care is another matter.

The platform's accessibility is whatever n8n decided to ship: a login, a list of workflows, an executions tab, and a toggle. That's the whole of it, and it's the same for every company running n8n. It got our manager through Saturday but did nothing for them on Monday, and there's no setting or upgrade that changes that.

With code, you decide how accessible the thing is, and you can go a long way past a login and a toggle.

Start where the damage stops

So build the reordering tool the way the Saturday test demands.

Start with the switch. Somebody in purchasing notices the tool is doing something wrong, and they need one control that stops it without stopping purchasing. That control should not require knowing anything about queues, workers, branches, containers, or whichever technical noun the builder happened to learn that month. It should be obvious, it should be something they're allowed to touch, and it should have been tested.

The emergency path should be one step, and that step is: turn it off and work normally. The manual fallback has to stay intact, the people in purchasing have to know how to use it, and somebody has to practice the switch before an emergency makes the practice exciting. A fallback that exists only in a planning document does not exist.

This simple control brings custom software to the same level of safety as platforms. The tool the company depends on can be pulled out of the path without the department going dark. The operator does not need the original builder to contain harm. And the escalation can happen after the system is safe, when whoever gets the call has enough oxygen to think.

Write for what the operator sees

Say a pilot with fifteen thousand hours gets a warning light they have seen maybe twice in their career. The first thing they do is reach for the quick reference handbook, the QRH, which is organized by what they are looking at: a light, a sound, a smell, an instrument doing something it should not. They find the page, read each line out loud, and the pilot next to them confirms each one. The QRH does not explain how the engine works. It doesn't explain why failures happen. It's there because nobody keeps a procedure they use twice a career in their head, and because people under stress skip steps. It gets them to a safe state without asking them to be brilliant.

Now put the purchasing manager in that seat. They have far less expertise and exactly the same stress, and on Saturday what they were handed was the opposite of a QRH: a canvas, which is a picture of how the system is built. They got anywhere at all by asking Copilot where to look, nothing on the screen told them. The platform can show you the architecture and it can show you the history. It cannot tell you what to do.

With code, you can hand that person a QRH instead, and it does not need to be an aviation-sized binder. Nobody is going to write a page for every way a reordering tool can misbehave, and nobody should. Instead you use the tools you have. A coding agent can do some heavy lifting here, especially in terms of code changes. But it cannot do everything. It cannot get someone to the codebase, the coding agent's UI, or the deployment server. That's where the QRH comes in. In outline the page looks like this, and on the real one every line has a paragraph under it: where the switch actually is, what "nothing new went out" looks like on the screen, the exact thing to paste to the agent, what a passing test run looks like to somebody who has never seen one, and the reviewer's name.

The operator can stop after telling the owner. Purchasing is safe. That is the whole point of the order. Nothing on the page says "restart worker three." That line assumes the operator already knows the diagnosis and the implementation. If they knew that, we would have written a procedure for the person least likely to need it. The maintainer gets the tour of the architecture in the runbook. The page also says what not to do. A nervous person with broad access and an agent offering edits is a remarkably efficient source of new symptoms. That is what the stop at the reviewer is for.

How do you know the QRH works? The same way aviation does. You break the system on purpose and hand it to somebody who did not write it (aviation obviously uses flight simulators instead of real planes, so maybe don't use production). Feed the tool a stock count that makes it order twice and ask the operator to work the page alone. Any step where the builder has to lean over and explain what the page really means has failed the drill. The fault is the page's, not the person's.

Revise the page from the stumble. Then drill it again.

Then there's Monday

Most changes are not emergencies. The floor on one SKU should be forty now instead of thirty. A vendor got dropped. Somebody wants the questionable orders to go to a different person. On a platform the rule and the machinery are the same object. Every one of those changes means opening the canvas and finding the node. That is the same thing that stopped everyone on Monday. There is no document that says reorder when on-hand drops below thirty. There is a filter node with 30 typed into it, sitting among the other boxes. The only way to read the rule is to read the whole workflow. That is not a flaw in n8n, it's just what a canvas is.

Custom software can keep the two apart. It's one of the strongest controls code has and one of the easiest to skip. Hard-coding a threshold feels quick, right up until the first handoff.

So the rules live in a document. The purchasing manager can read it and change it, somebody signs off on the change, and the engine, the code that applies the rules, reads that document instead of carrying the rules inside itself. Every order the tool places records exactly which version of the document it was following, so a later investigator can answer why a result occurred without asking what the current code probably did months ago.

For one order that would read something like: ordered 40 of SKU 2213 because on-hand fell to 22, below the floor of 30 set in policy v14; second vendor skipped, lead time too long. The purchasing manager can read that. So can an auditor.

That "why" has three layers. The run record shows the inputs, the policy version, the rule that fired, the outcome, and whether a human stepped in. The policy history shows what changed and who approved it. The engine's history shows whether the code that reads the policy changed underneath it. Without all three, an auditor ends up running today's policy through today's engine and hoping history was considerate enough to stand still.

The policy document needs tests too. A rule edited into a contradiction should be rejected before it runs. If the new rule is valid but surprising, a preview should show what it would have ordered last month. Code does not give you this by existing. The wrapper does.

This is where the AI fits. It is the Copilot session from Saturday, designed instead of improvised. A "break-glass" skill like this can read the run records, explain which policy applied, compare what happened with what should have happened, and walk the operator through the recovery steps. The skill knows the automation. It has the index, the policy document, and the QRH pages. When a problem comes in, it finds the page and walks the operator through it, one line at a time. When one comes in that has no page, it still gets them to the switch and the owner. It can say what it thinks happened, but that's as far as it goes on its own.

The wrapper has one more artifact. An index: a single page with a row for every tool the company runs, on the platform or off it. Each row says what the tool does, who owns it, and where the aforementioned skill is. The manager determines the automation from this index, gets the skill loaded, and they're off to the races.

That's the answer to Monday, and it's the first place code pulls ahead instead of catching up. On Tuesday the floor on one SKU needs to be forty. The purchasing manager opens the policy document and changes one line, and the next order out says so: forty, policy v15, their initials on the change. Twenty seconds, no ticket, no engineer, no canvas. On n8n that same change is another Monday situation. Find the workflow, find the node, edit it live, hope.

Saturday, again

Same Saturday, same over-ordering, same manager. This time the tool was built the way above.

They open the index. One row says reordering tool, an owner's name, and a link to the skill. They open it and type what they're looking at: purchase orders going out that nobody asked for. The skill finds the QRH for that and reads the first line. Turn it off. The switch lives in the policy document they already edit, so they flip it, and the skill has them check the run record for anything after the last run. Nothing. Purchasing goes back to placing orders by hand. That took less time than Copilot needed to tell reorder_v2 from reorder_v2_FINAL, and nothing they touched needs an engineer to undo.

Next line: tell the owner. The owner left last month and the row still has their name on it. That's the wrapper's first honest failure of the day. But the QRH says the operator can stop here, and they're stopped. Nothing is ordering. Purchasing is working. Saturday is over.

Monday, they pick the QRH back up. Open the repository in the browser, one click. Paste the question to the agent. It reads Saturday's runs and explains before it touches anything: every order fired on on-hand below the floor, and on-hand read zero for forty SKUs in the same minute. Forty SKUs don't hit zero together. A stock feed went blank. Let it fix that on a branch and run the tests, and the QRH says what a passing run looks like.

So purchasing has a bad week. The orders placed before the switch are still a problem, and the wrapper did nothing about those. Somebody has to be given the owner's row.

That's the worst case. Not "the builder left and we're hostage to a black box." A stale name, a branch waiting on a reviewer, and a bad week.

Back to the meeting

Take it back to the room that said the company does not do custom. The company does. It has a workflow called Copy of new to prove it. What the room was actually saying no to was a tool with nobody's name on it, and it was right to.

Don't argue with the fear. Hand them a spec. A custom solution isn't done until a stranger has run the drill and passed, and the same goes for anything on the canvas. Write that down and make it the rule. Pass it and "custom" stops being a risk category. It's a tool with a name on it, a switch, and a page.

Does custom software still deserve the stigma? The stigma is a scar. Every company has a graveyard of scripts with nobody's name on them. But a scar is a record of what happened, not a law about what has to.