← Back to all articles

OverEngineering as a Service

February 21, 2026

It's January and as usual I open my twitter, the entire timeline is taken over by everyone singing praises and posting crazy demos of a tool called "clawd", the hype is so much that people are buying mac minis just to run this tool. On the first glance it's just another side project, but its magic is that it connects with all your messaging apps like telegram, whatsapp and lets you perform actions on your desktop from these messaging apps. There's no need for you to manually run everything, it's just on all the time. I found the most interesting thing to be the whatsapp integration, fascinated by it, I saw that it uses a library called Baileys. Now writing code with baileys each time and keeping it running felt cumbersome, and the script itself felt really long and unnecessary to run. So what did I do? Something very normal — I built an entire service on top of it called Wataki. API, SDK, observability dashboard, landing page, docs, a complete end to end product.

Previously the constraints were both time and money, a product like the above would require weeks of effort. Now all you do is just prompt Claude or Codex to just build build build. Your job is to test it out, ensure the experience matches what you want and iterate accordingly.

But here's the thing nobody's really talking about. It's not just that building got cheaper. It's that the relationship between the size of your problem and the size of your solution has completely broken down.

There used to be a forcing function. Small problem, you write a script. Big problem, you build a product. The cost of building kept everything proportional — you couldn't justify a dashboard for a personal inconvenience, a team would never greenlight it, the economics would never make sense. That ratio was basically a law of software.

That law is gone.

I had a personal inconvenience with a library and the proportionate response was an entire B2B SaaS product. Wataki didn't come from a market research doc or a YC application. It came from a script that annoyed me on a Tuesday. The solution had no idea how small the problem was.

And I think this is producing a completely new category of software. Products that exist not because someone identified a gap in the market, but because someone had a friction so small they wouldn't have even complained about it out loud — and the cost of overbuilding was a Claude subscription.

That's the era we're in. Every little inconvenience is now a valid reason to build a company.

If you want to try out Wataki, here is the link