A material study in bright daylight. A thick rope of clear turquoise glass strands arches over like a doorway, wound once with a pearl silver band, its feet planted in a rippled pale floor with a second arch continuing off frame.
  1. Home
  2. Insights
  3. Web Applications and Portals
  4. Custom or a platform

Decision guide

When custom softwareis worth building.

Custom is justified when you can name one requirement a standard platform cannot meet and put a number on why it matters. Both halves are needed: a requirement with no number is a preference, and a number with no requirement is a business case for something else entirely.

The three year comparison in this article lists every term on both sides, including the two that are usually left off the build side and the three usually left off the platform side. Written 23 September 2026.

HUREAL / Material studies

The test

One sentencedecides it.

Name one requirement a standard platform cannot meet, and put a number on why it matters. That is the entire test, and its usefulness is in how hard it is to pass dishonestly.

Both halves carry weight. A requirement with no number attached is a preference, and preferences are what produce software that is expensive and slightly nicer. A number with no requirement attached is a business case for something, but not necessarily for this: a large figure for time lost to manual work is usually an argument for changing a process or buying a different platform, not for building one.

A sentence that passes looks like this in shape. A building products distributor in southwestern Ontario prices by contract tier, volume band and freight zone simultaneously, no platform in its category models all three at once, and the mispricing that results is worth a measurable amount per year in margin given away and quotes lost. That is a requirement, it is specific, it is attached to an amount, and it can be argued with. A sentence that fails looks like a wish for something more flexible.

The version of this test that a supplier should run on themselves. If a supplier cannot help you write the failing version of the sentence, they are not running the test, they are running a sales process with a test-shaped preamble. The willingness to conclude that the answer is a platform is the only evidence that the conclusion of custom means anything.

The case for buying

What you are reallybuying from a platform.

A platform is not a cheaper version of software. It is a different product: you are buying the cost of a problem being spread across every other customer who has it. Four things come with that, and all four are genuinely valuable.

  • Someone else carries the maintenance

    Security patching, browser changes, operating system changes, deprecated dependencies and the slow erosion that affects all software. This is a recurring cost that never appears on a build quote and always appears in year two.

    The single most undervalued thing a subscription buys.

  • The roadmap is paid for by everybody

    Features arrive that you did not commission and would not have prioritised, and some of them turn out to matter. A custom system improves only when you pay for it to improve.

    Worth most in fast-moving categories: payments, tax, security.

  • Hiring is easier

    People who already know a widely used platform can be hired, contracted or replaced. People who know your system have to be taught it, and the teaching material is whatever documentation exists.

    A real risk for any business with a small technical team.

  • Regulatory changes arrive as an update

    When a tax rate moves, a consent rule changes or a payment standard is revised, a platform absorbs it centrally. A custom system absorbs it as a change request with a date on it.

    Decisive wherever money or personal information is involved.

Configuration is also faster than construction by a wide margin. Most businesses that think they need custom software need a platform configured properly by somebody who understood the process first, and the difference between a badly configured platform and a well configured one is frequently larger than the difference between a platform and a build.

Where it stops being cheap

Four ways a platformturns expensive.

Platforms do not usually fail. They stop being the cheap option, quietly, in one of four recognisable shapes. Each of these is worth checking against your own situation, because the answer decides whether this year is the year the arithmetic changed.

  1. The seat cliff

    Per-seat pricing is excellent at twenty seats and a different decision at two hundred. The cost scales with the size of the organisation while the value scales with the complexity of the process, and those are not the same curve. The question to ask is what the licence costs at the headcount you expect in three years, not the one you have.

  2. The workaround tax

    A field is used for something it was not designed for, because the platform had no field for the real thing. Then a report depends on the workaround, then an integration depends on the report, and then nobody can change the workaround. The tell is a written rule somewhere that says what to type in a field so that something else works.

  3. The integration wall

    All the data is in the platform, and the only way to get it out is a scheduled file or a manual export. Every subsequent project is priced against that constraint, and the constraint is permanent. This is the failure that most often justifies moving, because it caps everything else the business wants to do.

  4. The process inversion

    The business changes how it works to suit the tool. Sometimes that is an improvement and the platform has taught you something. Sometimes the thing being changed is the reason customers choose you, and it is being traded for a licence fee. Telling those apart is a management judgement, not a technical one, and it is worth making deliberately rather than by accumulation.

Three options

Configure, extend,or build.

This is normally presented as two options and it is three. Extending a platform, by building a piece of software that sits beside it and connects to it, is where a large share of good projects land, and leaving it out of the comparison is how businesses end up choosing between two extremes neither of which fits.

Three approaches to a business system, compared
Compared on Configure a platformSettings and fields Extend a platformBuilt beside it Build itYours end to end
What you control What the settings allow. The part you built, and how it talks to the rest. All of it, including the parts you would rather not think about.
Who fixes it at two in the morning The vendor, under whatever the agreement says. Split, which means the boundary has to be written down in advance. You, or whoever you pay to be on call.
Cost to start Lowest. Often a fraction of the alternatives. Middle. The connection is a real piece of the cost. Highest.
Cost to change in year three Low if the change is inside the settings. Impossible if it is not. Moderate, and confined to the part you own. Moderate, and unconstrained by anyone else's roadmap.
When the vendor changes the price You pay it, or you migrate everything. You pay it on the part you still rent, which is smaller. Not applicable, which is the main thing being bought.
An unusual requirement A workaround, or a feature request with no date. Built, in the part you own. Built.
When it is the right answer The process is ordinary, or could be made ordinary without losing anything. One part of the process is genuinely yours and the rest is commodity. The process is the business, and no platform models it.

