Custom software: build vs buy, done right

Over the years we have watched companies choose custom software far too early, and other companies wait far too long. Both mistakes are expensive, and both have the same cause: nobody stopped to ask which parts of the product were actually worth building. This guide is what we wish every buyer knew before they signed a contract or started writing code.

Here is the short version. You should build the software that makes your company different, the part that a competitor cannot simply buy ready-made. You should buy the software that everyone needs and nobody notices, like payroll or email. The hard work is telling those two apart honestly, then building the custom part well enough that it pays off for years instead of becoming a cost you keep paying. The rest of this guide explains that decision and the work that follows it.

What custom software actually is

Custom software is software built for one company and one problem, instead of sold to many companies at once. A tool like a payment processor or a help desk is bought. A pricing engine that only your business logic makes sense of is built. Most real companies run a mix: they buy the common parts and build the few things that give them their advantage.

The word "custom" scares people into thinking it means large, slow, and risky. It does not have to. A custom tool can be small. What makes it custom is that it fits your work exactly, because it was made for your work and nothing else. We go deeper on the definition, and on what counts as custom, in what is custom software.

The decision: build or buy

Start every build versus buy question with one test. Is this part of the product something your customers would notice if it were slightly worse than a rival's, or something they would never think about as long as it worked? The first is a candidate to build. The second you almost always buy.

Buying is faster, cheaper up front, and someone else keeps it running. That is the right call for the common parts of any business: accounting, email, chat, storage, identity. There is no advantage in building your own calendar. You would spend a year rebuilding what you could subscribe to in an afternoon.

Building is slower and more expensive at the start, and it gives you something no competitor can copy by paying for it: software shaped exactly to how you work. When your process is the product, an off-the-shelf tool forces you to work the vendor's way, which slowly removes the thing that made you different. We lay out the full framework, with a decision block you can apply to your own case, in build vs buy software.

Two failure patterns are worth naming early. The first is changing your business to fit a tool, month after month, until nobody remembers why the process is so hard. That is when off-the-shelf software fails you, and it is a common reason companies finally build. The second is building something you could have bought, out of pride or a fear of depending on a vendor. Both are expensive. The whole point of this section is to help you avoid both.

The number that actually matters

When people compare build and buy, they compare the wrong number. They put the price of a subscription next to the price of a first build, and building always looks worse. That is not the real comparison.

The real number is total cost of ownership, which is everything the software costs you over its whole life: the first build, then the years of running it, changing it, fixing it, and keeping it secure. Bought software has ongoing cost too, in fees that rise and in the work you do around its limits. Custom software puts most of the cost at the start and then lowers it, because you are not paying a monthly fee for something you own. We explain this in detail in total cost of ownership, and if you want to know everything a build itself costs, the software development cost guide and what custom software costs go into detail.

The mistake to avoid is treating the first build as the whole cost. A cheap build that is hard to change ends up as the most expensive choice, because you pay for it every month for years.

Building it well

Deciding to build is the easy part. Building well decides whether a project succeeds or fails, and it depends on three things.

The first is requirements. Most failed projects were not failed by bad code. They were failed by a plan nobody could describe clearly. You do not need a hundred-page document. You need to be able to say, in a paragraph, what the software must do and why, and then keep that accurate as you learn. We turn this into a method in how to write software requirements, and the founder's job is to remove ambiguity explains why this work belongs to you, not only to the team you hire.

The second is the technology choice. Teams love to argue about the newest tools, and the newest tool is rarely the right one. The right stack is usually the boring one your team knows, the one with a large community and many years of support ahead. Choosing tools because they are new is how you end up with software only one person can maintain. We give you a way to choose in how to choose a technology stack.

The third is avoiding the mistakes that make custom software fail. Scope that never stops growing. Senior decisions handed to junior people. A team that delivers a demo and calls it a product. These are patterns, not bad luck, and you can avoid them if you know them. We collect the ones we see most in how to avoid custom software failure. The most important factor across all three is seniority: experienced people ask the right question in week one instead of month three.

Owning it long term

You never finish software. You keep caring for it for as long as you use it. The day you release it is the start of the part that costs the most, and the part most teams plan for the least.

