When a company plans a new internal system or a customer-facing tool, the same question always comes up: buy a ready-made product, build on a known framework (WordPress for a content site, for instance), or write custom software from scratch. The mistake is treating this as a technology question. It's really about how closely the company's own process matches the process a ready-made system assumes.
The ready-made system
A ready-made system (a popular project management or invoicing tool, say) is the right call when the process it needs to support is close to what most similar companies do. Customisation stays minimal, rollout is fast, and the vendor carries the maintenance burden.
The downside is the mirror image of that strength: the moment the process diverges from the norm at some point, the ready-made system either won't allow the deviation, or only through an awkward workaround. And workarounds accumulate: a spreadsheet next to the system, a separate email thread, a field where people “temporarily” type something else. Once there are more of these than the team can hold in its head, the ready-made system has stopped saving money and started generating cost.
Two things are worth checking up front: can you get your data back out when you eventually switch, and what does the licence cost when three times as many people use it as today.
The framework-based build
A framework-based build (a WordPress site with custom features, or a Laravel-based internal admin tool) offers a middle ground: the framework provides the backbone (login, data handling, an admin interface), and the company's own logic sits on top of it.
That's the right call when the larger part of the process is standard, and there's a clearly bounded part that's genuinely different from everyone else's. The key word is bounded. If the “custom part” runs through every screen in the system, then it isn't an addition. It is the system, and the framework will be an obstacle rather than a foundation.
Custom development
Custom development pays off when the process itself is the competitive edge: the company does better in the market precisely because it works differently from its competitors, and no ready-made system can follow that difference without forcing the company back onto the standard process.
It's the most expensive and slowest path, but the only one where the software reinforces the company's own method instead of pushing it toward a generic one. “Custom” does not mean everything is written from scratch. The lower layer of the system (permissions, users, audit logging) is the same here as anywhere else. The uniqueness lives in the layer above it.
How to decide
Four questions are usually enough:
- Where do we actually differ? If the answer is “barely anywhere, mostly in terminology”, buy the ready-made system.
- Is the difference bounded? If yes, that points at a framework-based build.
- Is the difference the competitive edge? If yes, that is what pays back the price of a custom build.
- What happens in three years? Can the data come out? Who do you call when it breaks? A decision is sound when its sequel is imaginable too.
The most common mistake
It isn't choosing wrongly. It is asking the question backwards: the technology is picked first, and the process is bent to fit afterwards. Then, after rollout, it turns out the daily work doesn't fit inside it, and the company either routes around the software or gives up a practice that was working perfectly well.
