five ways in.
every one of them priced.

a week of my time to map where your hours go, and a straight answer on what to buy, what to deploy and what to build. it is the only sensible first step if you don't already know what's broken.

• →a written map of every manual process, costed in hours and money
• →a ranked list of what's worth fixing first, and what to leave alone
• →buy / deploy / build called for each one, with named products and real prices
• →a fixed quote for whatever comes next, or a recommendation to do nothing

send me the workflow that broke. this is for the situation where somebody built you an automation, it stopped working, and nobody left in the building knows what's inside it.

• →a written explanation of why it failed, in language you can forward to your team
• →what it would cost to make it reliable
• →a straight answer on whether it's worth saving at all

a diagnosis, not a fix. the fix is quoted separately, and this fee comes off it.

the right existing product or open-source project, chosen, deployed, integrated and taught to your team. this is the outcome i recommend most often, and it's the smallest invoice on this page for a reason.

• →selection with the trade-offs written down, not just a recommendation
• →deployment into your own infrastructure, configured and hardened
• →integration with what you already run, and training for the people who'll use it

software built for how your business actually works — for the case where no product fits, or where stitching three products together would be more fragile than one purpose-built system.

• →evaluations, so we can both see whether it's actually working
• →error handling and monitoring, with alerts that reach me before they reach you
• →a runbook, and training for whoever will own it
• →full handover: code, documentation, credentials. no proprietary runtime, no lock-in
• →thirty days of tuning after launch, included

weekly demos while it's being built. you see it working, or not working, every week — never a reveal at the end.

systems drift. models change, apis change, your business changes. i watch what i built, fix it when it breaks, and improve one thing a month.

• →monitoring and alerting on everything i've built for you
• →fixes inside stated response windows, within uk and eu overlap hours
• →one improvement a month, chosen by you
• →a monthly note on what ran, what broke, and what it saved