The engine behind the product, built to hold up.
Server-side systems and APIs in C# and ASP.NET Core — the part users never see but the whole product depends on. Clean REST APIs, real authentication, background jobs, integrations and a database designed to stay fast as the data grows. Built for correctness under real load, not just a demo. Remote, worldwide.
APIs and services that other systems can trust.
A backend is judged on the day it's under load, not the day it's demoed. Here's the kind of server-side work I build, with the reliability baked in.
REST APIs & web services
Clean, versioned Web APIs on ASP.NET Core — the same foundation running under my live multi-GDS travel platform, front to back.
Authentication & authorization
JWT and OAuth, role- and claim-based access, refresh tokens and multi-tenant isolation — security designed in, not bolted on later.
Background jobs & schedulers
Queues, retries and scheduled work with Hangfire — for emails, refunds, syncs and anything that must survive a failed attempt.
Third-party integrations
Payment gateways, supplier and GDS feeds, and REST / SOAP / gRPC services made to talk to each other reliably. See GDS integration →
Data access & databases
SQL Server schemas, EF Core and Dapper, tuned queries and clean migrations — the layer everything else sits on. See database work →
Logging, monitoring & audit
Structured logging with Serilog, health checks and audit trails — so when something goes wrong at 2am, the answer is in the logs.
What every backend build includes
The parts that make a backend trustworthy are the ones you can't see in a demo. Every build ships with them from the start.
- Clean-architecture Web API with clear layers
- Authentication, authorization & multi-tenancy
- Input validation & consistent error handling
- Background jobs, queues & retries
- Structured logging & health checks
- Database schema, migrations & tuned queries
- API documentation (OpenAPI / Swagger)
- Tests around the logic that matters
One engineer, the whole stack
The person designing your API also designs the database under it and the frontend that consumes it — so nothing gets lost in handoffs between specialists.
- A real multi-GDS platform in production, built solo
- APIs designed for the frontend that will actually use them
- Money and booking logic done idempotently, not hopefully
- Built to add features later without a rewrite
- Honest scope and a clear quote up front
- You own all the code — no lock-in
From requirements to a running API, in five steps.
Scope
What the system must do, who calls it, and how it fails safely. We agree what's in — and what isn't — so the quote is honest.
Design
The API contract, the data model and the auth model — agreed before code, because this is where rework hides.
Build
Endpoints, jobs and integrations built in clean layers, with previews as we go so you're never surprised.
Harden
Validation, edge cases, retries and load — the failure paths tested, not just the happy path.
Deploy & support
Ship it, wire up logging and monitoring, and stay on to add features as you grow. See support options →
The thinking behind the build.
Write-ups and related services that show how I approach backend work — the architecture, the integrations, and the data layer underneath.
Integrating the Amadeus API
Auth, the search-price-book flow, and the server-side plumbing — markup, wallets and multi-tenancy — a real API integration end to end.
Database engineering
The SQL Server layer your API sits on — schema design, indexing and query tuning so the backend stays fast under real traffic.
Why your database is slow
The seven causes I work through when an app has slowed to a crawl — and why a bigger server almost never fixes it.
Legacy .NET modernization
Already have a .NET backend that's fragile or stalled? I take over, stabilise and modernise existing systems too.
Azure deployment & DevOps
An API is only useful once it is running. I deploy, monitor and set up the pipeline that ships it.
AI integration
Adding an assistant, summarisation or classification to a product is backend work — API keys, queues and cost control.
React Native mobile apps
A phone app is mostly a well-designed API plus a thin client. If the backend is mine, the app is straightforward.
Questions about backend work
Can you take over an existing .NET codebase?
Do you write tests?
What happens to background jobs if the server restarts mid-run?
How do you handle authentication for a multi-tenant app?
Need a backend or an API built?
Tell me what the system needs to do and what it has to talk to — a rough idea is enough. You'll get an honest scope and a clear quote, with no pressure.