Custom software needs regular maintenance for as long as you own it. The code libraries it depends on go out of date. Security holes appear. The business changes and the software has to change with it. Skip this and a system that works well slowly gets worse until a small change becomes a large project. We cover how to keep it in good condition without overspending in maintaining custom software.

There is one more risk that shows up years after the build: depending completely on whoever built it or whatever you bought. If only one vendor understands your code, or if your data is stored in a format only one tool can read, you have lost the control that made building worth it in the first place. Owning software means owning the ability to change who works on it. We show you how to protect that in how to avoid vendor lock-in.

Telling commodity from differentiated work

The build versus buy test sounds simple until you apply it to a real product with dozens of parts, some built, some bought, some a mix of both. A better way to sort them is to walk the product piece by piece and ask two questions of each one: does a customer choose you because of this, and could a competitor buy the same version of this that you would buy.

Login, billing, sending email, storing files, scheduling a calendar event: a customer never chooses a company because its login screen is better. These are commodity. Every company needs them, dozens of vendors sell a solid version, and no version of building your own login system makes your product more attractive to a buyer. Buy these without a second thought, and resist the urge to customize them past what the vendor already offers.

The logic that decides which loan a customer qualifies for, the sequence of steps a warehouse worker follows to pick an order, the way a clinic schedules a specialist against a rule only that clinic follows: this is where the differentiation usually sits. It is rarely the whole product. It is often a narrow piece of business logic sitting inside a much larger system that is otherwise ordinary. Find that piece, and you have found the actual candidate for a custom build. The rest of the product around it, the login, the billing, the notifications, still gets bought.

A useful habit is to list every distinct capability the product needs, then mark each one commodity or differentiated before any conversation about vendors or price happens. Do this honestly and most lists come out mostly commodity. That is expected and it is fine. The value of the exercise is finding the two or three items that are not, because those are the only ones worth a custom build, and everything else on the list is a subscription decision, not an engineering one.

Watch for a common trap: calling something differentiated because your team is used to doing it a certain way, rather than because customers actually notice or care. A process being familiar to your staff is not the same as a process being the reason customers pick you. If you removed the custom version and gave your team a well-regarded bought tool instead, would customers notice within a quarter. If the honest answer is no, the process was commodity, and the custom build around it was spending money on the wrong piece.

How total cost of ownership actually adds up

Total cost of ownership is a real number with real components, not an abstract argument for building. Laying out the components side by side is what makes the comparison honest.

For bought software, the components are a subscription or license fee that tends to rise as you use more of the product or add more seats, the cost of the workarounds your team builds around whatever the tool does not do, the cost of migrating away if the vendor changes its pricing or direction in a way that no longer suits you, and the cost of the integration work needed to connect that tool to everything else you run. None of these show up on the price page. All of them show up on your bill within a year or two.

For custom software, the components are the first build, then a steady yearly cost for keeping it maintained, covered fully in maintaining custom software, plus the cost of the people who need to understand the system well enough to change it. There is no rising subscription fee, because you are not renting the software from anyone. The cost curve is front-loaded and then settles into a lower, steadier number.

The comparison people get wrong is putting the bought tool's monthly fee next to the custom build's first-year cost and stopping there. Run both curves out five years and the picture usually reverses: the bought tool's yearly fee, multiplied by however many years you keep paying it, can end up larger than the one-time cost of building and then maintaining your own version, especially once you count the seats you have added and the workarounds you have built. This is not true in every case. Some bought tools stay cheap for as long as you use them, particularly for the genuinely commodity parts of a product. But it is not true by default in the buyer's favor either, which is the assumption most price comparisons quietly make.

The hidden cost of an integration-heavy stack

A common pattern in growing companies is a stack made entirely of bought tools, each one solving one job well, all stitched together with integrations. This looks efficient at first, because every individual tool is fast to set up and each one does its job competently on its own.

The cost shows up as the stack grows. Every new tool is another system that has to stay connected to the others, another login, another place data can drift out of sync, and another vendor whose pricing, support quality, or product direction you do not control. When one tool in the middle of that chain changes its API or gets acquired and re-priced, every integration touching it has to be revisited, often on short notice and at a time you did not choose.

