The backend matters in production.
Outages, latency or processing errors directly affect customers, revenue or internal operations.
All services
Backend development
Backends that hold under load. Not just in the load test.
Peak traffic is not an accident. It arrives, with the campaign launch, the seasonal peak, the competitor’s outage. I build backends for SaaS products and platforms that survive that moment: in Go and PHP 8, event-driven on AWS, with tenant isolation and recovery designed in rather than bolted on.
Golang & PHP 8AWS Certified Solutions Architect – Professional20+ years of backend
What you get
- An architecture and service split that fits your domains rather than a buzzword
- Production-ready code with tests, a pipeline and a deployment strategy
- Load tests with defensible numbers, so you know what the system takes
- Monitoring, alerts and runbooks your team can run operations with
Scope & working together
Typical scope is three to nine months, part time or full time. An architecture or load review also works as a self-contained two week engagement.
Remote from Germany. Straight with me, no agency in between.
The starting point
It runs. Until the traffic arrives.
Most backends are not built wrong, they are built for a different order of magnitude. What works with ten thousand users tips over at a million in places nobody had on their radar: a database lock, a synchronous call inside a loop, a connection pool sized too small.
Then comes the second effect: systems under load do not fail all at once, they get slow. Timeouts stack up, retries amplify the load, and a bottleneck turns into a total outage. No bigger server fixes that. Only a design that absorbs backpressure does.
Typical symptoms- Deployments happen at night because they are too risky during the day.
- One slow downstream service takes the whole system with it.
- There is no number for how much load the system can take.
- One large customer affects response times for everyone else.
- Every integration against the API turns into a special case.
- Only one person really understands the critical path.
Who this is for
For product teams whose backend carries revenue, users or critical workflows.
For CTOs, technical leaders and product owners with a live digital product. Load, reliability or technical debt limits the next stage of growth and the need is architecture plus implementation.
The challenge sits below the UI.
Data models, interfaces, concurrency or operations matter more than one more visible feature.
Your team needs hands-on senior support.
You need decisions implemented in code and production, not an architecture report for a drawer.
What I do
Designed.
Resilient.
Handed over.
01
Load profile and bottleneck analysis
Before any code, we establish what the system has to take: requests per second, the ratio of peak to average, the latency budget per call. Then I measure where it breaks today, with profiling and a load test rather than assumptions.
02
Service boundaries and decoupling
What does not have to be synchronous becomes asynchronous: queues, events, idempotent processing, dead letter queues for when it matters. The split follows domain boundaries rather than team boundaries, because it determines your operating cost later.
03
Go services on the hot path
Where throughput and latency matter, Go is the pragmatic choice: small memory footprint, real concurrency, fast starts. Existing PHP stays where it belongs and gets connected cleanly, rather than everything being touched at once.
04
Tenant isolation and data
Several customers on one infrastructure, without one large tenant dictating response times for the others: isolation at the data and load level, indexes and query paths that scale with you, and caching as a deliberate decision rather than a shortcut.
05
Load resilience and recovery
Every call gets a time budget, every dependency a circuit breaker, every load level a point beyond which it gets shed deliberately. Multi-AZ as standard, recovery and restore rehearsed once against the clock, so nobody has to guess when it counts.
06
APIs and uneventful deployments
The API gets specified before it gets implemented, OpenAPI for REST and Protobuf for gRPC, so integrations succeed without follow-up questions. Plus CI/CD with tests, blue/green deployments, feature flags for risky changes, and a rollback that has been practised. A release should be a non-event.
Specific cases
Building SaaS platformsTenant separation, billing and recovery are decided at the start, not at the tenth customer. A page of its own on what carries a SaaS once one customer grows as large as all the others together.Building online shopsThe shop is rarely the hard part. The hard part is what hangs off it: inventory systems, point of sale, branch stock in real time. A page of its own on when a shop of your own pays off and when a standard product will do.Introducing observabilityFor when outages are reported by customers rather than by the system, or the other way round: two hundred dashboards and still no answer. SLOs on the paths that carry money, alerts with an owner, cardinality and cost decided rather than grown. A page of its own.Building deployment pipelinesFor when releases happen at night and nobody wants to touch the path that carries code into production. One artefact through every stage, access without long-lived keys, and a way back that has been rehearsed rather than described. A page of its own.Go services alongside PHPNo rewrite and no change of language: one hot path is lifted out and runs as a Go service next to what you have. A page of its own on when that holds and when the bottleneck sits elsewhere.
Should your backend survive the next peak?
Let’s spend 30 minutes on your load profile.
How it runs
From load profile to running system.
No waterfall. Every stage ends with something you can hold: a number, an environment or a release.
STEP 01
Establish the target
What the system has to take, who runs it, what is already fixed. 30 minutes is enough to tell whether it fits.
STEP 02
Analysis and design
Load profile, bottleneck measurement, target architecture with service boundaries. The result is a plan with an order and an effort estimate.
STEP 03
Building in increments
Delivered in steps that can go to production individually. Tests, pipeline and Terraform grow with it, not after it.
STEP 04
Harden and hand over
Load test against the agreed numbers, recovery rehearsed, runbooks, pairing until operations run without me.
The outcome
What you end up with.
Defensible numbers instead of hope
You know what your system takes, where the next limit sits, and what it costs to move it.
Failures stay local
An overloaded part does not drag the rest down. Backpressure gets absorbed rather than passed on.
Operations that stay in the team
Documented decisions, runbooks and a team that can keep building. No knowledge tied to one person.
Technologies I use
Proven tools. No experiments.
Languages
- Golang
- PHP 8
- Python
- TypeScript
- SQL
Frameworks
- Symfony
- Laravel
- Slim
- gRPC
Interfaces
- REST
- gRPC
- API Gateway
- Webhooks
- GraphQL
Databases
- PostgreSQL
- MySQL
- MariaDB
- Aurora
- DynamoDB
Cache and queue
- Valkey / Redis
- Elasticache
- SQS
- SNS
- Apache Kafka
Platform
- ECS Fargate
- EKS
- Lambda
- EventBridge
- Docker
Infrastructure
- Terraform
- AWS CDK
- GitHub Actions
- GitLab CI
Operations
- OpenTelemetry
- CloudWatch
- Datadog
- Grafana
- Prometheus
Who you are talking to
Directly with me as a freelancer. No agency in between.
I am Tim Rutte. More than 20 years in software development. Today I build backends that hold under load and fail predictably. You talk to the person who touches your code, from the first call to the handover.
- 20+years in software development
- 50+successful projects
- 2003working remotely since then
Working together
Working with your team or delivering independently.
You do not need to bring a particular setup. I adapt the engagement to how your company works and how much responsibility you want to hand over.
01Together
I work as part of your team.
If knowledge and responsibilities already sit with you, I join wherever additional experience is needed. Inside your workflows, in direct contact, without creating a parallel track.
- Integration into your sprints, reviews and technical decisions
- Pairing and knowledge transfer throughout delivery
- Code, documentation and operations remain fully with your team
02Independent
I take ownership of delivery.
If you lack time or capacity internally, I take a clearly scoped piece of work from technical clarification through to production. You set the objective and constraints; I take care of the path there.
- One point of contact from clarification through to delivery
- Regular, clear progress updates without day-to-day supervision
- A proper handover with documentation and a walkthrough
Whichever model you choose, you always know what is being built, which decisions are pending and what happens next. Billing follows the project and the model you prefer: clearly bounded work at a fixed price, longer or more open-ended work by time spent.
Continuity
Your system remains yours.
Independent delivery does not create dependency on me. Everything required to develop and operate the result stays in your environment from day one and remains ready for handover throughout the engagement.
Access stays with you.
Code, cloud accounts, pipelines and secrets live in your systems. Operations never depend on a personal account or credentials that only I control.
Knowledge does not stay in my head.
Architecture decisions, operating procedures and known risks are documented where your team will find them and kept current as the work progresses.
Someone else can take over.
Reproducible environments, automated deployments and regular handovers allow your team or another provider to continue without starting again.
The goal is not for you to depend on me permanently. The goal is for you to remain free to decide who develops the system next.
Client voices
What clients say afterwards.
“Mr Rutte built a fully custom CRM for us, tailored exactly to our needs. Working together was straightforward. He implemented our requirements perfectly and the system runs absolutely stable.”
“Tim worked with us as a PHP developer and did a really good job. He got up to speed on the project quickly and always found a solution, even on tricky topics. The code was clean, easy to follow and genuinely moved us forward. We would work with Tim again any time.”
“The development of our software was completed as agreed and all problems were resolved. Many thanks.”
Common questions
Before you ask.
Do you build the frontend as well?
No. I build the backend, the interfaces and the infrastructure. For frontend and design I work with your team or the people you already use, and the coordination runs through the API contract, which is agreed up front. If you are looking for someone to deliver the complete product including the interface, I am the wrong person and I will say so in the first call.
Do we have to move to microservices for this?
No. A well-structured monolith beats plenty of distributed systems and is considerably cheaper to run. I split things only where there is a concrete reason: different load profiles, different release cycles, or team boundaries that would otherwise block permanently.
Do we need Kubernetes?
Often not. Kubernetes is a good tool when you have several teams, many services and people who can run the cluster. For most setups ECS Fargate gets there faster and costs less to operate. I decide that based on your team and your load, not on the trend.
Why Go rather than the language we already use?
Usually the existing language stays. I use Go deliberately where throughput, latency and memory footprint matter, as an additional service next to what you have, connected over gRPC or a queue. I have written up how that works without a rebuild in a separate article.
Do you write code yourself or only advise?
I write code. The design happens at the start, but most of the time goes into implementation, tests and the pipeline. In my experience, advice without implementation produces documents nobody reads.
Do you work with our existing team?
Yes, and that is the normal case. I work in pairs, document decisions as ADRs in the repository, and hand over before I leave. The goal is not dependence on me, it is a team that can keep building on its own.
Terms that come up here
Anti-corruption layerFeature flagModular monolithExpand and contractRTO and RPOBlue-green deploymentMulti-tenancyMulti-regionIdempotencyCircuit breakerRate limitingObservabilitySLO, SLI and SLAEvent-driven architectureBus factorBrownfield and greenfieldInfrastructure as codeGraceful degradationgRPCSaga patternCanary releaseShardingTest coverageRefactoringMonolithMicroservicesAPI firstServerlessAmazon RDSKubernetesCI/CDLoad balancerCachingMessage queueAPI gatewayRESTWebhookDatabase indexChaos engineeringRunbookWorkflow orchestrationETLERP integrationLeast privilegeSecrets managementZero trustAudit logEncryption at rest and in transitPatch managementPenetration test
To the glossaryOther services
What else I help with.
Legacy modernization
Modernizing grown systems step by step: strangler fig instead of a rewrite, operations untouched, every step reversible.
Learn moreAWS migration
From your own data centre or another cloud onto AWS, with a cost model before the move and a rollback path for every step.
Learn moreReducing AWS costs
I find where your AWS budget leaks away, and cut it measurably without giving up performance or availability.
Learn moreImproving AWS resilience
So that a single fault does not take the whole application with it: dependencies and single points of failure identified, recovery rehearsed rather than documented, changes delivered as Terraform.
Learn moreAI in production
The infrastructure behind AI systems that actually ship: MCP servers, controlled tool access, LLM integration with real permissions and cost control.
Learn moreProcess automation
Replacing manual workflows with real systems: wired into the software you already run, with permissions and an audit log instead of a chain of tools.
Learn more