← All insights

Custom software, or a platform that already exists?

The question isn't which one is better, it's where your competitive edge actually is. A criterion to decide without falling in love with the answer.

It's the first question in almost every project, and the one answered worst. Because it tends to get answered with personal taste — "I'd rather have something of our own," "I'd rather not reinvent the wheel" — when in reality there's a fairly objective criterion behind it.

The right question

It's not "which one is better?" It's: is what I want to build where I compete, or is it infrastructure?

Your competitive edge is what you do differently and what your customers choose you for. Everything else — invoicing, sending emails, authenticating users, charging payments — is infrastructure: necessary, but nobody picks you because of it.

The rule we use: infrastructure gets bought, the edge gets built.

It sounds simple and it settles almost every discussion. If you're about to custom-build a billing module, the question is whether your billing has anything unique about it. It almost never does. If you're about to squeeze your differentiating process into a platform that doesn't account for it, you're going to spend years fighting it.

The hidden cost of custom-built software

When someone compares, they usually compare the license price against the development cost. That comparison is wrong, because custom software doesn't end the day it ships:

  • It has to be maintained. Dependencies get updated, browsers change, vulnerabilities show up.
  • It has to be documented. If only one person understands it, you have a risk.
  • It has to be operated. Backups, monitoring, someone available when it goes down on a Sunday.

None of that is in the initial budget, and all of it exists. A custom system is a multi-year commitment, not a purchase.

The hidden cost of a platform

And the same thing happens on the other side:

  • The ceiling. Everything goes fine until you need something the platform doesn't support. That's when the patches start, and patches break with every update.
  • The leak through integrations. Many platforms solve 80% and the remaining 20% gets covered with third-party apps. Each with its own monthly cost, its own support, and its own way of breaking.
  • The exit. If you ever want to leave, does your data come out? In what format? This question needs to be asked before you go in, not after.
  • The cost that scales with your success. Many platforms charge per transaction or by volume. The better things go for you, the more you pay.

The model that almost always wins

In practice, the answer is rarely one extreme or the other. It's usually: platform for the infrastructure, custom for the differentiator.

A typical example: the store runs on a well-known platform, but the pricing logic — which is where the business actually competes — lives in its own service that the platform queries. The boring part gets bought, the valuable part gets built, and each piece does what it's good at.

What makes this work is a clear boundary between the two. If your own logic spills into the platform as loose scripts, you've already lost both advantages: you can't update the platform and you can't migrate your logic either.

The questions we ask

When this decision lands on our table, we start here:

  • If this system disappeared tomorrow, what's the part you couldn't just go buy off the shelf?
  • How much of what you're asking for is genuinely different, and how much is "that's just how we do it" out of habit?
  • What happens if this grows 10x? And if it doesn't grow at all?
  • Who's going to maintain it two years from now?

That second one is uncomfortable and it's the most useful. Many processes that look unique are just inherited habits, and adapting them to the standard is a lot cheaper than building software to preserve them.

When we say "don't build it"

We've told people we shouldn't be hired for something. If what you need is an institutional website, a standard store, or a common CRM, there are mature tools that do it better and cheaper than we would.

We'd rather have that conversation upfront than a six-month project that ends up being something you could have bought off the shelf.


In our software factory case studies you'll find projects where custom really was the answer. If you're unsure, get in touch and we'll look at it with this criterion.

Tell us about your projectWhatsApp