The workflow repeats often.
Volume, handling time and exceptions can be described, so the business case can be calculated before implementation.
All services
Process automation
Manual processes cost twice. Once in time, once in errors.
Workflows that run on spreadsheets, email and three departments hold up until volume grows or someone is off sick. I replace them with systems wired into the software you already run, with permissions, a traceable log, and no tool chain sitting in between that belongs to nobody.
Golang & PHP 8ERP and inventory integrationAWS Certified Solutions Architect – Professional
What you get
- A process survey: what actually happens, where errors and waiting time come from
- Automation where it pays off, with effort and savings quantified
- Clean integration with existing systems instead of a layer of tools on top
- Logging, error handling and monitoring for day-to-day operation
Scope & working together
The process survey is a self-contained one to two week engagement. Implementation follows process by process, so the first benefit lands early. A single, bounded process runs shorter and at an entry price, linked below.
Remote from Germany. Straight with me, no agency in between.
The starting point
The process runs. On people, spreadsheets and hallway conversations.
Grown workflows are rarely documented. Someone exports a list, someone checks it, someone types the result into a second system. That works while volume stays small and the people stay put. Both of those change.
The obvious answer is a chain of automation tools. It stands up quickly and holds until an interface changes, an access key expires, or someone asks who triggered which change. I build a service that belongs to the rest of your system landscape instead: versioned, monitored, and with permissions that match the ones you already have.
Typical symptoms- A workflow runs on spreadsheet exports and email between departments.
- The same data gets maintained by hand in more than one place.
- When one person is on holiday, the process stalls.
- Nobody can trace who changed what, and when.
- A tool chain automates it, but nobody knows who owns it.
- Volume grows and processing time grows with it.
Who this is for
For owners whose teams pay for the same manual process every month.
For operations, finance and technical leaders in established companies. A recurring workflow consumes visible time, crosses several systems and creates errors or rework.
Several systems are involved.
ERP, email, files, APIs or databases must work together reliably, including permissions and auditability.
People should handle exceptions.
Routine cases should flow automatically while people remain where judgement is actually required.
What I do
Understand.
Connect.
Automate.
01
Recording the process as it really runs
I look at what actually happens, not what the handbook says. Who does which step, how often, how long it takes, and where the errors appear that someone corrects later. That tells us which part is worth automating and which part is better left to a person.
02
Integration with existing systems
Inventory management, ERP, shop, CRM. There is usually an interface, sometimes only a database or a file export. I connect to what is there instead of making a system replacement a precondition. Where an interface is missing, it gets built properly rather than worked around.
03
The workflow as a service, not a tool chain
The automated process becomes a service like any other: in Git, in the pipeline, with tests and a deployment. Event-driven so individual steps can be retried, and idempotent so a second run does no damage.
04
Errors, exceptions and the human in between
No process is a hundred per cent automatable. Exceptions do not disappear into nowhere, they land in a queue with clear ownership. Where a decision needs a person, it gets presented to them with the context they need to make it.
05
AI where rules run out
Free text, receipts, unstructured documents. This is where a language model is the right tool, embedded in the workflow, with a confidence threshold and a fallback to manual review. The rest of the process stays deterministic, because it should be.
06
Traceability and operations
Every run is logged: what came in, what was decided, what went out. Plus monitoring on throughput and error rate, so a process that starts drifting becomes visible before the department reports it.
A workflow eating days every month?
Let’s spend 30 minutes working out whether automation pays off.
How it runs
From workflow to service.
The first process goes live early. You decide on everything after it once you have seen the benefit.
STEP 01
Name the process
Which workflow eats the most time or causes the most errors. 30 minutes is enough to place it.
STEP 02
Survey, 1–2 weeks
Volumes, interfaces, exceptions. The result: what can be automated, with effort and savings attached.
STEP 03
First process live
One workflow completely rather than five halfway, including error handling, logging and monitoring.
STEP 04
Follow through
Further processes on the same foundation. Each one after the first is cheaper than the first.
The outcome
What is no longer on anyone’s desk.
Time you get back
Repetitive handwork disappears. The department handles exceptions instead of routine cases.
A workflow that does not depend on people
Holiday, illness or a resignation no longer bring the process to a halt.
Traceability
For every run it is documented what happened and why. Months later as well.
Technologies I use
Proven tools. No experiments.
Languages
- Golang
- PHP 8
- Python
- TypeScript
- SQL
Events
- EventBridge
- SQS
- SNS
- Step Functions
- Apache Kafka
Interfaces
- REST
- SOAP
- gRPC
- API Gateway
- Webhooks
AI building blocks
- Amazon Bedrock
- Textract
- RAG
- Prompt engineering
Data
- PostgreSQL
- MySQL
- DynamoDB
- S3
- AWS Glue
Platform
- ECS Fargate
- Lambda
- ECS
- EKS
Infrastructure
- Terraform
- AWS CDK
- Docker
- GitLab CI
Operations
- CloudWatch
- Grafana
- Prometheus
- Datadog
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 replace workflows where people copy data between two systems. 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.
Common questions
Before you ask.
Wouldn’t an automation tool like n8n or Make be enough?
For a bounded workflow with stable interfaces, quite possibly, and I will tell you so. I come in when the process is business critical, when it has to reach systems with real permissions, or when it has to be traceable who triggered what and when. The difference does not show up on day one. It shows up the first time an interface changes.
Do we have to replace our systems for this?
No. I connect to what is there: an interface, a database or a file export. Making a system replacement a precondition would push the automation out by years and put the benefit at zero until then.
How do we know it pays off?
From the volume figures in the process survey: how often the workflow runs, how long it takes, how much rework it generates. If the numbers do not add up, I say so. The more honest recommendation is then to simplify the process, or leave it alone, rather than automate it.
Is there AI in all of this?
Only where rules run out: free text, receipts, unstructured documents. The rest stays deterministic, because a workflow that should do the same thing every day ought to do the same thing every day. A language model is a tool inside the process, not the process.
What happens to the people doing this today?
In the projects I know, they end up handling the cases that genuinely need a decision instead of working through routine ones. What that means in your company is your call. My job is to put the numbers on the table.
Other services
What else I help with.
Backend development
Backends for SaaS and platforms that hold under real load: Go and PHP 8, event-driven, with tenant isolation and recovery designed in.
Learn moreLegacy 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 more