Buy the product, or build the panel?
We tell some of the people who approach us not to build. If a product already does the job, installing it and working on top of it is almost always faster and cheaper. Custom software starts where the off-the-shelf product stops. This note is about finding that line.
The question is not custom versus ready-made
The decision is not about the kind of software. It is about who owns the process.
If the work you do is done roughly the same way by everyone in your industry, a product has already been written for it, and every line written for you alone is trying to relearn the detail that product accumulated over years. Accounting, payroll, e-invoicing and basic CRM all sit in that category.
Some processes really are yours, though: the rule that sets a price, who signs a job off, which exception applies when. That is not an industry standard, it is how your company operates.
An off-the-shelf product meets that kind of process only by being bent, and the usual result is that people use the product while running the actual work in a spreadsheet beside it.
Where the product wins
- The work is standard and tied to regulation. When the rules change, the vendor ships the update instead of you. That alone is a serious load lifted.
- You need to start tomorrow. Installation takes days, building takes weeks.
- Few users, simple process. A panel written for a team of five often costs more than the licence it replaces.
- You have no integration need, or the product's own integrations already cover it.
If three of those describe you, use the product properly for two weeks before you talk to a software company. A good share of every “we need something custom” request comes from never having opened the product's second screen.
Where building wins
- The process is spread across several tools and a person carries the data between them. Every copied field is a place an error will appear.
- The product's logic and yours disagree, and the team keeps escaping into a spreadsheet to get around it.
- The data is sensitive to you and you need to control where it sits.
- You will open the same work to your own customers. A customer-facing screen is usually the weakest part of a product designed for internal use.
Two of those four make the conversation worth having. All four, and you have already lost whatever efficiency the product was bought for.
- Time to start
- Days for a product, two to six weeks for a built panel. There is no way to close that gap, so accept it before budgeting.
- First-year cost
- The product is usually cheaper. What decides the crossover is seat count and licence model, not the hourly rate of development.
- Third-year cost
- A licence repeats every year and grows per seat. A built panel is paid once, with maintenance on top. The table often turns here.
- Speed of change
- With a product you wait on someone else's roadmap. In your own system a rule can change the same week.
- Exit risk
- Leaving a product, you can export the data but not the process. In your own system the repository and the data are already yours.
Do not price it from the wrong side
Most companies compare the two by putting a licence fee next to a development quote. That comparison is incomplete, because both sides carry costs that do not appear on either document.
On the product side, the hidden cost is the person closing the gap the product does not cover. Someone spending three hours a week stitching a report together is roughly a hundred and fifty hours a year, and those hours never show up on the licence invoice.
On the custom side, the hidden cost is maintenance: going live is not the end of the work, small changes and updates continue.
The honest comparison is total cost of ownership over three years. Put the licence, the build, the maintenance and the hours the process eats into one table. The decision usually makes itself once that table exists.
Four questions before you ask for a quote
- 01Is this process an industry standard, or particular to us?
- 02What work is the team currently doing outside the product, in a spreadsheet?
- 03What is three years of licence, and what is build plus maintenance?
- 04If we had to hand this to someone else tomorrow, how would we hand over the data and the rules?
The fourth is the one most often skipped. Leaving a system handoverable is a decision taken while it is written, not a document produced afterwards. Asking for the repository and the servers to be in your name from day one is not a technical detail, it is commercial cover.
Most jobs land in the middle
In practice the answer is usually not one or the other but a split: accounting and invoicing stay in the product, a panel is built for the process that actually runs your business, and data moves between them. That is not indecision, it is the right division. What matters is that the ownership of each side is written down.
Before commissioning anything, ask one more question: will this work still be done the same way in three years? If yes, and the process is yours, building makes sense. If no, the cheapest answer is the one that gets you through today.