Scroll the table sideways to read it.

The arithmetic

Three years,with every term in it.

The comparison people run is build cost against annual subscription, and it is wrong in both directions. Both columns are missing terms, and the missing terms are large enough to reverse the answer.

The platform column, in full

  • Licence over three years, at the seat count you will haveNot the one you have now. Model the growth you are planning for.
  • Implementation and configurationUsually a separate project, and often larger than the first year of licence.
  • Connectors and middlewareThe per-connection fees that appear once the platform has to talk to anything.
  • The cost of the workaroundsSomebody maintains them, and somebody re-explains them to every new hire.
  • The internal administratorA partial role that becomes a real one somewhere around the second year.
  • The exit costWhat it takes to get the data out in a usable shape, which is worth asking about before you go in.

The build column, in full

  • The buildThe number on the quote, which is the only term most comparisons include.
  • Hosting, monitoring and backupsSmall in money, non-optional, and the first thing forgotten.
  • An improvement budgetSoftware that never changes after launch is software the business has stopped using.
  • Security and dependency maintenanceThe work a platform was doing for you, now itemised. It does not go away.
  • Someone accountable when it breaksOwning software means owning its incidents. This is a real line and it belongs in the model.
  • The risk of being wrongA platform that does not fit can be left. A build that does not fit has already been paid for.

Two of those six build-side terms are usually left out by whoever is selling the build, and the last one is almost never stated at all. A comparison that includes them and still favours building is a comparison worth acting on.

The usual answer

Rent the commodity.Build the advantage.

The answer that fits most established businesses is neither column. Keep a platform for everything that is the same in every company of your size, and build only the part that is actually yours.

Accounting is a commodity. Payroll is a commodity. Email, calendars, file storage and the mechanics of taking a card payment are commodities, and a business that builds any of them has spent money to arrive at a worse version of something it could have rented. A commerce engine that handles tax, inventory and payment is a commodity too, which is why rebuilding a storefront on top of one is such a common and such a sensible project: the selling is yours, the money handling is not.

What is worth building is the part a competitor could not copy by buying the same software. A quoting rule that took twenty years to learn. A scheduling constraint specific to how your crews actually work. A pricing model that reflects a relationship rather than a list. Those are the things a platform cannot hold, and they are also the only things worth the cost of holding them yourself.

The verdict, including where it goes against building

If you cannot write the one sentence, buy the platform. Configure it properly, which usually means paying somebody to understand the process before they touch the settings, and revisit the question in two years when the seat count or the integration wall has changed the arithmetic.

If the sentence is about reporting, buy the platform and build the reporting. It is a much smaller project, it does not put your operational data behind something new, and it solves the thing that was actually wrong.

Building is right when the process is the business and no platform models it. That is a narrower category than it feels like from inside a company, and the narrowness is the point of the test.

Questions

Questions peopleactually ask.

  • How do we know custom is justified?

    Write one sentence naming a requirement a standard platform cannot meet, and attach a number to what failing to meet it costs each year. If you and your supplier can write that sentence together, the build is justified. If you cannot, the platform is the answer and saying so should cost nothing.

  • What happens when our process changes after launch?

    It will, which is why the build separates the rules from the code wherever that is possible. Thresholds, approval steps, pricing bands, notification timing and the list of who does what belong in an administration screen rather than in a deployment. What genuinely cannot be separated goes into the monthly improvement work, and the scope should say which is which before it is built.

  • Who maintains it if we stop working with you?

    Anybody competent, which is a design requirement rather than a promise. The build uses mainstream, well documented technology for exactly that reason, the code and the infrastructure sit in your own accounts, and the documentation is written for a developer who has never met us. Being difficult to replace is not a business model worth having.

  • Is open source a third option?

    Yes, and it sits between the two. You own the deployment, the data and the ability to modify it, and you do not own the roadmap or the security response. The honest way to evaluate it is as a platform whose licence cost is zero and whose operating cost is not, and then to ask who in your organisation or your supplier is accountable for applying its security updates.

  • We have already bought the platform. Is that money wasted?

    Almost never. The usual right answer is to keep it for what it does well and build only the part it cannot do, connected to it. A platform that handles money, inventory or records competently is worth keeping even when the experience on top of it has to be replaced, and replacing the experience is a much smaller project than replacing the engine.

Read next

Three that followfrom this one.

The service behind this article

The recommendationthat costs us the work.

A Web Applications and Portals engagement starts by trying to write the one sentence, and where it cannot be written the recommendation is the platform. That recommendation comes with no build attached, and it is made in the first session rather than after a proposal.

The discovery call tries to talk you out of the build first. We map the process with the people who run it, name the requirement a platform cannot meet, and put a number on it. Where no such requirement exists, you get the platform recommendation in writing and nothing to buy from us.

Book a discovery call

More on this subject in the Web Applications and Portals index, and everything else at Insights.

A material study photographed in bright daylight. A tall fan of clear turquoise glass fins rises on the right of the frame with a polished pearl silver ribbon curving through it, standing in a shallow film of still water. The left of the frame is empty pale mint.

Software you own from day one.

HUREAL / Material studies