Watch first. Build second.
I start the day you are ready. But I will not touch a process before I understand it, so the first week runs slower on purpose. The most expensive automations are the ones built before anyone understood the work.
The process
Five stages, in order
Conversation
A short call to understand the business and work out whether I am the right person. If I am not, I will say so and probably point you somewhere better. No charge, no obligation.
Instant start
There is no waiting period. Once you are ready, I begin. Access, tooling and communication channels get set up on day one so nothing is blocked on admin.
The first week
Expect output to be slower for roughly seven to ten days. I am learning how the work actually runs: where the time goes, which parts need judgement, what breaks when you are away, and why things are done the way they are. This is the stage that makes everything after it smooth.
Proposal & pilot
A written scope covering what gets done, what it costs and explicitly what it does not include. Then one narrow piece delivered first, so you can judge real work before committing to more.
Delivery & handover
Full-speed execution, with SOPs written as I go and recordings for anything that needs explaining. The role stays transferable rather than dependent on me.
All work is delivered remotely from Kolkata, India, on your working hours. Regional hours are set out here.
Principles
How I make decisions
These are the rules I actually apply, including the ones that cost me money.
I will tell you not to automate something
If a rule can be written down, a deterministic automation beats an AI one on cost, speed and reliability. Sometimes the honest answer is that you need a process change, not software.
The first week is not a formality
Building before watching is how you get elegant pipelines for processes that should have been deleted. I would rather spend a week understanding than a month rebuilding.
Everything gets documented
SOPs and recordings as standard. If you ever replace me, the next person inherits a written system rather than a mystery.
Failures should be loud
Every automation I build has error handling and failure notifications. An integration that breaks silently is worse than no integration at all.
One person, start to finish
No subcontracting and no handoffs. It limits how much work I can take, which is the tradeoff for consistency.
Your tools, not mine
I work inside the stack you already have. Migrations happen only when the current tool is genuinely the problem.
Questions
About working together
How long does onboarding take?
Why not start at full speed immediately?
What if it is not working out?
Do you document what you do?
How do we communicate day to day?
Is the work done remotely?
Start here
Stage one is just a conversation.
No charge, no obligation, and an honest answer about whether I am the right person for it.