Off-the-Shelf vs Custom Software: When to Choose Which

You buy a CRM because the sales manager can no longer keep up with the notes, and after three months an Excel file with three price lists stands beside the system, together with a folder of invoices that someone copies into the accounts. The product is no worse than what it was sold as, because it knows the customer, the deal and the next call, but it does not know your process, because that process was not what the vendor built for hundreds of companies, and this gap is the whole subject of this article: off-the-shelf vs custom software is not a hole in a feature list that one customisation can fill, but whether you are buying a tool for your process or a process for your tool. If the hole is a connection between systems that already do their job, that is not an argument for a build: we connect what is already there first.

Off-the-shelf vs custom software: when to choose which is not a question about which button looks more modern, and it is not a question of whether you are “big enough to build it yourselves”. Our answer is the same sentence we have written on the service page: if your process fits an off-the-shelf tool, take the off-the-shelf tool, it will be cheaper, and a custom system is justified when the process is part of your competitive edge or ready-made products demand too many compromises, and that sentence is not a sales trick so that we can sell a build afterwards anyway, but a test with which we lose the rows where we would have to write yet another CRM, and keep those where the process is the edge or the off-the-shelf tools demand too many compromises.

This article is not a comparison of shop platforms, because we have already written that elsewhere, and it is not a price list for custom software, because we have no such article and will not have one, since we do not make up prices out of our heads, and it is also not a promise that your own system always wins. We sell both the implementation of an off-the-shelf product and a build from a blank page, and an honest text starts from the fact that sometimes the most expensive service we can sell you is the one you do not need, so what follows is the boundary at which this choice can be made before someone sells you a sprint.

Off-the-shelf vs custom software: when to choose which

Take the off-the-shelf product if the process fits it, and commission software if the process is your competitive edge or the off-the-shelf tools demand too many compromises: that is the whole answer, and the rest of this article is how to test that sentence against a concrete piece of work, not against a slide deck. A comparison that starts with a feature table ends before it has begun, because the table shows what the vendor has named, not who will decide your next change a year from now.

The consequences of the wrong side are not symmetrical, because an off-the-shelf tool into which you have forced your process becomes a subscription plus Excel plus a person who holds the two together, and after a year that person is more expensive than any licence, whereas a commissioned system for a process that already lives in the accounts, the mail application and a standard CRM is a build you will maintain yourselves even though someone else already maintains it on the market. In the first case you have bought a product and then written a second system beside it; in the second you have written a system where a licence would have been enough; and both mistakes keep costing longer than they look in a proposal.

We name this boundary because we have seen both ends in a single week: a company that wanted “its own HubSpot” when what it needed was HubSpot, and a company that spent three years bending a ready ERP around its price table and finally came for that same table as a new project, not because “the ERP cannot do it”, but because the compromises had already outgrown configuration. Neither of those states is the result of bad will, because both start from the sentence “we need a system”, which is not yet a test, and the test begins only when you write the process on one page without a tool’s name and then look for which tool already does that page.

Before a purchase, write down what the system has to do on the first day, what it must not forget in the second year, and who is allowed to change that second year without someone else’s release, because if the answers fit a product that can be configured, take the product. If the question is a catalogue, prices, an order and delivery in an online shop, that is the shop test, and we do not rewrite it here; if the answers are a process a competitor must not be able to buy as an off-the-shelf tool, only then is it worth talking about a sprint. From here this article sells that order, not a tool.

What an off-the-shelf product is, and what custom software is

An off-the-shelf product is software someone has already written for many buyers, which you purchase or subscribe to so that you can use it without a substantial rebuild, and in the Technology Code of Practice guidance on defining your purchasing strategy, updated in November 2023 for UK government buying, that same split is a written decision to build, buy or combine. COTS — commercial off-the-shelf software — we take here as a product you use as it was intended and configure rather than rewrite, and SaaS as software as a service, an application you subscribe to over the internet. Those are planning words for public money, not a duty on a private firm, and we take them here as names already written down, not as a law that imposes a public-sector spend control on you.

Custom software is a system written for your process, and specialised software, in our usage, is software written individually for a particular organisation or sector. We also call it a custom system, on the service page a non-standard system, and in the title custom software, and those are not three products but one piece of work: code that starts from your process, not from the vendor’s assumption about what a customer, an order or an invoice is, so the difference is not “better” against “worse”, but who is afterwards allowed to change that assumption.

