01
API design
Resource modelling, versioning, error shapes, pagination, and auth. The contract is the product. We treat it that way.
Service 04
APIs that other products can trust.
A slow or unclear API becomes everyone’s bottleneck. We design the contract first, then implement it in Node.js.
Typical start
Audit or contract workshop first
Build length
2–8 weeks depending on surface area
Best for
New APIs and rescue of slow ones
The problem
The mobile app is blamed for lag, the website times out, and every new client needs a ‘special’ endpoint. The real issue is usually the API: no versioning, N+1 queries, payloads that ship the entire database, and docs that live in someone’s head.
What you walk away with
A stable contract, measurable latency, and documentation a new engineer can use on day one. Web, mobile, and partners stop inventing their own workarounds.
Who this is for
- Teams whose app is slow and the backend is the suspect
- Companies exposing data to partners, vendors, or a public developer programme
- Product teams adding a mobile app on top of an existing web API
- Founders who need a clean API before they hire a larger engineering team
What this service actually includes
02
Implementation in Node.js
Express or a modern Node stack, typed where it pays off, with the boring production pieces: validation, rate limits, logging, and tests on the paths that matter.
03
Performance work
Query optimisation, caching, payload trimming, and the indexes nobody added. We measure before and after so ‘faster’ is a number, not a feeling.
04
Docs & partner access
OpenAPI / clear reference docs, API keys or OAuth, and examples for the clients that will actually call you.
Typical company engagements
Greenfield API for a mobile + web product
Contract first, then Node.js implementation with auth, pagination, and docs the clients can mock against.
Performance rescue
Profile slow routes, fix queries and payloads, add indexes and caching. ‘Faster’ comes with numbers.
Partner / public API
Keys or OAuth, rate limits, a changelog, and examples a third party can use without a Slack thread.
How the work runs
Step 01
Audit the current surface
If an API exists, we profile it: slow routes, unused fields, auth holes, and the endpoints the app actually hits. If it does not exist, we start from the product jobs.
Step 02
Write the contract
Endpoints, errors, and examples are agreed before a week of coding paints you into a corner. Mobile and web can mock against this immediately.
Step 03
Build & measure
Implementation with instrumentation. We keep p95 latency and error rate visible, not hidden in a log file.
Step 04
Document & hand off
Reference docs, changelog, and a path for the next version so you are not stuck on v1 forever.
Deliverables
What a company can put in a statement of work.
- Documented API contract (OpenAPI or equivalent)
- Production Node.js implementation
- Auth, validation, and error standards
- Performance notes with before/after where we optimised
- Example requests for web and mobile clients
What the company keeps
Ownership and handover are part of the professional standard.
- A written API contract (OpenAPI or equivalent)
- Auth and error standards the clients can rely on
- Instrumentation so latency is visible
- Examples for web and mobile, not a wiki page that lies
How a company starts
Send this and we can quote.
You do not need a 20-page RFP. A messy but honest brief is enough for a scoped proposal.
- 01
What already exists (repo, Postman, or ‘it is only in the app’)
- 02
Who calls it today: web, mobile, partners, or all three
- 03
The slow or painful endpoints, with examples if you have them
- 04
Auth as it stands (JWT, sessions, API keys, or none)
- 05
Whether this is a new contract, a rescue, or partner access
Stack
Tools we actually ship with. We will work inside yours if that is the cheaper path.
Node.jsRESTJWT / OAuthPostgreSQLMongoDBOpenAPI
What this is not
Saying no is how companies know we are not selling everything.
- SOAP or legacy enterprise buses we would have to fake-understand
- Blockchain APIs as a fashion choice
- Undocumented ‘just make it work’ dumps with no contract
Questions companies ask
Do you only do REST, or GraphQL too?+
REST is the default for most company products, it is easier to cache, version, and explain to partners. GraphQL is used when the client shape truly needs it. We will not add GraphQL as decoration.
Can you fix our existing API without a rewrite?+
Often yes. Indexes, query shapes, pagination, and cutting oversized payloads recover a lot of performance. We rewrite when the contract itself is the bug.
Will this work for both our app and website?+
That is the point. One API, multiple clients. If web and mobile need different payloads, we design that on purpose with sparse fieldsets, not two backends.
How do you prove the API got faster?+
We measure p95 latency and payload size on the routes that matter, before and after. If we cannot show a number, we do not call it optimisation.
Do you write the mobile/web clients too?+
We can. Many API engagements sit inside a larger product build. If you already have client teams, they get a contract and examples they can mock on day one.
Discuss apis with us
Tell us what you need: a new product, a revamp, or ongoing maintenance. You will receive a clear response on fit, scope, and next steps.