Service / 06
REST.
GraphQL.
Contracts that hold.
Senior API freelance support. New backends, integration layers, cleaner contracts between frontend and backend, and the operational work that stops API projects becoming fragile later.
Service / 06 / Capabilities
What's covered.
REST and GraphQL APIs
Backend APIs for products, internal tools, mobile apps, and frontend applications. Designed around how the data actually gets used, not just how the endpoints look on paper.
Integrations
Third-party APIs, webhooks, CRMs, payment providers, and system-to-system data flows. Useful when the complexity is less about building screens and more about making services talk properly.
Auth and access control
Authentication, authorization, token flows, and permission boundaries that hold up once more than one client or team depends on the API.
Operational reliability
Validation, rate limits, observability, and error handling. The work that keeps an API usable after launch, when real traffic and edge cases start showing up.
10+ years senior delivery
Why me
Senior delivery you don't have to project-manage.
API work usually looks simple from a distance. In practice it sits in the middle of product logic, integrations, auth, and team handoffs, so the details matter. I shape APIs around real product needs rather than how the endpoints look on paper.
- API for a web app, mobile app, or internal tool
- Frontend moving faster than the backend contract can support
- Multiple systems that need integrating without a brittle mess
- Auth, permissions, or data consistency becoming delivery risks
- An API your team can keep extending after the initial build
Engagement / Snapshot
A typical api development engagement.
Lead time
<7
Days to start, contract permitting
Length
4-12
Weeks for fixed-scope work
Reply
<24
Hours, every working day
Day rate
POA
Quoted per engagement
FAQ / API Development
Frequently asked
Q · 01
Do you only build APIs for greenfield projects?
No. A lot of API work sits inside existing products, legacy systems, or platforms that need better structure before more features get added.
Q · 02
Can you help with both the API and the frontend consuming it?
Yes. That is often where I am most useful, because the contract between frontend and backend is where a lot of delivery friction comes from.
Q · 03
What kinds of API work do you usually handle?
Product backends, internal tools, third-party integrations, auth-heavy systems, and the cleanup needed when an API has grown quickly without much structure.
How I work
Remote-first. Async by default.
Inspired by Remote and the way Basecamp ran a distributed team without burning anyone out. Meetings are expensive, writing is cheap, and momentum belongs to whoever can make a decision without a calendar invite.
01 / Specs
Specs before code
A short written spec covering problem, scope, and acceptance before anything gets built. Cuts rework, makes review easier, and means we never argue about what was agreed.
02 / Workstreams
Workstreams over standups
Active work lives in tickets and PRs with running notes. Async updates instead of daily standups, so deep work is the default and meetings only happen when they earn it.
03 / Loom > Zoom
Loom over meetings
Most reviews and walkthroughs go out as a 5-minute Loom you can watch at 2× when convenient. We jump on Meet / Zoom / Teams when the topic actually needs a conversation.
Channels / Tools
Slack
Async, threaded, no expectation of instant reply
Loom
PR walkthroughs, demos, design reviews
Google Meet / Zoom / Teams
Booked when conversation > writing
Linear / Jira / GitHub
Source of truth for the work
Notion / Docs
Specs, decision records, retros
The pitch
I write the code, talk to your team, and ship what we agreed. No agencies. No PMs. No surprises.
James Donnelly
Freelance developer · Manchester