An off-the-shelf product is not a failed custom build, and a commissioned build is not a better CRM, because WooCommerce is a ready e-commerce product, Moodle is a ready learning platform, WordPress is a ready content platform, and we sell all three as implementations, not as a hidden build under another name. Laravel is not a product in this sense: it is a framework on which we have written custom systems since version 4.0 in 2013, and it does not give you a catalogue, a cart or a CRM until someone has written them, so to confuse a framework with a product is to imagine that “on Laravel” is already an answer, when it is only a way of writing the answer.

A third thing usually confused at this point is a subscription against ownership, because SaaS means you pay for use and the supplier holds the data, a perpetual licence means you have paid for the right to use a version and updates are often a separate line, and commissioned code that we hand over means the source code, the documentation and the infrastructure configuration are yours. None of those lines wins automatically; there is only clarity about what you are buying, because otherwise a year later you are arguing about whether “the system is ours” when what you actually have is a subscription you can cancel.

The test we use to make this choice

The test is not “whether we like this screen”, but whether the process you must not hand to a competitor fits a tool the competitor can buy in the same shop: if it fits, the tool is the right answer, because it will be cheaper and it will be maintained by someone whose only job is that tool, but if it does not fit, because the price table, the order approval or the delivery terms are what you compete on, then the off-the-shelf product becomes a compromise, and a compromise here means the process starts living in Excel beside the system.

The other side of the same test is too often forgotten, because needs are more often common than unique, and you do not build a mail application, you do not build the accounts that already do what the law requires, and you do not build a standard sales funnel in which a deal is a deal. Bodies that spend their money according to written criteria have named the same shape in other words: first ask whether the thing already exists on the market, and build when the available products do not cover the core or when you need to control the thing yourselves, and that is not a duty on a private firm, and we do not turn it into one, but it is the same shape with which we say no to a build that can be bought.

The third mistake is rebuilding a product until it is no longer a product, because configuration stays within supported limits — the fields, roles and flows the vendor has provided — whereas a customisation that rewrites the core so that the process “finally fits” spends exactly the advantage for which the product was bought: the updates, the documentation, the fact that someone else finds the bug. We have seen this in Moodle implementations, where we first check whether a plugin already exists and only then write our own, and on WordPress sites, where we do not put on an off-the-shelf theme because it brings in dozens of features you do not need and which become a security risk, so a product with someone else’s core is not a custom system but a product from which you have taken the vendor’s core away.

We run this test in a discovery workshop, not on a proposal slide, because on a slide the build that looks like it cares about you always wins, whereas in the workshop the process that can be named wins. If after two days it turns out that the process fits an off-the-shelf tool, we say so, even when that means this week’s deal is not our non-standard system, because an article that always ends with “we will build you your own” is not a test, but a proposal hiding behind a question.

When the off-the-shelf product is the right answer

The off-the-shelf product is the right answer where the process has already been named in the industry and you are not the ones who invented that name, because email, accounts that issue an invoice the way the law requires, a standard sales CRM, a learning platform that records a course and its completion, and a small shop with one price and one warehouse are places where a build gives you nothing worth paying the difference between a licence and a sprint. We do not sell these rows as “a temporary solution until you are ready for the real system”, because they are the real systems for these processes.

We also sell these products, and that is not a hidden promise that a build will arrive a year later: WordPress remains a content platform with a theme we write, not with an off-the-shelf theme from a marketplace; for a small shop with standard processes we ourselves say WooCommerce; Moodle remains a learning platform that we configure, migrate and theme, not invent from scratch. The prices for these rows stand on the service pages and in one place lower in this article, where we need to show that the custom starting figure is not automatically the most expensive line, and here it is enough to say that the product remains a product.

The consequence, if in this place you still commission a build, is not “better control”, but maintenance you no longer share with thousands of others, because someone ships a security patch for a mail application to everyone, whereas the patch for your own mail application you ship yourselves, and that sounds like freedom until the second night on which you have to fix what the vendor has already fixed in their product. We sell that freedom where the process earns it, not where a licence is enough, because otherwise we are selling you work that a year later you will hate as an expensive duplicate.

So the most honest thing we can say before any non-standard estimate is a list of products we would recommend instead: if the process is learning, start with Moodle; if the process is content, start with WordPress; if the process is a small shop, start with WooCommerce; and if the process is invoices and the accounts the law already requires, start with the accounts you already have, and only then ask whether any of that has to become your own system. This list is not a partner agreement; it is a test we use against ourselves.

