Why I Started Coding
No, it wasn’t because Obama urged that everyone should code. Nor was it Zuck or Gates who inspired me. It was a simple need of the hour — to take back control.
I run Tushky.com. Tushky was an online marketplace for real-world leisure experiences, backed by 500 Startups (Batch 6, 2013). We started with no CTO or a dedicated tech team. We just took the “leap of faith” without planning or thinking too much — which had its upside and its downside. When we started in September 2011, the initial understanding was that the business was tech-enabled and operations-intensive, needing only basic tech support. Over time, we realized that apart from operations, the business needed a strong tech team to build the product.
But getting developers on board turned out to be a brutal affair. Either it was too costly, or the developers acted too pricey. Made some wrong hires, who we had to fire. Made some good hires, who we had to let go due to their demands. In all, lost a lot of time and money. And in December 2013, we were back to square one with no developers on board.
The larger problem was that I could define the product but could not make or maintain it without a developer. That dependency left the company exposed.
The breaking point came when a developer vanished without sharing the documentation or the access keys. I cannot remember any other moment when I felt so helpless and out of control. That very moment, I decided — enough of this — and took it upon myself to code and build my product. And I cannot be happier.
In 12 weeks, I fixed long-pending bugs, improved existing features and built a new web tool for our sellers.
Learning to code gave me direct control over Tushky’s product alongside sales, marketing and operations. My conclusion was simple: at least one founder of a technology company should be able to understand and change the product directly.
The usual counter-arguments are:
- You’re a CEO, you have more important things to do
- You’re a CEO, you should delegate
- Focus on your strengths
Unless you have reached or crossed the expansion stage, you have nothing more important than controlling how the product is shaping up.
That conviction never left me. If anything, it deepened. At Zopdev, where we are building agentic cloud infrastructure, the instinct is the same: a founder who cannot read the system cannot steer it. The problems have grown more abstract — distributed systems, provisioning pipelines, AI agents managing infrastructure state — but the principle is unchanged. You have to be able to look at what the machine is doing and understand it, not just trust that it is doing something. Systems thinking is not a skill you hire for at the early stage. It is something you build into yourself, one frustrating debugging session at a time. That developer who vanished without sharing the access keys did me an accidental favor. The full Tushky story — from the leap of faith to the shutdown — traces the same arc: every infrastructure bottleneck a founder tolerates eventually becomes the thing that breaks them.