The question that comes before all the others
Before choosing a technology, a supplier or a subscription, you have to settle something simpler: is your need everyone's need, or yours? If the way you work is the way your industry works, a vendor has already tooled it better than you would, and maintains it for you. If it isn't, no amount of configuration will close the gap — you'll spend your time working around it.
The trap is that the answer doesn't show up in a sales demo. It shows up in what your team already does, every day, alongside the tool you have.
When off-the-shelf wins, and it often does
This needs saying plainly, because it's true: in several situations, buying existing software is the right call, and building anything would be a waste of time and money.
The clearest case is REGULATED domains, where compliance IS the product: accounting, payroll, certified invoicing. What you're buying isn't a screen, it's the fact that a vendor tracks the law on your behalf and updates the tool at every change. Nobody should rebuild that.
Next come platforms that bring something other than software: a marketplace, a directory, a network of customers. There, the software is the pretext; what you pay for is the audience, and an audience cannot be generated.
Finally, the most common and most ordinary case: your process really is standard. You do what your peers do, in the same order, with the same vocabulary. Everyone's tool is then the right tool, and its price is split across all its customers.
- Regulatory compliance to maintain (accounting, payroll, certified invoicing)
- The platform brings customers, not just screens
- Your process is the industry's, with no particularity
- An established specialist already covers the subject, at a proportionate price
The signal that says the software doesn't fit
You don't need a study to know. The signal is physical, and it's already in front of you: a spreadsheet kept ALONGSIDE the software. Not a one-off export — a living file, updated every week, that someone maintains because the information the team actually needs isn't in the official tool.
The variants of that same signal are just as easy to spot: the “Notes” or “Comment” field carrying the structural information, because no intended field fit; double entry, where the same data goes into two systems; and the sentence that keeps coming up in meetings, “we can't get that out of the tool”.
When those workarounds have lasted more than a few months, they are no longer workarounds: they are the real process, and the off-the-shelf software is its partial piece. The spreadsheet living alongside it is then the best specification you could have — it describes exactly what you track, in your own words.
The cost nobody counts
Off-the-shelf software is rarely compared against its true cost, because two items are invisible on the invoice. The first is workaround time: the hours spent re-keying, gluing exports back together, explaining to a newcomer why they have to look in two places. It appears nowhere and it's paid every month.
The second is per-user pricing. It's reasonable at three people and becomes structural at fifteen — especially when part of the team only needs to read. You end up restricting access to contain the bill, which means deliberately degrading the tool you're paying for.
The honest calculation isn't “subscription price versus application price”. It's “subscription price, plus workaround time, plus the cost of leaving the day you switch”, against the cost of the application and its hosting.
What a custom application actually changes
An application built for your activity doesn't do more things: it does yours. The entities carry the names your team uses, the statuses are those of your real process, and the home screen shows the number you look at on Monday morning rather than the one a vendor judged universal. That's an adoption gain before it's a feature gain.
The second change is about ownership: the code of an application generated by Blueprint Maker is exportable, and the application runs on a standard PostgreSQL database. You aren't renting the right to keep using your own tool — you own it, and you can host it elsewhere.
Two limits have to be stated, otherwise the comparison would be dishonest. A custom application doesn't excuse you from knowing what you want to track: if the need isn't clear, no tool will clarify it. And it doesn't replace regulated software: you don't manufacture your own compliance.
The decision grid
In five lines, with no pointless grey area:
- The subject is regulated and compliance is the product → off-the-shelf, no hesitation.
- Your process is your industry's, with no particularity → off-the-shelf.
- A spreadsheet has lived alongside the software for more than six months → custom application; that spreadsheet is already your specification.
- No vendor covers your trade, or per-user pricing exceeds what the tracking returns → custom application.
- You don't yet know what you want to track → neither, for now: first write down the table you'd like to read every Monday.
Most often, both
The real answer is rarely exclusive. You keep the regulated software for what it does best — keeping the books, running payroll — and you build an application for the operational part it doesn't cover: tracking sites, jobs, members, stock. Each to its own trade.
One honest clarification on that point: there is no automatic connection between the two today. Generated applications do expose an API, but it's protected by the session — there is not yet a key letting another piece of software connect on its own. Data therefore moves through CSV or JSON export, or through direct database access if you host it yourself. And since the code is yours, adding that key remains ordinary development work.
So the right question isn't “which of the two”, but “which part of my activity is genuinely mine”. That part deserves a tool that looks like it; the rest can be bought.