← Notebook
Over the past year, I have built a slightly unreasonable number of tools.
Dashboards. Search tools. Reporting views. Small applications that join information together, identify patterns and answer questions that would previously have required a spreadsheet, three meetings and somebody who knew where the bodies were buried.
I have built enough of them to make my browser tab bar look like a governance failure.
AI has made much of this surprisingly easy.
Describe the job clearly. Give it access to the data. Build a rough version. Test it with people who understand the work. Improve what matters. Remove the parts that seemed clever at 10 pm but make considerably less sense the next morning.
With frontier LLMs, it is now possible to build a useful interface over an existing dataset in hours, or even minutes. You can generate a dashboard for a particular team, create a natural-language search tool, combine records from several systems or test an idea before beginning a traditional software project.
The code is rarely the hardest part anymore.
The hard part is getting to the data.
That changes the meaning of an old piece of business advice:
Data is your moat.
The phrase usually means that proprietary data creates a defensible advantage. The more useful information an organisation collects, the harder it becomes for competitors to reproduce its products, insights or decisions.
There is truth in that.
But a moat is only useful if you are on the right side of it.
The value has moved
For years, organisations accepted fairly rigid software because building alternatives was expensive.
A vendor supplied the application, the interface, the reports and the approved ways of working with the information inside it. If you needed a different view, you submitted a request. If you needed a new report, you waited for the next release, hired a specialist or discovered that the feature was available in the enterprise tier for only slightly more than the GDP of a small island nation.
AI is changing that calculation.
This does not mean enterprise software has become easy. Security, identity, data quality, support, integration and change management have not packed their bags and gone home.
It means the cost of turning accessible data into a useful tool has fallen sharply.
As that happens, more of the value moves away from the interface and towards the information underneath it.
Which makes access rather important.
The drawbridge goes up
Some vendors appear to have noticed this shift and reached an understandable conclusion.
If customers can freely use their own data, they may build things the vendor would prefer to sell them.
So the drawbridge goes up.
Bulk exports become awkward. Useful fields disappear from standard extracts. Historical information is difficult to retrieve. Updates arrive once a day when the work needs them in minutes. API access moves into a higher-priced tier. Rate limits make technically available data operationally useless.
Then a toll booth appears in front of the bridge.
You can access the information through an API, an integration product or, increasingly, an MCP server that allows AI tools to interact with the platform. There may be usage limits, licensing restrictions, additional fees or a carefully controlled list of things you are permitted to ask.
This is a remarkably creative interpretation of 'your data'.
To be clear, APIs and MCP are not the problem.
Organisations need governed interfaces. Authentication matters. Permissions matter. Auditability matters. A system that provides unrestricted real-time access to everything is not open. It is an incident waiting for a calendar invitation.
The real question is whether the interface gives the organisation practical, timely and reasonably complete access to its own information.
An API can be a bridge.
It can also be a toll booth painted to look like one.
Extracts prove the opportunity, and expose the limit
I have built plenty of useful tools from managed extracts.
That experience has convinced me of two things.
First, organisations are sitting on far more usable value than most of their standard systems reveal. Once the information is available in a form that can be queried, joined and explored, AI can help create views for specific roles and decisions surprisingly quickly.
A generic vendor dashboard might tell you what happened.
A tool built around your actual work can help you understand why, show where attention is needed and connect the result to the next action.
That is a meaningful shift.
Second, extracts have a ceiling.
They work well for historical analysis, management reporting, prototyping and questions where yesterday's data is good enough. They become less useful when the tool is expected to participate in live operations.
The moment somebody asks:
- Has this changed since the last extract?
- Can I act on this record now?
- Can the tool update the source system?
- Can it react when something happens?
- Can I trust this answer during a live customer conversation?
You discover who controls the drawbridge.
I can prove that the tool works.
I cannot make stale data current through force of personality. I have tried glaring at the extract. Its refresh schedule remained unmoved.
Ownership is not the same as access
Most organisations would say they own their data.
The contract may say so too.
But ownership becomes a slightly philosophical comfort if the organisation cannot retrieve that data completely, continuously and in a form it can use.
The practical test is not, 'Do we legally own the data?'
It is:
Can we use it, when we need it, without asking the system that stores it for permission every time?
That does not require every employee to have direct database access. Nobody is helped by creating a data free-for-all and hoping governance catches up later. Governance is not famous for its sprint finish.
It does require the organisation to have an intentional data layer beyond individual applications.
A place where information from core systems can be stored, governed, understood and made available to approved tools. A place where common entities and definitions belong to the organisation rather than whichever product currently presents them.
Customer. Employee. Asset. Case. Project. Transaction.
These are not vendor concepts.
They are organisational concepts.
The system of record may manage them. It should not become the only system permitted to understand them.
No visas required
I suspect restrictive vendors are accelerating the response they hope to prevent.
The harder it becomes to use data inside a platform, the stronger the case becomes for moving that data into organisation-controlled stores.
Not as an occasional backup. Not as a heroic migration performed just before the contract renewal. As a normal architectural capability.
That might include managed replication, change data capture, event streams, governed APIs, shared semantic models and carefully designed stores for analytics and operational use.
The specific technology matters less than the posture:
Important organisational data should be able to travel.
With controls, certainly. With identity, lineage, retention and audit. But it should not require a fresh visa every time the organisation finds a new use for information it already generated.
This is not an argument for copying everything into a data lake and declaring victory.
A swamp with excellent object storage is still a swamp.
The organisation needs to know what the data means, where it came from, how current it is, who may use it and which system remains authoritative. AI can make a badly governed data estate easier to query. It cannot make the answers trustworthy.
The aim is not maximum access.
It is maximum useful access under deliberate control.
Check which side you are on
Before adopting or renewing a platform that will hold important organisational data, I would ask:
- Can we retrieve all of our data in a documented, usable format?
- Can we access changes quickly enough for operational tools?
- Are API limits aligned with legitimate use, or designed to preserve product dependence?
- Can approved tools act on the data as well as read it?
- What happens to access, history and metadata if we leave?
- Could we build a new view of this information without buying another module from the vendor?
The answers tell you where the moat sits.
A strong platform should still create value when customers can access their data. Its workflow, reliability, expertise and service should be worth paying for. Captivity should not be the product feature doing the most work.
AI is making the application layer more fluid. New dashboards, interfaces and tools can be built around the needs of a team rather than the limits of a vendor roadmap.
But only if the data can reach them.
Data may well be your moat.