When custom software is justified

Custom software is justified when the process is part of your competitive edge or ready-made products demand too many compromises, and the process can remain ancillary to the goods you sell and still be part of this test, because the test is the number of compromises, not whether you sell software. If the off-the-shelf product starts to require that you become the average customer, and the average customer is not your competitive edge, a build is at last a test the process has passed, not a wish for your own screen.

Integration is not an argument on its own here, because products have interfaces too, and we connect them, and the argument begins only when the interface is not enough and the process requires that the truth about stock, a price or a status live in one place you control. The Sadales tīkls map portal, which we have built on Laravel and Leaflet, shows outages, free capacity and the connection fee, and that is not “a map plus a plugin”, because the fee and the capacity are the operator’s process, not a field on a maps product; on the Elektrum portal an SSO session attaches to every request before the Vue configurator draws, and that is not “an energy theme on WordPress”, because the session is part of the service, not decoration.

Colour, a logo and the order of a menu are not this test, because those can be done in a product, and we do them in a product: a Moodle theme with your palette, a WordPress theme without the surplus, a WooCommerce shop that looks like you. If the only thing that cannot be done in the off-the-shelf tool is “so that it looks like us”, you have not reached custom software, but a theme, and to confuse those two things is to pay for a build where design would have been enough, and then to wonder why maintenance is expensive for a system whose only difference is colour.

We also do not say that every industry automatically requires its own platform, because the name of the industry is not a test, and the test is whether this industry’s process in your company is the same thing the vendor has already put in the package, or whether it is your way of working in that industry, and that way must not be buyable next door. If it can be bought, buy it; if it cannot, then the conversation is about a custom business system, and only then is it worth talking about a discovery workshop, not about a theme.

The third route: a product with our code on top

Between the off-the-shelf product and a build from a blank page there is a third route, which we also sell and which comparisons most often leave out: the product remains a product, and on top we write what the product does not do, and that is not “a little custom software”, but a decision to leave the core where the vendor maintains it and to write only the layer that is yours. The Sadales tīkls service portal stands on October CMS, and the calculators, calendars and the fault report are work on the product, not a new content engine; in a Moodle implementation we first check whether a grading or reporting plugin already exists, and only then write our own, because otherwise we are selling you a duplicate.

If the question is a catalogue, prices, an order and delivery, that is the shop test, and it has already been written in the article on the WooCommerce or Laravel choice, so we do not rewrite it here and we do not turn it into the default for a non-standard system. If the question is a CRM, an ERP, an internal panel or an industry process, stay here, because a shop is one case of the same test, not the whole content of the choice.

On the WordPress side the third route looks like a refusal, because we do not put on off-the-shelf themes, they bring in features that become a security risk, and we build a clean theme with only what is needed, and that is still a product: the editor writes in WordPress, not in an editor we invented, and updates come from WordPress, not from a release of ours alone. The difference between this and a custom system is that the content process fits the product, but the theme process does not fit a ThemeForest theme, and to confuse them is either to put on someone else’s theme and then wonder about the plugins, or to build your own CMS for content for which a CMS already exists.

This boundary is also the place where we say no to a “small rebuild” that by the third month is the core, because if the customisations become more than the configuration, if every update requires our code first, if the vendor’s field is no longer the truth, you are no longer on the third route. You are on a build that hides behind a product’s name, and then it is more honest to name the build and bill it as a build, because otherwise you are paying for a product you can no longer update, and for a system you cannot yet take over.

Money and time are a shape, not a price list

A custom system with us starts at €8,000, and a full cycle usually takes from 12 to 32 weeks, and that is a starting figure, not an invoice, and 12 weeks are not the same as the first three months in which we promise a usable MVP: the starting term is the shortest build, the MVP is the step after which the system is already in use, and 32 weeks is the upper bound of a larger piece of work, which also sits inside what in the general FAQ we call six to eight months for a large custom system. The Laravel page starts at the same €8,000 and 6–24 weeks, and that is not cheaper custom software: it is a page for someone who already knows the work is Laravel, not a test of whether the work is a build at all.

These figures must not become the sentence “custom software is the most expensive choice”, because a Moodle implementation starts at €15,000, the Pro version of a shop is €9,500, and both sit above the custom starting figure, because one is the implementation of a large product and the other is a shop with a warehouse and B2B prices. To compare the €8,000 start with the Moodle start as “build against product” is the wrong arithmetic, because you can only compare two routes for the same process, and even then both sides are starting figures, not totals; for larger non-standard work we bill for time and materials with a weekly cap, because a fixed price there usually means a mark-up for risk or a fight about scope, and the hourly rate is €50.

