An API where your site, app and jobs see the same data.
For teams whose app, site and a job must read and write the same records. We write HTTP APIs with auth, limits and errors a developer can read. Docs ship with the work.

An API is useful when two screens have to lean on the same truth. Weekboodschappen has an API on Netlify so the Expo app can fetch the week plan and the list. StepQuests shares discovery, booking and admin on the same web stack. We put contracts on paper: which fields are sacred, who may call, what happens when it fails.
Which systems talk, which fields are sacred, and who is allowed to call the API.
Work that is live
Weekboodschappen.nl runs marketing and API on Netlify. The app talks to that for account, plan and list. StepQuests.com bundles booking and admin on the same Next.js app. We do not publish request volumes. What you see is the product: one source for web and app.

Weekboodschappen
Weekly menus and shopping lists for busy households across the Netherlands. The product promise: a first plan in about 3 minutes.
Studio still, generated. This is not a screenshot of the live site.

StepQuests
Self-guided city walks with stories, quizzes and checkpoints. Web for discovery and booking. The app is the route on the street.
Screenshot of the live site, 25 August 2026.
What you get
HTTP endpoints, authentication, rate limits where they belong, errors with a code and a sentence, and docs at delivery. Schema changes in migrations. Secrets in the environment, not in the repo.
How we start
Map which systems talk, which fields are sacred, and who may call. First slice: one flow the web or app can already use. Then the rest in sprints. Breaking changes get named before we roll them out.
When this fits
This fits when more than one client needs the same data, or a partner has to plug in. A marketing site without an app can live on web. Internal screens without a public API live with custom software. The software-fit quiz helps if you are still choosing the shape.
Ready to tell us what you need?
Sketch which systems need to talk. We reply with a contract sketch and a price estimate. Five questions in the quiz if you are still choosing between API, app or web.
Questions about this work
- REST, GraphQL, or something else?
- Usually HTTP JSON, because the app and the site already speak it. GraphQL if the clients ask and the gain is worth the cost. We pick that together, not from habit.
- Do I get documentation?
- Yes. Endpoints, auth, error codes and a sample request ship with the work. Without docs the API is done for us and blocked for your team.
- Can you talk to a system we already have?
- Yes, if that system has a contract or we are allowed to wrap it. If the other side has no API, we name the risk, the same as automation against raw HTML.
- What if the app and the site drift apart?
- Then the API is the source. Versioning or a flag we agree before we remove a field. Weekboodschappen keeps web and app on the same records. That is the point of this work.