APIs, backends & integrations
APIs, backends, and integrations that last
Custom API development for teams building real products and businesses connecting real systems. Documented, authenticated, monitored, and handed over — on your infrastructure, in your name.
What you get
- A documented REST or GraphQL API deployed to your own infrastructure, with your own domain.
- Authentication, authorization, and rate limiting wired up from day one — not bolted on later.
- Structured logging and error monitoring so production problems are visible, not silent.
- OpenAPI or GraphQL schema published alongside the code, kept honest with the implementation.
- A handover runbook covering deploys, secrets, on-call, and the shape of the data model.
- Integration tests that exercise the real boundary, not just unit tests of internal helpers.
- Source code in your GitHub, infrastructure in your cloud, secrets in your own vault.
Who this is for
The first group we help is product teams that need a real backend. The front end lives in Next.js or React Native; the data layer has outgrown a form-to-spreadsheet setup; the next hire depends on having a real API to build against. You don't need a full platform team — you need a stable, documented surface your own engineers can work against, today and a year from now.
The second group is businesses connecting multiple SaaS tools that don't natively talk to each other. HubSpot to the warehouse, the billing system to the ops dashboard, the CRM to the support inbox. The off-the-shelf integrations are thin or nonexistent. You need a small, boring service in the middle — one your team owns, one that logs everything, and one that can be extended without re-doing the whole thing.
How we approach API development
- 1
Design around the real job-to-be-done
A good API is shaped by the workflow it serves, not by the internal table structure. We start by listing the concrete things clients need to do, then design the smallest, most obvious set of endpoints that let them do it. Naming, versioning, and error handling get decided on day one — not during the first incident.
- 2
Write it simply
Most backends do not need a micro-services architecture or a custom framework. We use plain, well-known tools and keep the surface area small enough that a new engineer can read the whole thing in an afternoon. Boring code is faster to change and easier to hand over.
- 3
Test at the boundary
Unit tests of helpers are cheap comfort. What actually matters is whether a real request produces the right response and the right side effects. We write integration tests that hit the API the way clients will, so refactors stay safe and regressions are obvious.
- 4
Document, then hand over
On the last day you get the repository, the deployed API, the OpenAPI or GraphQL schema, and a runbook. Your next engineer can understand how it fits together without us. If you want us to stay on for extensions we're happy to, but there's no default retainer.
What makes our approach different
Simple, sane engineering
We reach for the most obvious framework, the most boring database, and the smallest set of services we can get away with. Complexity is only added when there's a real reason — and we tell you why.
No framework or cloud lock-in
Your API is plain Node or Python on your own AWS, GCP, or Vercel account. If you part ways with us tomorrow the API keeps running, your team keeps deploying, and your clients never notice.
Flat, predictable pricing
We scope the API and quote a flat fee. No hourly billing surprises. You pay for the finished system, not for meetings about the finished system.
Engineer-led, always
You work directly with Eric and the engineer building the backend. No account manager between you and the code, no offshore handoff, no junior guessing at your requirements.
Tech we reach for
Most of our APIs are written in Node with TypeScript using Hono, Fastify, or Express, backed by Postgres. We reach for Python and FastAPI when a workload is data-heavy or the ecosystem fits better — pandas, scientific libraries, machine-learning glue. Hosting runs on Vercel for smaller services or the client's own AWS or GCP account for anything that needs long-running processes, VPC peering, or strict compliance. We pick the simplest thing that safely solves your problem, and we avoid framework lock-in so your next engineer can pick up where we left off.
Common questions
REST or GraphQL?+
REST is the right answer most of the time — it's simpler, easier to cache, and every client library already speaks it. GraphQL earns its place when you have a dozen different client surfaces each needing a different shape of the same data, or when a mobile team is suffering from REST over-fetching. We'll recommend honestly based on your constraints, not on what's fashionable.
Do you build public APIs or internal-only?+
Both. We build internal-only APIs that power a single product, partner APIs that a handful of trusted clients consume, and public APIs that go out to the open internet with docs and rate limits. The engineering fundamentals are the same — auth, validation, observability — the public-facing work just needs more care on versioning, abuse prevention, and documentation.
What about OpenAPI docs?+
Every API we ship comes with an OpenAPI or GraphQL schema published alongside the code, plus a hosted docs site if you want one. We prefer schemas generated from the implementation so the docs cannot drift out of sync with reality. Your downstream consumers get something they can actually point a code generator at.
Can you integrate with legacy systems?+
Usually yes. We've written integrations against SOAP services, SFTP drops, EDI, flat-file batch jobs, vendor APIs with no docs, and databases we were only allowed to touch read-only. The code around a legacy system is almost always uglier than the code around a modern one, and that's fine — we write it clearly, test it carefully, and document the quirks so your next engineer doesn't have to re-learn them.
How do you handle auth?+
Depends on the audience. Internal APIs usually use a managed auth provider (Clerk, Auth0, Supabase Auth) plus short-lived JWTs. Partner APIs typically use signed API keys with scoped permissions and rotation. Public APIs use OAuth 2.0 when third parties act on behalf of end-users. We default to well-understood standards and almost never roll our own.
Need a backend your team can actually read?
Tell us what the API needs to do and who's going to call it. You'll talk to Eric directly and get an honest read on scope, timeline, and whether we're the right partner. No pressure, no sales sequence.
Related services