The best foundation is often not the product with the longest feature list.
It is the smallest dependable platform that can represent the organisation's work, enforce its rules and support new interfaces without trapping the data inside them.
Do not begin with a software shortlist
Most software selections begin too late in the process.
The organisation creates a list of features, invites vendors to demonstrate them and scores how well each interface appears to satisfy the list.
That makes sense when the interface and the platform are the same decision.
In a Headless system, they are not.
The interface used by a project team next year may not exist yet. An agent may replace a form. A temporary application may support a six-month programme. A reporting experience may move to a different platform.
The foundation needs to survive all of those changes.
Start with the records, relationships and protections that must remain dependable. Then select the technology.
1. Can it represent how the organisation actually works?
A CRM is not just a contact list.
The platform needs to represent the things the organisation works with and the relationships between them. That might include people, organisations, requests, opportunities, projects, cases, commitments, activities, decisions and outcomes.
Ask:
- Can we create the records we really need?
- Can those records be connected without duplicating information?
- Can a record move through a process without losing its history?
- Can the model change as we learn?
- Can important terms and stages be defined consistently?
If the platform forces every kind of work into “contacts and deals”, the organisation will begin creating workarounds immediately.
The data model should reflect the work, not the vendor's sales demonstration.
2. Can every important capability be reached without the standard interface?
This is the defining Headless question.
The platform should provide stable, documented ways for approved applications and agents to find records, create them, update them and trigger workflows.
In technical language, this normally means well-supported APIs, event notifications and authentication. In ordinary language, it means the foundation has doors that other software is allowed to use.
Ask:
- Can an external interface perform the actions our users need?
- Can the platform notify other systems when something changes?
- Are there sensible usage limits?
- Are integrations treated as a core capability or an expensive afterthought?
- Is the documentation clear enough for another team to maintain the connection?
A platform is not meaningfully Headless if every useful action still requires someone to open its own interface.
3. Are permissions enforced underneath the experience?
Small applications and agents should not each recreate the organisation's security model.
The foundation should know who a person is and what they are allowed to see or change. Where necessary, access may need to differ by role, record, department, region or sensitivity.
Ask:
- Can we connect organisational sign-in?
- Can access be limited to the records a role actually needs?
- Can particularly sensitive fields receive stronger protection?
- Do integrations use their own controlled identities?
- Can an administrator remove access quickly?
- Does an agent inherit the user's permissions rather than gaining blanket access?
The interface can be playful. The permission model cannot be improvised.
4. Can we see who did what?
Every operational platform needs a dependable history.
If a field changes, the organisation may need to know its previous value, who changed it, when it changed and which interface or workflow made the change.
This becomes more important when agents and automations are involved. “The AI updated it” is not a useful audit trail.
Ask:
- Are record changes logged?
- Can automated actions be distinguished from human actions?
- Can we see the identity on whose behalf an agent acted?
- Can approval decisions be reconstructed?
- How long is history retained?
- Can audit information be exported for review?
Trust requires inspectability.
5. Can it keep important rules out of prompts and screens?
Some rules should remain true however a person reaches the system.
A financial threshold may require approval. A case cannot close without a recorded outcome. A person in one region may be unable to view records in another. A message may require consent.
These rules should not be copied into every form, dashboard and agent prompt.
Ask:
- Can validation be enforced at the foundation?
- Can multi-step work be represented clearly?
- Can approvals pause an automation?
- Can failures be retried safely?
- Can important actions be reversed or corrected?
- Can rules be tested before release?
The agent can explain the rule. The platform should enforce it.
6. Can it connect to the rest of the organisation?
Headless does not mean isolated.
The operational foundation may need to exchange information with messaging, email, finance, identity, document, analytics and specialist delivery platforms.
Ask:
- Can records be linked to information held elsewhere without copying everything?
- Can inbound messages be matched to the right person and piece of work?
- Can approved audiences be sent to an email platform without creating an unmanaged list?
- Can operational data reach reporting tools?
- Can specialist systems return status and outcomes?
- Is there a clear owner for every connection?
An integration is not finished when data moves once. It is finished when ownership, errors and future changes are understood.
7. Does it meet the organisation's hosting and privacy requirements?
This cannot be added at the end.
The appropriate controls depend on the information involved and the organisation's obligations, but the questions are consistent.
Ask:
- Where are live records, backups, attachments and logs stored?
- Which suppliers can process the information?
- What privacy and retention rules apply?
- Can data be separated by region or business unit if required?
- What certifications or assurance evidence are available?
- How are security incidents reported and handled?
“Cloud” is not a location and “enterprise” is not a security assessment.
8. Can it recover from mistakes and outages?
Operational systems contain living records. People will make mistakes. Automations will occasionally fail. Vendors will have outages.
Ask:
- How frequently is the information backed up?
- Has restoration actually been tested?
- Can individual records or changes be recovered?
- What happens if an integration sends the same update twice?
- Can essential work continue during an outage?
- Who is responsible for recovery?
A system is not dependable because it has never failed.
It is dependable when recovery has been designed.
9. Can we leave?
The organisation should be able to retrieve its records in a complete, understandable and reusable form.
This includes relationships, history and attachments—not only a spreadsheet containing the latest contact fields.
Ask:
- Can all important records be exported?
- Are relationships and identifiers preserved?
- Can attachments and audit history be retrieved?
- Are there additional charges or delays for leaving?
- Does the organisation own its configuration and custom work?
- Could a different capable team take over maintenance?
Portability is not pessimism.
It is part of responsible ownership.
10. Can the organisation maintain it?
A technically elegant platform can still be the wrong choice if only one person understands it.
Ask:
- Who will own the data model?
- Who will review and release changes?
- Which skills are required?
- Can non-technical owners inspect the rules and workflows?
- Are testing and documentation part of the operating model?
- What happens when the original builder leaves?
The platform should be sophisticated enough for the risk and simple enough for the organisation to own.
11. What does it cost to operate, not merely to buy?
Licence price is only one part of the cost.
Count implementation, integration, administration, training, support, change requests, full-user seats, usage charges and the cost of maintaining duplicate records elsewhere.
In our work with larger organisations, individual legacy internal applications are often costing at least $20,000 a year. Within one department, we can commonly identify two or three tools that can be consolidated onto one operational foundation.
That does not mean every replacement will save the same amount. It means the comparison should be made against the real cost of the current collection, not the sticker price of one product.
Also ask how many people genuinely need a full platform seat. Someone who submits an occasional update or receives a dashboard should not automatically be priced like a full-time administrator.
12. Can we prove it with one useful piece of work?
Do not select a five-year architecture from a polished demonstration.
Choose a contained workflow and test the platform with real records, real permissions and real users.
The pilot should prove that:
- the data model can hold the work cleanly;
- an external interface can perform useful actions;
- permissions survive outside the standard interface;
- history and errors can be inspected;
- data can be exported; and
- the organisation can support what has been built.
A foundation earns the right to expand.
When does a large suite make sense?
Salesforce, HubSpot, ServiceNow and other large platforms can be the right foundation when an organisation genuinely needs their packaged capabilities, ecosystem, scale or assurance.
They are not automatically wrong because they are large.
They are wrong when the organisation pays for their breadth but uses only a small collection of records, workflows and reports.
In my experience, that is closer to 90 per cent of the situations in which these platforms are being considered or used.
The direction of the market supports the Headless idea. The large platforms are increasingly exposing records and capabilities to outside applications and agents. Even when an enterprise suite remains underneath, its standard interface does not need to be the workplace for every user.
The decision is no longer “buy the giant application or build everything ourselves”.
We can buy or create a dependable foundation, then build only the experiences the organisation needs.
Bottom line
The right Headless platform is not necessarily the cheapest, newest or most flexible.
It is the one that can hold the organisation's operational history, enforce its protections and make that capability safely available to many simple interfaces.
Choose the foundation for what must remain consistent.
Build the experiences around what can be different.
