An off-the-shelf template is faster, cheaper and perfectly sufficient for plenty of companies. For others it's the start of two years of frustration. Three questions that reliably tell the two apart, and what to do with the answer.
There are two ways to get a business system. Take a ready-made template and start working in it, or build a data model around yourself. Marketing usually pushes towards the second, because it sounds more ambitious. Reality is duller, and for plenty of companies the right answer is “template”.
You can tell which in five minutes, with three questions.
Question 1: Do you do it the same way as your competitors?
This isn't about quality, it's about method. If someone joined you from a competitor, would they recognise your process?
Answering “yes, we do it the standard way” means a template will probably fit you. A standard process has a standard data model and somebody has already thought it through on your behalf.
Answering “no, we do it differently” is more interesting - but watch for a trap. Most companies believe they do it differently, when really they just use different names for the same things. A genuinely different process shows up as a step, an entity or a rule that doesn't exist elsewhere.
Question 2: How many things do you keep in spreadsheets on the side?
This is the most reliable indicator in the whole test, because you can't answer it with wishful thinking. Just look at how many spreadsheets or documents run alongside your main system.
- Zero to one - the system fits you. A template will work.
- Two to three - borderline. Look at what's in those spreadsheets; often it's one missing relation.
- Four or more - you have your own system in spreadsheets and the main tool is an archive. A template won't fix this, because that spreadsheet exists precisely because it doesn't fit the standard.
Question 3: How often does your process change?
Not the technology, not the tools - the way you work.
We last changed it five years ago. A stable process can carry an off-the-shelf solution. Adapting once is cheaper than building your own.
We change it twice a year. New service lines, new pricing, new roles. In this case the question isn't whether a template fits you today, but whether it will fit you in eighteen months.
Three questions that decide it
Answer for your company, not your industry. Two “no”s out of three mean a template will chafe before you've got used to it.
Scoring
| Answers favouring your own model | What to do |
|---|---|
| 0 of 3 | Take a template and stop thinking about it. You'll save time and money. |
| 1 of 3 | A template plus a few edits. Check you can make those edits yourself. |
| 2 of 3 | Start from a template, but in a tool where the data model can change. |
| 3 of 3 | Build your own model. A template will only be a source of frustration. |
Note the third row. The most common outcome of this test is neither extreme - it's “start from something ready-made and adapt it”. Which is exactly why the most important property of a system is the one nobody mentions in a quote: whether the data model can be changed after you've started working in it.
The worst combination
A template in a tool where nothing can be changed. At first it looks like the fastest route. Six months in you discover you've built a second system in spreadsheets and can't abandon either of them.
What to verify before deciding
Whatever the outcome, these three are worth establishing before you sign:
- Can a custom field be added? And can someone in the back office do it, or is it a request to the supplier?
- Can two databases that weren't originally related be connected? This is the test that separates genuinely adaptable systems from ones that merely have configurable styling.
- Can we get our data out? At any time, in a structured format, at no extra charge.
When it's worth leaving spreadsheets at all is covered in When a spreadsheet stops being enough. What a data model that grows with the team looks like is in A data model that grows with your team. An overview of ready-made solutions by industry is in the Solutions section. The whole subject of building apps without a developer is covered in the complete guide to no-code and AI development.
Common questions about templates versus custom models
Can we start with a template and move to a custom model later?
Yes, and it's the most common route - provided you chose a tool where the data model can be edited. If not, “move later” actually means moving to a different system.
Isn't a custom model a heavy way to start?
It's usually one afternoon of thinking about what your main entities are and how they relate. You'll do that thinking eventually anyway - the only question is whether it happens before rollout or six months into working around the system.
How do I know I designed the model badly?
By a spreadsheet appearing alongside it. That's a reliable signal that a field, a relation or a view is missing from the system - and at the same time, a precise instruction on what to add.