The integrations themselves are a form of custom software that nobody budgeted for as such. Someone has to build them, and someone has to maintain them as each connected tool changes independently on its own release schedule. A company with fifteen connected tools is running fifteen vendors' worth of change management, permanently, whether or not anyone assigned that as a job.

This does not mean integration-heavy stacks are wrong. For the commodity parts of a business, connecting good tools is usually still cheaper than building your own version of each one. It means the cost of "just buy it" is not the subscription fee alone. It includes the ongoing work of keeping a growing web of connected tools working together, and that work belongs in the total cost of ownership comparison, not outside it.

Vendor lock-in has three specific causes

Vendor lock-in usually gets discussed as a general worry about depending on one company. That framing is easy to dismiss, because every business depends on other companies for something. Naming the specific causes makes the risk easier to see and to manage.

The risk has three concrete shapes. The first is data trapped in a format only one vendor's tool can read, so leaving means rebuilding your data, not just switching a subscription. The second is a workflow that only makes sense inside one vendor's product, so your team's daily process would have to be redesigned, not just re-pointed at a new tool, if you ever left. The third is a price or a set of terms that can change without your agreement, where the vendor knows switching costs you more than paying whatever they now ask.

Each shape has a concrete test. Can you export your data in a form another tool could actually use, not just a technical dump. Could a new hire learn your process from a written description that does not name the vendor, or does the process only exist as clicks inside one product. Has the vendor's pricing or terms changed once already in a direction that cost you, and if so, what happens the next time.

For a custom build, the equivalent risk is depending on one person or one small team who is the only one who understands the system. The fix is the same in shape: keep the knowledge documented and shared rather than held by one person, and keep the freedom to bring in a different team if you need to. Both versions of lock-in cost you the same thing in the end, control over your own next move, and the how to avoid vendor lock-in page goes through how to protect it on the custom side.

What owning software long term actually requires

"Own it long term" is easy to say and specific to do. In practice it means a small set of ongoing commitments that have to be in place before the software ships, not added afterward once something breaks.

The first is a person or a team, not a single individual, who understands the system well enough to change it safely. One person who wrote the whole thing and holds it in their head is a single point of failure. The day that person is unavailable, every change becomes slower and riskier, and a departure can turn a working system into one nobody feels safe touching.

The second is a written record of how the system is built and why, kept current as the system changes. Code alone does not explain the reasoning behind a decision made two years ago. Without that reasoning recorded somewhere, each new person who joins has to guess at intent, and guesses are how working systems quietly drift into a state nobody intended.

The third is a routine for the plain, ordinary work: updating dependencies before they become a security problem, checking that backups actually restore, watching for the slow build-up of small workarounds that add up to real complexity. None of this produces a visible feature. All of it is the difference between a five-year-old system that still runs cleanly and one that has become too risky to touch.

The fourth is a budget line for all of the above that exists before launch, not one you discover you need after a security incident or a departure forces the issue. Every one of these is cheaper handled routinely than handled as an emergency, and every one of them is a normal, plannable cost of owning software rather than a sign that something went wrong.

How the build-vs-buy decision changed

For years, this calculation favored buying. Building was slow and expensive, so a custom build had to promise a large benefit to be worth it, and buying was usually the choice.

That requirement is now lower. Work that was clearly not worth building, an internal tool, a narrow workflow nobody sells a product for, an integration between two systems that will never connect to each other otherwise, is now worth building in cases where it plainly was not.

Ownership costs the same as before. Anything you build is yours to run, monitor, secure, and change for as long as you use it, and none of that got cheaper. So the rule still holds, with a lower requirement for building: build what makes you different, buy the common parts, and judge the build decision on what it costs to keep rather than what it costs to make.

Where Reveneau fits

We build the custom part. When a company knows what it needs and wants one team to take responsibility for the whole result, that is a custom software development or full product build engagement. When the plan is still changing and the risk is in getting the direction wrong, we help shape it first. And when a decision to build depends on picking the right team to build with, the choosing a software development partner guide is the companion to this one. If you are weighing build against buy for a specific project, the fastest next step is to talk to us.

Decide honestly, build only what makes you different, buy the rest without guilt, and plan for the years after launch from day one. Do that and custom software becomes the thing that makes your company different from its competitors.