Backend & APIs
The part nobody sees and everything depends on: data, rules, interfaces.
- REST
- PostgreSQL
- Migrations
How it works
The backend holds the rules, not the app. Whatever has to be correct is checked in one place rather than again in every client.
Interfaces you can read
We document the API while building it, not afterwards. Whoever connects later — you, another agency, a partner — should be able to do it without asking us.
A database with history
Every change to the data model is a migration in the source code. That makes every state traceable and lets any environment be brought to the same one. A production database edited by hand is a state nobody can reproduce.
Cushioning third-party systems
Around every external connection we build a layer: timeouts, retries, comprehensible errors instead of forwarded crashes. When the other system fails, your app should explain it rather than fall over.
Permissions in one place
Who may do what lives in the backend. A client can be compromised; a backend still checks — that is the difference between a hidden button and an actual permission.
- Access to systems being connected, including a test environment. Developing against production is not a solution.
- A contact for subject-matter questions who is allowed to decide rules.
A documented API, a database with migrations, and the source code in your possession.
If you skip this
Without your own backend, the app hangs directly off third-party systems. If someone changes something over there, your app stops — and you have no layer at which to absorb it.
Questions about this step?
A conversation costs nothing and takes half an hour. Afterwards you will know whether we are a fit.