How a project works

We map the current process together: what triggers it, what tools are involved, what a human currently does at each step, how often it runs, and what edge cases or exceptions exist.

I will tell you upfront if the process is not worth automating, if it requires more complexity than the value justifies, or if a simpler fix exists. No interest in selling you a build you do not need.

Output: shared understanding of the process, initial assessment of automation potential, tool recommendation, and a rough timeline estimate.

A written proposal covering: exact scope, deliverables, tool choices, data residency approach (revDSG/GDPR considerations where relevant), timeline, and price in CHF.

Fixed-price for projects with a well-defined scope. Time-and-materials for exploratory work, phased builds, or projects where requirements evolve. No surprises either way — cost and scope are agreed before work starts.

I build and test in stages. You see the workflow functioning on real (or realistic sample) data before it is complete. This surfaces edge cases and integration issues early, when they are cheap to fix.

Error handling is built in from the start — not added at the end. Every production workflow includes failure notifications so you know immediately if something breaks, rather than discovering it three days later.

I use a sandbox environment where the tool supports it (Google Workspace, Salesforce, HubSpot all have sandboxes). For tools without sandboxes, I use test data and limited-scope runs before going live.

Testing covers the normal path, edge cases (missing fields, unusual input formats, API timeouts), and volume (what happens at 10× expected load). I test failure scenarios deliberately — not just the happy path.

You are involved in testing. You run it against your own data, in your own environment, before I call it done. If something does not feel right, we fix it before handover.

Full written documentation: what the workflow does, what to watch in the logs, how to edit simple settings without breaking it, and what to do if something fails.

A 60–90 minute walkthrough call where I explain every part of the build. The goal is that you understand what was built and why — not just that it runs.

A 30-day support window after go-live where I fix anything that breaks on real production data. Production always surfaces something a test environment did not.

Most clients handle routine operation themselves after handover. When requirements change — new tools, new edge cases, new processes — I am available project-by-project.

Some clients with ongoing automation needs move to a monthly retainer covering a fixed number of build hours. This works well for teams that want continuous improvement without recruiting a full-time automation engineer.