That order matters more than it sounds. Most of what makes an automation survive isn't technical, it's knowing which parts of a process people quietly work around.
I trained as a mechanical engineer at NUST and I'm a registered engineer with the Pakistan Engineering Council. What engineering actually taught me had very little to do with machines. It taught me to assume things fail, to ask what happens at the edges, and to be suspicious of a design that only works when everyone behaves.
Then I spent three and a half years at a digital agency, starting as an SEO manager and finishing as general manager. Delivery, hiring, business development, the lot. That's where I learned what a broken process actually costs, because I was the one absorbing it. Somebody rebuilding the same report every week isn't a line item, it's a person you can't give better work to.
Alongside that I ran a short-term rental operation. I took occupancy from under 47% to just over 65% in four months and moved it from an operating loss to break-even in the first month. Small numbers on a small business, but it was mine, and every one of those points came out of a process I had to fix myself rather than delegate.
Now I build the systems instead. Same instinct, different output.
Automating the easy 90% and flagging the rest beats automating 100% badly. On the kitchen system some orders carried allergy information, so anything unverifiable stops and waits for a person. That decision cost some automation and it was obviously right.
Built on your accounts, documented on handover, no dependency on me answering an email. The measure I actually care about is how long a system runs after I stop looking at it.
I test assumptions against the live service. On one build, three separate APIs behaved differently from their own docs, and every one of those would have been a silent failure three weeks after handover.
You get the person who scoped it building it, which is the reason briefs don't get lost in translation and the reason I can tell you on a first call whether something is worth doing. Nobody is protecting a utilisation target by saying yes to your project.
The flip side is real too. I'm not an agency, so I can't put four people on something to hit a date, and if a build is genuinely large I'll tell you that rather than take it and go quiet. I take on subcontracted overflow from agencies as well, which is a different arrangement, described here.
I'm based in Islamabad and I work with clients across Europe and North America, which mostly means my afternoons belong to Europe and my evenings to the US east coast. It's never been the problem people expect it to be.
I hold certifications from Zapier, n8n, Make and IBM, all of which link out to the issuer so you can check them rather than trust them. There's a page explaining what each one actually covers, including the parts a certificate can't tell you.
Twenty minutes, no deck. You'll know by the end whether it's worth doing, including if the answer is no.
