Skip to content
Custom Software

When you need custom software and when you don't

Custom software or a standard product? An honest guide: when standard is the right call, when only custom software holds up, and what lies in between.

We make our living from custom-built software. That is exactly why it is in our interest to say it plainly from the start: in many of the conversations we have, the right answer is not "we'll build you something". It is "take a standard product, configure it properly and come back to us when you hit its ceiling".

A vendor who never says "no" is not a partner. It is a bidder.

This article is the test we apply ourselves before any conversation about price. You can apply it on your own.

When you don't need custom software

Your process is no different from your competitors'. Accounting, payroll, email, documents, leave tracking: these are processes that tens of thousands of companies run the same way. There are mature, inexpensive products for them, kept legally up to date by someone else. Building one yourself means paying to reinvent something that already exists, and then paying again to keep it in step with every change from ANAF, the Romanian tax authority.

You haven't used a standard product long enough. The most common situation: the company tried a CRM for two weeks, people didn't use it, and the conclusion was "it doesn't suit us, we need something of our own". More often than not, the problem wasn't the product. It was that nobody decided who uses it, for what, and what happens if they don't. Custom software doesn't fix that. It amplifies it, because now you have paid even more for something nobody uses.

The problem is process or people, not software. If two departments keep parallel records because they don't trust each other, the software that "unifies" them will be worked around just the same. If nobody is responsible for keeping the data clean, any system will be full of duplicates within three months. The same goes for AI: an AI tool brought into the company without rules doesn't put your data in order, it scatters it across personal accounts. Software makes a process faster. It doesn't make it exist.

The missing 10% doesn't matter to your business. Any standard product covers roughly 80-90% of what you need. The question isn't whether something is missing. Something always is. The question is whether what's missing sets you apart in the market or is just a habit. "Our report looks different" is not a reason. "We confirm delivery within 4 hours and customers choose us for it" is.

You want "exactly as it is now, but on the computer". When the requirement is a faithful copy of the current workflow, with all its historical exceptions, the result is expensive software that freezes a process nobody has rethought in ten years. Digitalisation is the moment you rethink the process, not the moment you pour it in concrete.

The budget covers the build but not the upkeep. Custom software is a living thing: it needs hosting, security updates, legislative changes and new requests from the people who use it. If the financial plan stops at delivery, it isn't a plan.

When you do need custom software

Your process is what sets you apart. The way you take orders, plan production, assign teams or calculate prices is the reason customers choose you. A standard product will make you work like everyone else. Sometimes that's healthy. But when the way you work is your competitive advantage, the software has to serve it, not flatten it.

You have hit the ceiling of the standard product. The signs are easy to recognise: Excel files circulating alongside the system, one person who "remembers" rules the system doesn't know, data entered twice in two places, reports assembled by hand every Monday. When the workarounds have become the process, the standard product is no longer helping you. It is slowing you down.

Your systems don't talk to each other. The webshop, the inventory system, accounting, the courier, the bank, e-Factura: each works fine on its own, and your people are "the integration", copying data from one screen to another. Here custom software doesn't replace anything. It connects. And it is, by far, the most common project with an immediate payback that we see.

Romanian specifics aren't covered. Excellent international products stop short at e-Factura (Romania's mandatory e-invoicing system), at SAF-T, at local tax particularities or at the workflows of a regulated industry. Either you patch them with add-ons and consultants, or you build the layer they are missing.

Licences cost you more than building would. Past a certain number of users, a per-user, per-year subscription overtakes, within three years, the cost of your own application that does exactly what you need, without the 200 features nobody uses. The calculation has to cover at least three years, maintenance included, and sometimes it works out, sometimes it doesn't.

You need control over your data and your future. Where the data lives, who has access, what happens if the vendor changes its prices, gets acquired or disappears. For some companies, especially those with contractual or regulatory requirements, the answer to these questions cannot be "it depends on the vendor".

The middle path, which is usually the right answer

In practice, the best projects are neither "all standard" nor "all custom". They are a standard product chosen for what it does well, configured seriously, plus a custom-built layer for the 10-20% that matters: the integrations, the pricing rule, the approval flow, the report management depends on.

The advantage is twofold. The standard part is maintained and kept legally up to date by someone else. The custom part is small: you understand it, you control it, and it costs a fraction of building everything.

What to ask yourself before you sign anything

Whoever you work with, five questions that prevent the most expensive mistakes:

  1. Who owns the code at the end, and where is it stored? If the answer isn't "you, with access to it", you haven't bought software. You've rented it.
  2. What happens if the vendor disappears tomorrow? Is there documentation, is there someone else who can take over?
  3. What do year two and year three cost, not just the delivery?
  4. Who in your company is responsible for the project, has time for it and can make decisions? Without that person, the project stalls at the first unanswered question.
  5. What exactly changes in the company if the project succeeds? If you can't answer in one sentence, it isn't clear to the vendor either.

How we work

We don't start with a quote. We start with a conversation about what isn't working now, and we go through the list above together. Sometimes the conclusion is a standard product and a few days of configuration. Sometimes it's an integration between the systems you already have. And, when it's warranted, it's an application built from scratch around your process, with the code in your hands.

All three are good answers. What makes the difference is choosing correctly before you spend.

If you've reached the point where the Excel files alongside the system have become the system, it's a conversation worth having.