Core vs Configuration: Four Questions to Ask Every Assumption
Every assumption inside internal software has to be sorted into one of four buckets the day a second business signs: universal, configurable, customer-only, or refused. Sorting them is the whole job. Getting it wrong is what turns a platform into twenty projects that share a logo.
The moment this becomes real
While you have one customer, every assumption in the system is free. Your terminology. Your hierarchy. Your approval rules. Your exceptions. Your permission model. None of them cost anything, because there is nobody to disagree with them.
The day a second business signs, every one of those becomes a product question — not once in a planning session, but for each field, each rule, each screen.
The four questions
| Question | If yes | Cost of getting it wrong |
|---|---|---|
| Is it universal? | Core. Fixed once, everywhere. | Something in the core that is not actually shared, forcing every customer to live with one company's opinion. |
| Is it configurable? | A setting, along a dimension you predicted. | A setting nobody uses, or a dimension you did not predict and now cannot express. |
| Is it customer-only? | Their data. Never in the core. | One company's private reality quietly becoming everyone's default. |
| Do you refuse it? | Written down, before the contract. | The one nobody answers — and the reason the roadmap belongs to whoever asked last. |
The fourth question is the one that decides it
Most teams answer the first three. Almost nobody writes down the fourth, and it is the one that determines whether there is a product at the end.
A platform is defined as much by what it refuses as by what it supports.
Without a written refusal list, every request is negotiable, and the roadmap belongs to whichever customer asked most recently. With one, a request that falls outside it is a short conversation rather than a quarter.
How to test an answer
The questions are easy to answer wrongly with confidence. Two checks help:
- The second-customer test. Describe the rule to somebody who runs a similar business and does not work for you. If they say "we do that differently" it is not universal, however obvious it feels from inside.
- The fix-once test. If this were wrong, could you fix it in one place? If the honest answer is no, it is already customisation, whatever the folder structure suggests.
The business object is supposed to differ
The main thing a business manages — the property, the patient, the job, the policy — will differ enormously between verticals, and that is correct. On systems we measured, the central object differed by 41 columns between two installs, and none of that was the problem.
The problem is when the plumbing underneath differs too. Authentication, tenancy, permissions, migrations, deployment and observability should be identical everywhere. When those diverge, the shared core is a naming convention rather than a fact.
Expect the core to be smaller than you think
The intuition is 80% shared, 20% configured. Measured across three real installs it was closer to 25% shared. That is not a failure — it is what an honest boundary looks like once the answers come from code rather than from a diagram. A core that claims more than it holds is worse than a small one, because every customer inherits assumptions that were only ever true for the first.
When you do not need to answer these yet
If nobody outside your company has asked to use the system, these questions cost you time and give you nothing. Sorting assumptions for hypothetical customers is how internal software grows features nobody opens. The questions become urgent the day somebody asks, and not before.
Which rung is your system actually on?
The Platform Readiness Review is seven days and $2,500. A map of what you have built, where the core-versus-configuration boundary really falls, the assumptions that break when a second business signs, and a 90-day plan including what to postpone. If it is not ready to be productized, we say so and you keep the map.