A subscription versus a build is also not a formula in which after N years one side automatically wins, and public-sector cost planning names what we also see in private contracts: a SaaS fee can rise with the number of users or with indexation, integrations remain your cost, and a change of supplier needs an exit plan, because the data sits with them. That is not a percentage of the build we would quote here, because the footnote behind those figures leads to vendor blogs, and we do not write numbers of that kind, but the shape remains: a subscription is a line every year, a build is a starting figure plus maintenance, and neither of them is a line that disappears.

The Data Act, which applies in the Union from 12 September 2025, helps you export exportable data from a cloud service and forbids the supplier from putting obstacles in the way of switching, but the functional equivalence it requires is of an infrastructure service, not of a CRM you simply “move”, and Regulation 2023/2854 does not promise that the process will travel with the file. Article 20 of the General Data Protection Regulation (Regulation (EU) 2016/679) ports personal data the data subject has provided, not the application, not your configuration, not the business rules, so if you want a system you can move to another developer, that is the source code we hand over, not an export from someone else’s panel, and this section ends here, because the next sentence would already be a price list we do not have for this question.

What we do not say when we talk about custom software

We do not say that your own system is always the smarter choice, that the off-the-shelf product is for those who “have not grown up yet”, or that after three years the build has certainly paid for itself, because a curve of that kind without your process is an invention. An article that after an honest start still arrives at the claim that you should buy a build has gone too far, and we have seen that often enough to stop here, because honesty is a constraint and a short test is the aim.

We also do not say that Laravel is the answer to the off-the-shelf product question, because Laravel is how we write when the test has already given a build, and to sell a framework to a person who needs Moodle is to sell a hammer to a person who needs a shelf. Our Laravel page starts at €8,000 and talks about APIs, queues and tests, but this article talks about whether you need that page at all, and to confuse the two is to choose the instrument before you have chosen the work.

We also do not say that a discovery workshop is a hidden way of walking you into a build, because the result of the workshop is a plan that stays useful even if you decide not to use us, and sometimes the plan says: take the product you have already named, and we will implement it, or someone else will. If that sentence sounds to you like a lost deal, that is because it is a lost deal, and we would rather lose a build in which we would have to write yet another CRM than gain a client who a year later asks why they are maintaining a system they could have subscribed to.

For public procurement this test does not work the same way as for a private firm: you cannot carry the public-sector test across unchanged, because public-sector planning often asks first whether there is already a ready solution on the market, and that belongs to procurement, not to this sentence, but on the private side what belongs is your process and our price list. Both sides can arrive at the same answer, and they do not arrive at it because one is the other’s law.

How this decision is made with us

The work starts with a two- to three-day discovery workshop in which, together with your team, we go through the processes, the user roles, the risks and the MVP scope, and that is not a morning of slides, but work after which we can say whether the process fits an off-the-shelf tool, whether it needs the third route, or whether it is a build. If the answer is a product, the workshop has paid for itself with that sentence; if the answer is a build, the next step is not code.

Before production code we prepare a clickable prototype in two to three weeks, because changing your mind there is cheaper than in a finished system, and the prototype is not “so that there is something to show the board”, but the place where you see that the price table you named yesterday is in fact another table, and where that discovery costs days, not months. Only then does development begin: in the first three months we build an MVP that can actually be used, and from there we expand iteratively, in two-week sprints with a demonstration after each one.

At the end you receive the source code, the documentation and the infrastructure configuration and can move them to another developer, and that is not a promise that the move will be pleasant, but a promise that you are not locked into our account. On larger projects we stay on time and materials with a weekly cap, and we still fix the MVP boundary, because otherwise “agile” becomes a word behind which the scope disappears, and if after the workshop you take another path, the plan stays yours, as we have written on the service page, and this article does not change that.

Before you write to us, write the process on one page without a tool’s name and mark which rows you must not hand to someone else’s release: if the page is empty or contains only “so that we have our own system”, you need a product, and we will say so, but if the page holds a process a competitor cannot buy as an off-the-shelf tool, then it is worth talking about a build. Write to us if you want us to read that page with you and say which side is yours, even when the answer is to take the product you have already named.