Tim Rutte. Architect for AWS and legacy modernization.
Modernization, migration and backends under load, usually on systems that have to keep running while it happens. I rebuild them myself instead of leaving recommendations behind. Pragmatic, direct, and focused on delivery.
Cloud & Software Architect · Remote · No overhead · Since 2003
Pragmatic. Direct. Focused on delivery.
I am Tim Rutte. More than 20 years in software development. Today I build business-critical systems on AWS.
What drives me: systems I touch should end up better than I found them. More stable. More maintainable. More scalable. Not because it looks good, but because bad systems carry a real cost.
I have worked my way into legacy codebases nobody wanted to open, stabilized systems that were breaking under load, and replaced manual workflows with services that have run untouched ever since. Added to that is the infrastructure behind production AI systems: MCP servers and LLM integrations that hold under real load. What I work on concretely is on the services pages, and what came out of it is in the case studies.
Experience
More than 20 years of software. And several technology generations.
I have been building production software since 2003. In that time several technology generations have come and gone: from PHP and MySQL applications through platforms that grew over years to Go, AWS and today agentic tooling.
That shapes how I look at modernization. I know legacy systems not only in the state they are in today. I have watched them get there: how software grows over years, where a pragmatic decision turns expensive, and why a rewrite is still rarely the simplest answer.
- 2003
Software goes into production
Custom web applications, backends, databases, interfaces to whatever was already running in the business. Rarely a website. Mostly software a business process depended on, among them work in financial services. When something like that fails, nobody calls support. A process stops.
Systems get bigger
Individual applications turned into platforms: more users, more data, more interfaces, and code several people had been working on for years. From that point the effort was no longer decided by the single feature but by the state of the system. How it ships. How easily it changes. What a pragmatic decision made three years ago costs today.
Code meets cloud
With AWS the responsibility moved from my own code to the system as a whole. Infrastructure as code instead of console clicks that grew over time, distributed services instead of one application, Go where latency and memory behaviour have to be predictable. Along with the questions somebody else used to own: availability, observability, cost.
- Today
Modernizing business-critical systems
Systems that are running, earning money and still have to change. Agentic engineering is part of the daily routine and makes delivery considerably faster. It changes nothing about the substance: architecture, quality and the decision about what gets built stay my responsibility.
Legacy rarely comes from bad developers. Most of the time it comes from successful software that lived longer than anyone planned for. So with a twenty year old system the question is not who is to blame but what happens next: what comes first, what needs a way back, and what can stay as it is. How that runs is on the legacy modernization page. One example is a 20 year old editorial platform that did not stand still for a single day while it happened.
How I work
Understand. Decide. Deliver.
Context before code.
I start by understanding how a system actually works, not how it is documented. What is genuinely broken? What runs better than it looks? Only once that is clear do we decide together what has to be built, and in which order.
No nodding along, no looking away.
I take responsibility for the system, not just for my part of it. Problems nobody wants to hear about get raised anyway. Decisions that are wrong get questioned. In the end I stand behind what was built.
Specs before sprint.
I use spec-driven development with agentic AI tools daily. Requirements get defined precisely before code gets written. That reduces misunderstandings, makes changes plannable, and keeps quality steady even when delivery moves fast.
Tools
What I work with.
Tools, not a worldview. Everything listed here I have run in production, not just tried out.
- Golang
- PHP 8
- Symfony
- TypeScript
- Python
- SQL
- ECS Fargate
- Lambda
- S3
- RDS
- DynamoDB
- EventBridge
- SQS
- Step Functions
- CloudFront
- IAM
- Organizations
- PostgreSQL
- MySQL
- Valkey / Redis
- Manticore Search
- Elasticsearch
- Athena
- Terraform
- Docker
- Kubernetes
- CI/CD
- CloudWatch
- OpenTelemetry
- Blue/Green
- Amazon Bedrock
- MCP
- FastMCP
- Tool calling
- Embeddings
- Vector search
Values
What drives me.
Honesty. If an approach does not work, I say so, even when it is uncomfortable. If a project needs more time than planned, I raise it early. A client who knows the truth can decide. A client who gets softened feedback cannot.
Quality. Not because I am slow, but because badly written code always comes back. As technical debt, as a production outage, as a developer who resigns because they no longer want to touch the system. I build things I can still stand behind in two years.
Being myself. I work the way I am, not the way I think a contractor is supposed to be. I say what I think, bring my actual opinion, and stand by it. Anyone looking for someone who always nods is in the wrong place. Anyone looking for someone who thinks along, raises problems and takes responsibility is in the right one.
Working together
When I fit. And when I do not.
A fit
- A system is running, earns money and still has to change.
- Nobody owns the architecture as a whole.
- The decision is technical, the consequences are commercial.
- You want someone who builds it, not someone who recommends it.
Not a fit
- Advice without delivery.
- An extra pair of hands in a running sprint, with no responsibility for the outcome.
- Projects where the decision has long been made and only needs confirming.
Credentials
Certifications
Frequently asked
What clients ask me.
Do you work on site?
The work happens remotely. I come on site for alignment when it helps: kickoff, an architecture session, a hard decision with many people in the room. The delivery itself does not need a desk at your office.
How quickly can you start?
That depends on scope. Smaller pieces of work I can usually start within a few days, larger ones need more lead time. Tell me your timeline and I will tell you honestly whether it is realistic.
Do you also run the system afterwards?
If you want me to, yes. Just as often the goal is the opposite: that your team can operate the system without me. Either is fine, it just has to be clear from the start, because it shapes the architecture.
Do you work alone or with a team?
I work alone and I am your direct contact. When a piece of work needs more hands or a specialist discipline, I bring in people from a circle of freelancers I have worked with for years and who are experts in their field.
What happens if the project turns out bigger than expected?
Then I say so as soon as I know, not at the end. A client who knows the situation can decide: cut scope, move the date, or add budget. A client who gets softened feedback cannot.
Which languages do you work in?
German and English, spoken and written, documentation included.
Enough about me. Let’s talk about your system.
Thirty minutes are enough to see whether I can help.