From Engineering Student to AI CTO at 25

The Overconfident Beginning

When I co-founded Sunbots in 2019 at 23, I was confident I understood what being a CTO meant: technical excellence, good architectural decisions, writing clean code. I had a computer engineering degree from GTU, two years of building projects, and a genuine excitement about AI's potential. What I didn't have was any clarity on the other 70% of the job.

The first six months were a crash course in everything a CTO actually does beyond writing code. Here's the version I wish someone had told me — organized around the gaps that were most painful to discover late.

What I Got Right Early

Domain focus over resume optimization. I chose to go deep on computer vision and Gen-AI rather than building a broad generalist ML background. This was a good bet — depth compounds faster than breadth in a field where hiring managers can tell within 15 minutes whether someone understands the hard problems or just the vocabulary.

Building before the field was crowded. In 2019, "AI startup" in Ahmedabad was a relatively unusual combination. This gave us time to learn in production without as much competitive pressure as we'd face if we started today. The timing advantage was partly lucky; I'd take it again if I could.

Choosing the right co-founder dynamic. My co-founders and I had complementary capabilities: I owned technical direction, they owned operations and business development. This meant we weren't competing over the same decisions and we weren't neglecting entire company functions.

The Gaps That Cost Me the Most Time

People management: Leading a technical team is different from being the most technically capable person on the team. In the beginning, I conflated the two. I held technical opinions too strongly, overrode engineer judgment when I should have asked questions, and created a dynamic where engineers brought me solutions instead of problems.

The shift that helped: I started treating my engineers' technical decisions as opportunities to understand their reasoning rather than evaluate their correctness. An engineer who can explain why they chose a particular approach has thought through the problem in ways I may not have. An engineer who can't explain their reasoning needs help thinking, not override.

Estimating complexity: I was systematically optimistic about implementation timelines, especially for AI components with research uncertainty. The pattern: estimate from the best-case path and ignore the 40% chance that the core technical approach doesn't work and requires a reset.

Better pattern: estimate from the median case, not the best case. For AI projects with genuine research uncertainty, add a "what if this doesn't work" branch to your timeline that extends the estimate by 50–100%.

Client communication under uncertainty: Engineers learn to communicate with precision. "We don't know if this approach will work" is precise — it's honest about the uncertainty. It's also a bad answer to a client who needs to make a decision about whether to continue investing.

Better answer: "Here's what we'll know by [specific date], here's the decision we'll need to make at that point, and here are the two paths we're considering depending on what we learn." Same underlying uncertainty, but framed around the decision rather than the unknowing.

What I'd Tell Myself at 23

Build in public earlier. I spent the first two years building in relative obscurity — sharing progress internally but not externally. The relationships and credibility I'd have built by sharing earlier would have compounded significantly.

Say no to more projects sooner. The instinct to say yes to every interesting project — because it seems like an opportunity — leads to a team spread across too many contexts. The best AI work I've done has come from focused, long-running engagements where we could develop real domain expertise.

Find advisors who've done this specifically. General startup advice from general startup mentors is widely available and often inapplicable to AI companies. AI-specific advice — about research risk, model evaluation, the gap between demo and production — is rarer and more valuable. Find it actively.