Backend Development

Backend Development

Table of Contents

I build the part of your product users never see: the API your app talks to, the database underneath it, and the jobs that run while nobody’s watching.

Suitable whether you’re starting from nothing, adding a backend to an existing frontend or mobile app, or taking over something that already exists and needs to be stabilised.

What you get

Every backend engagement is delivered with all of the following. These aren’t upsells.

  • Source code in your repository, under your organisation’s account. You own it outright.
  • A documented API — OpenAPI/Swagger spec, or a Postman collection, whichever suits your team.
  • Database schema and migrations, version-controlled so any environment can be rebuilt from scratch.
  • Automated tests covering the core business logic and endpoints.
  • A CI/CD pipeline that runs those tests and deploys on merge.
  • Environment configuration for local, staging, and production, with secrets kept out of the codebase.
  • A written runbook: how to deploy, how to roll back, how to restore a backup, where the logs are.
  • A handover walkthrough with your team, recorded if you want it.
  • 30 days of post-launch support for defects in what I delivered.

What I can build

The three areas on the poster, in more detail.

API Development & Integration

REST or GraphQL endpoints with authentication (JWT, OAuth2, or session-based), role and permission models, request validation, versioning, rate limiting, and consistent error responses.

Integration is the other half of it: payment gateways, WhatsApp and email delivery, object storage, mapping services, or whichever internal system needs to be talked to. On the Dinas Kominfo Jatim portal that meant one Laravel backend feeding both a public site and an admin dashboard.

Database Management

Schema design and normalisation, indexing and query optimisation, and migration paths between engines. Read replicas and connection pooling where the load actually justifies them.

Backup and restore policies that get tested rather than assumed. I wrote a Go CLI to handle provisioning and retention after one shell script too many quietly filled a disk.

Inherited databases too: working out what is really in there, documenting it, and getting it under version-controlled migrations before anything else changes.

Server-Side Scripting

The logic that runs when nobody is watching. Queues and background workers, scheduled tasks, report generation, webhook processing, and event-driven flows over a message broker.

Caching strategy as well, which mostly means deciding what gets cached, for how long, and how it gets invalidated — the third of those being where the bugs live.

And the containerised deployment underneath all of it. That’s how 50+ applications ended up with isolated runtimes and push-to-deploy pipelines instead of an FTP client and a held breath.

Stack

I’ll recommend based on your team and constraints, not habit. If your developers know one of these already, that usually decides it.

LayerOptions
LanguagesGo, PHP, JavaScript/TypeScript, Java
FrameworksLaravel, Livewire, Node, CobraCLI (tooling)
DatabasesPostgreSQL, MariaDB/MySQL, Redis, Firebase
MessagingRabbitMQ, NATS, SQS
Web/proxyCaddy, Nginx
RuntimeDocker, Docker Compose, Kubernetes, Podman
CI/CDGitLab CI, GitHub Actions, Jenkins, Bitbucket Pipelines
QualitySonarQube, pre-commit hooks, semantic versioning
ObservabilityGrafana, Prometheus, Loki, Tempo, CloudWatch

How it runs

1. Scoping. A call to understand the product, then a written scope: endpoints, data model, integrations, environments, and what’s explicitly out of scope. Fixed price or day rate, your choice.

2. Foundations. Repository, environments, pipeline, and database schema before feature work. Deployment works from day one so it’s never a launch-week problem.

3. Build. Delivered in increments you can see running on staging, not a single reveal at the end.

4. Handover. Runbook, walkthrough, and the support window.

Where I’m a good fit

Best suited to products where reliability and maintainability matter more than shipping a prototype this week: internal platforms, government and enterprise systems, mobile app backends, and businesses whose backend has outgrown whoever set it up originally.

Less suited to very short throwaway builds, or teams wanting a language nobody on either side will maintain afterwards. I’ll say so early rather than take the work and hope.

Get in touch

Tell me what you’re building, or what’s currently breaking. Send a message on WhatsApp and I’ll tell you honestly whether I’m the right person for it.

Proof, if useful: a Laravel government portal serving public traffic, a Go CLI for database operations, and 50+ applications containerised with pipelines.