APIs & databases
The layer everything else depends on: a data model that survives contact with reality, and an API other developers can use without asking you what a field means.
What the work covers
Schema design, endpoints, authentication and the operational details that only hurt once you are already live.
Data modelling
Tables, relations and constraints designed around what the business actually does, so the database refuses to hold data that makes no sense.
REST APIs, documented
Predictable endpoints with an OpenAPI spec that stays in step with the code, so integration does not run on screenshots and guesswork.
Authentication and scopes
Tokens, refresh, expiry and per-scope permissions — checked on every request, not just at login.
Migrations you can roll back
Schema changes versioned in the repository and applied the same way in every environment. No manual SQL run from someone laptop at midnight.
Rate limits and idempotency
Retry-safe endpoints and limits that protect the database from a client stuck in a loop.
Backups and restores
Backups configured, and — the part usually skipped — a restore actually tested before you need it.
What you end up with
- An OpenAPI specification and a working reference environment developers can call against.
- Versioned migrations, so any environment can be rebuilt from an empty database.
- Documented authentication, with example requests for each flow.
- A backup and restore procedure that has been run at least once, not just written down.
The stack we reach for
- Node.js
- TypeScript
- PostgreSQL
- Supabase
- REST
- OpenAPI
- JWT
- Vercel Functions
How it runs
Model the domain
Before endpoints, the nouns: what exists, what it relates to and which rules must never be broken.
Agree the contract
The API shape is written and reviewed before implementation, so the consumers can start in parallel.
Build and test
Endpoints with automated tests against a real database, including the failure cases.
Harden and hand over
Limits, monitoring, backups, restore drill, documentation.
Questions we get asked
REST or GraphQL?
REST by default, because it is easier to cache, debug and hand to another team. GraphQL when the client genuinely needs to shape its own queries — we will say which one fits and why.
Can you work with our existing database?
Yes, and that is common. We start by reading the schema and writing down what we find, including the parts that will constrain what we can do.
Who can see production data?
As few people as the work allows. Access is scoped and logged, and we prefer anonymised copies for development wherever the data is personal.