There are two ways to build a business application: one where the screen talks straight to the database, and one where the screen is just a client among others, served by the same API as everyone else. The second is the one we practise at Descartes. Here is what it changes, concretely, for the tools you already have — and for the ones you don't have yet.
Two ways to build
In the first, the form writes to the table and the list reads the table. Everything else — the exports, the connectors, the "API" promised in the brochure — comes afterwards, like a service door cut into a load-bearing wall. It covers what the vendor had time to cover. The day you ask for something that isn't there, the answer is a ticket, and the ticket has a date.
In the second, the screen is only a client. Every creation, every read, every update, every deletion goes through an API — the same one for the interface and for anyone else. There is no operation the screen can perform that a script could not perform. That is how the applications we deliver are built, and that difference is what this article is about.
What it means, without the jargon
Our business applications rest on a database exposed through an API, and on an interface that holds no privilege over that API. When a programme officer moves a file from one stage to the next, the screen sends an update request for that file. When a jury member records a score, that is a creation request. When the list of files appears, that is a read request, with filters.
Nothing else happens behind the scenes. There is no second path, reserved for the application, through which data could enter or leave without the API knowing.
Three consequences follow, and they are the ones that matter to you:
The contract is complete by construction. The API documentation is generated from the real schema — objects, fields, relations, permissions. A field added to a form exists in the API the second it exists in the database. It can be read and tried, request by request, in the browser.
Permissions are the same on both sides. A volunteer who only sees the files of her region on screen only sees those through the API, with the same credentials. There is no more permissive "API mode", because there is no API mode at all: there is only the API.
The application cannot hide anything from you. Everything it stores, you can read; everything it can do, you can trigger. That is not a sales argument, it is a property of the architecture — and it can be checked.
The board's spreadsheet, as a second screen
Take the most common case.
A federation processes its grant applications in its application: submission, review, committee, decision. But its monthly committee has grown used to a spreadsheet view — a grid filtered by stage, with a "chair's remark" column that has no place in the official file, and a calendar view for deadlines.
With a closed application, that view is filled in by hand, or from a Monday-morning CSV export that somebody pastes into the spreadsheet. Two sources, a week apart, and soon nobody knows which one is right.
With a complete API, the view synchronises. A script, or an automation tool such as Make or n8n, queries the files at the "Committee" stage every hour and creates or updates the rows. The chair's column stays in the spreadsheet, where it belongs. The file data is never retyped: it comes from the application and can go back to it — a decision taken in the meeting travels back in a single request.
The spreadsheet is only an example. Replace it with Notion, with Airtable, with a management dashboard: the reasoning is the same, because the counterpart is the same — a documented API, with credentials.
The tools you will not replace
The more serious case is that of the tools you already have and intend to keep.
An association has its accounting software, where every grant awarded must be recorded as a commitment. A trade body has its intranet, where the members' directory serves everyone. A company has its reporting tool, built in-house six years ago, which expects a file in a precise format every quarter.
No vendor will ever build a connector for those tools. There is only one copy of each in the world.
That is exactly where "everything goes through the API" stops being an architect's concern and becomes a matter of the tool's survival. Your provider — us, or someone else, or the automation you configure — writes twenty lines that read the files that reached the "Awarded" stage this quarter and drop them in the expected format. Nobody had to be asked. No roadmap had to be waited for. They read the documentation, obtained credentials, and the bridge exists.
And in the other direction: when your intranet creates a member record, it can create the file in the application at the same moment. The person receives their access, the workflow starts, and nobody retyped the company number.
What you gain by not being locked in
The question to ask of any business tool is not "what can it do?" but "what can I make it do without asking permission?".
An application whose API is a service door answers: what was planned. An application whose API is the only door answers: anything you can do yourself.
The difference is also measured the day you leave. All the data — files, evaluations, messages, documents, history — can be extracted in full, with the very requests the application uses every day. That holds for what we deliver too: a tool you can leave without loss is a tool you freely choose to keep.
What the API does not do for you
It would be dishonest to stop there.
An API does not do the integration; it makes it possible. Someone has to write the script or configure the automation, and maintain it when the tool on the other side evolves. It is work — less than a year of double entry, but work, and we cost it with you.
API credentials are a key. They open exactly what their holder's role opens, no more, no less; so create a role for the integration, with only the rights it needs, rather than lending a manager's credentials. The rule is the same as for a badge.
And a two-way synchronisation requires deciding, before switching it on, which of the two is right. The API will not decide for you. It will do exactly what it is told, in both directions — which is precisely why it deserves thought first.
The test
Before choosing — a packaged product or custom development, ours included —, ask a single question: does the interface use the same API as the one I am being offered?
If the answer is a list of connectors, you have your answer: the limits of the tool, listed in advance. But if the answer is yes, and you can see it for yourself in the documentation or in a request on a file you know, that will show you not only what the tool can do today, but what you will be able to make it do yourself, on top, tomorrow.