I build Backends

A backend handles the work behind a website or application. It manages data, business logic, integrations, and the rules that make the software work.

Whether you’re building something new or working with a backend that already exists, I can help. That might mean designing a new system, adding functionality, connecting services, or improving a codebase that has become difficult to work with.

The right structure depends on what the software needs to do. I favour clear code, sensible architecture, and automated tests where they provide real value.

The result should be a backend that does its job reliably and remains practical to change and maintain over time.

I connect things

A backend rarely works on its own. I connect databases, APIs, external services, and other systems so they can work together in a predictable way.

The details depend on the business and the software involved. I focus on clear data models, understandable server logic, and integrations that are easy to test and maintain.

  1. Databases

    Databases store the structured data a system works with, such as users, products, orders, and content. I use them when data needs clear relationships, reliable transactions, controlled access, and dependable backup and recovery.

    • PostgreSQL
    • MariaDB
    • MySQL

  2. Server Logic

    Server logic handles the rules and processes behind an application. It can manage payments, signups, order changes, scheduled tasks, validation, and error handling so the system behaves predictably in everyday and unusual situations.

    • Queues
    • Tasks
    • Data evaluation

  3. API Integration

    APIs connect your backend with services such as payments, shipping, customer records, analytics, and notifications. I build integrations that exchange data reliably, handle external events, and keep the different parts of a system in sync.

    • REST
    • GraphQL
    • Webhooks

A good backend makes the systems around it easier to work with. The aim is a setup that handles everyday operations reliably and leaves enough room to change as the business evolves.

I also handle Infrastructure

A backend needs an environment where it can run reliably. I set up infrastructure as code, automated deployments, and basic monitoring to make deployments repeatable and day-to-day operation easier to manage.

The setup depends on the system, the team, and the budget.

See how I handle infrastructure

Languages and Ecosystems

The programming language and its ecosystem affect how a backend is built, deployed, and maintained. They influence available libraries, hosting options, performance, developer experience, and how easy the code is to work with over time.

I choose the environment based on what the software needs and what makes sense for the project.

  1. PHP

    PHP has a large ecosystem and runs on a wide range of hosting environments. It is often a practical choice when straightforward deployment, broad hosting support, and a mature set of tools matter.

    See how I use PHP

    • Tempest
    • Laravel
    • Composer
    • LAMP
    • Managed Hosting

  2. Rust

    Rust is useful when performance, predictable resource usage, and strong safety guarantees are important. Its concurrency model also makes it a good fit for services that need to handle a lot of work reliably.

    See how I use Rust

    • Performance
    • Safety
    • Concurrency
    • Tokio
    • Axum

I often use PHP when broad hosting support and straightforward deployment are useful. Rust is a good fit when performance and low-level control matter. I’ve also built production systems with Node.js, Deno, TypeScript, and Elixir. The language is part of the decision, but the requirements of the software come first.

I also build Websites

A backend is only useful when people can actually use what it provides. I can build the website or application that connects to your backend and turns the underlying functionality into a useful experience.

That might be a web application, a website, or another interface that needs to work with your system.

See how I build websites

Data Storage

Backends need somewhere to keep the data they work with. The right storage depends on what the data is, how it is used, and how much of it the system needs to handle.

I work with databases, file storage, and other storage systems and choose the approach that fits the application.

  1. SQL

    SQL databases are a good fit when data has clear relationships and transactions need to remain consistent. Schemas, constraints, joins, and mature tooling also make them useful for reporting and workflows where data correctness matters.

    • PostgreSQL
    • MariaDB
    • MySQL

  2. NoSQL

    NoSQL databases can make sense when data structures need more flexibility or when a specific access pattern calls for a different approach. They are useful for some high-traffic workloads, rapidly changing data, caching, and other cases where a traditional relational database isn’t the best fit.

    • Redis
    • CouchDB
    • MongoDB

  3. Object Storage

    Object and filesystem storage are useful for media, documents, and other large files that don’t belong in a database. They can keep databases smaller, work well with CDNs, and provide simple ways to manage large amounts of data.

    • Plain Files
    • MinIO
    • Amazon S3
    • Cloudflare R2

Storage is part of the backend’s overall design. A sensible setup keeps data accessible and reliable without adding unnecessary complexity to the rest of the system.

Let’s build your backend

Building a new backend, replacing an existing system, or dealing with a codebase that has become difficult to maintain? Tell me what you have in mind.

You don’t need a technical brief. A description of what the system does, what you want to change, or where you’re currently stuck is enough to start.

Tell me about your backend

Photo of Tobias Tom