Custom system or an off-the-shelf box: an honest comparison

When the box wins

The box wins when your process is standard and you are prepared not to change it. Bookkeeping, email, room bookings, a simple online shop with no warehouse — hundreds of thousands of users do the same thing you do, and the product has been polished on them. Building your own in that zone is paying for what has already been done better.

The second sign: you can describe what you want using words from the product’s interface. If you recognise your working day in the demo, buy it. If at every step you find yourself saying “it is slightly different for us”, that is the first warning.

The third: you have nobody who will be responsible for the system. A box comes with support, updates and someone else’s responsibility. A custom system comes with yours.

When custom wins

Custom wins where your process is your advantage. If you earn precisely because you do something differently from everyone else, a box will make you do it like everyone else, and the advantage goes with it.

The second zone is hardware. Boxed products for equipment exist, but each is written for a particular set of controllers and acceptors. As soon as something on site is outside that list — and something on site is almost always outside the list — the box either does not see the device or demands that it be replaced. Controllers over Modbus, acceptors over ccTalk and MDB, the acquirer’s terminal, the fiscal service: four worlds, and a box that knows all four in exactly your combination is rare.

The third is integrations. A box has its own list of what it works with. If your warehouse, bank or CRM is on the list, good. If not, you pay for a bridge between the box and everything else, and that bridge is already custom software, only without the benefits of custom software.

The third option: a working system adapted to the process

Between the two extremes is how we work, and, to be honest, how most people who have built applied systems for a long time work. There is a working core — a payment log, controller and acceptor handling, reconciliation, documents, messenger integration. It has been through real operation: 14 million transactions have passed through our payment layer on a car wash network, and 260 orders worth UAH 22.2 million through the messenger sales system. It is not a demo.

But the core is not a product with a fixed interface. It is adapted for each customer: different controllers, a different acquirer, different documents, a different shift logic. The customer gets neither a box nor development from scratch, but a system that already works, with exactly the differences their process actually needs.

What that gives: timelines closer to a box, because most of the code is already written and tested; flexibility closer to custom, because changes are made in code rather than in settings the vendor anticipated. What it costs: dependence on whoever develops the core — and that deserves to be said plainly.

Lock-in: to whom, and by what

Lock-in always exists; the only question is its form. With a box you are tied to the vendor: their prices, their roadmap, their decision to discontinue the product. The data can usually be exported, but a process built around their interface cannot.

With custom software you are tied to the people who know it. If that is one developer with no documentation, the lock-in is stronger than to any box, because a box is at least known to thousands of people.

With an adapted system the lock-in is to whoever develops the core. Three things weaken it, and they belong in the contract: the code belongs to the customer or is licensed to them indefinitely; documentation and server access are with the customer from day one; the system is built on open components any developer knows, not on a proprietary platform only the author understands.

Who owns the code, and what that means in practice

A clause saying “the code belongs to the customer” is useful, but it does not save you on its own. Code without a person who understands it is an archive. Owning the code means something only when another developer can pick it up and continue, and that needs a repository with history, documentation of the part that cannot be understood from the code, and no closed dependencies that do not work without the author.

We hand the code over into the customer’s repository and make sure deployment is described in a script rather than in someone’s head. That is not charity: a customer who is able to leave stays because of the quality of the work, not because there is no exit. That is a healthier relationship for both sides.

Support and the risk of migrating away

A box promises support, but box support answers the question “how do I do X in the product”, not “why does our bay not start after payment”. The second kind of question is the one that costs money, and with a box it is answered by your own engineer or by nobody.

The risk of migrating away should be assessed before the choice, not after. Three questions: can all the data be exported in a readable format; is there anything in the system that only its author knows; how long can the process live without the system if it stops. If the answer to the third is “not a single day”, you do not need the cheapest system, you need the one where you understand how it stops and how it comes back.

The most honest test of any option is to ask to be shown the way out. A vendor who readily shows the export and the documentation is confident you will not want to leave. One who avoids the question knows you will.

Frequently asked