I Was Not Supposed to Build This
I'm Om Avchar. Third-year Computer Science student at GWCET, Nagpur. Class of 2027.
By all conventional measures, I should be grinding LeetCode for placements, attending every class, and planning my internship applications in spreadsheets.
Instead, I spent the last two years building a production AI platform from my hostel room, scaling it to 550,000 users, watching it fall apart at 3am, fixing it, and building it again.
I'm not writing this to brag. I'm writing it because I wish someone had told me the things I'm about to write before I started. The technical stuff, sure — but more importantly, the things that have nothing to do with code.
The Beginning: A Problem I Lived Inside
HeartEcho didn't start as a startup idea. It started as frustration.
Every AI chat platform I tried felt foreign. The language was too clinical. The cultural references were wrong. Nobody using these tools seemed to understand that I don't speak in clean, grammatical English — I mix Hindi and English in every sentence without thinking. My humor is different. My context is different. My problems on a Tuesday evening in a hostel in Nagpur are different from someone's in San Francisco.
I thought: someone should fix this. Then I thought: why not me?
I had Node.js. I had an OpenAI API key. I had a laptop. I had time I probably should have spent on college assignments.
I started building.
The First Thing I Learned: Scaling Breaks Everything You Assumed Was Fine
The early version of HeartEcho worked perfectly. It worked perfectly for me, for my five friends who tested it, and for maybe fifty people who signed up the first week.
Then something happened that I wasn't prepared for: people started actually using it.
At around 1,000 concurrent users, everything that worked before stopped working at the same time. The Node.js process was choking. Response times went from 300ms to 8 seconds. The Redis cache I'd implemented wasn't being used correctly — it was caching the wrong keys and hitting the LLM API for responses that should have been served from memory. Nginx wasn't configured for sustained load. Error logs were overflowing with things I'd never seen in development.
I had to learn system design not from a textbook, but because the alternative was the product dying in front of real users.
What I built to fix it:
- A custom Priority Queue for AI scheduling — so paying users' requests never got queued behind free tier traffic. Simple idea, enormous impact on perceived performance.
- Redis Emotional Cache — I named it that. It caches the contextual state of a conversation, not just static data. Sub-12ms retrieval on warm requests. Before this, every message in a conversation was re-fetching context from the database.
- 4 Node.js cluster workers with Nginx sticky sessions — so a user's session would always hit the same worker process, maintaining in-memory context without cross-process state sharing.
Did I know how to build all of this before I needed to? No. I read, experimented, broke things in staging, and deployed when I was 70% confident it would hold. That last 30% you learn from production.
The Second Thing: Your Real Competitors Are Attention and Friction
Before I launched HeartEcho, I thought my competition was other AI chat apps.
I was wrong.
My real competition was:
- The three seconds of loading time after which someone closes the tab
- A confusing onboarding that never explains the value before asking for a signup
- The notification from Instagram that arrives right as someone is about to engage with my product
- A payment flow that adds one too many steps and loses the user at checkout
Nobody is sitting down to choose between HeartEcho and another AI product with a checklist. They're distracted, impatient, and swimming in options. The product that wins isn't necessarily the best one. It's the one that removes friction fast enough to keep the user engaged before their attention moves somewhere else.
Every second of loading time costs real users. I obsessed over this.
I profiled every API call. I pre-warmed the most common conversation contexts in Redis at startup. I moved image assets to a CDN. I reduced the initial JS bundle by removing dependencies I'd added without thinking. Each optimization felt tiny. Together, they dropped average response time from ~1.8s to ~280ms on warm requests.
Speed is not a feature. It's respect for the user's time.
The Third Thing: Support Emails Teach You More Than Analytics
For the first six months, I personally answered every support email.
Not because I had to — I could have just added a contact form that went nowhere, like most early apps. I did it because I was curious. What are the people who reach out actually experiencing? What made them frustrated enough to type a message instead of just leaving?
What I found was not what I expected.
Very few support emails were about technical bugs. The majority were about emotional expectations — users who felt the AI companion didn't understand them, or users who had gotten deeply engaged and were confused about a pricing change, or users who wanted to tell me something they'd experienced using HeartEcho that had genuinely helped them through a difficult week.
Those last emails were the ones I saved.
It's easy to get lost in metrics. DAU, MAU, churn rate, conversion rate. These are real and important. But they don't tell you why someone who cancelled their subscription cried a little when they typed "I'm deleting my account."
User research is not a phase of product development. It's a continuous practice that never ends.
The Fourth Thing: Winning Hackathons Taught Me to Pitch, Not to Build
I've won five national hackathons — including ones at NIT Rourkela and AIT Pune.
People assume hackathons are about building the best product. They're not. They're about communicating the value of what you built in a very short window of time, to judges who are tired and have seen thirty other pitches that day.
The best hack I built at a competition was technically impressive but I presented it badly. Third place.
The second-best hack I built was simpler, but I knew exactly how to tell its story — the problem, the insight, the demo that hit the emotional note I needed to hit. First place.
This felt unfair at first. Then I realized: the real world doesn't work differently. A better product with a worse pitch loses to a good product with a great pitch, every time. Investors, users, and media all respond to narrative first.
Building the thing is necessary. Explaining why it matters is the skill that most engineers — including me for a long time — are embarrassingly underdeveloped in.
The Fifth Thing: LeetCode Is Not the Same as System Design, and Both Are Not the Same as Shipping
I have a LeetCode rating of 1,396. I can solve medium problems in reasonable time. I understand graph traversal, dynamic programming, and binary search at a level that would pass most campus placements.
None of that prepared me for the moment when HeartEcho's Kafka consumer fell behind by 40,000 messages during a traffic spike because I hadn't set the right fetch.min.bytes and fetch.max.wait.ms configuration for my throughput profile.
These are different skills:
Competitive programming trains pattern recognition on well-defined algorithmic problems with known solutions. It's a useful mental gym.
System design is about making tradeoffs under constraints — consistency vs. availability, read throughput vs. write throughput, cost vs. latency. There's no single right answer.
Shipping is about making decisions with incomplete information, under time pressure, with real users waiting. It's uncomfortable in a way that neither LeetCode nor system design whiteboards prepare you for.
You need all three. But pretending that grinding LeetCode is sufficient preparation to build real systems is the thing that keeps so many smart engineers from ever shipping anything.
The Sixth Thing: Being a Student Is a Structural Advantage, Not a Disadvantage
Every job posting says "3-5 years of experience required." Every investor wants to see traction before they'll talk to you. Every senior engineer has opinions about the right way to build that you lack the authority to challenge.
I used to think being a 3rd-year student was something to apologize for.
Then I realized: students have structural advantages that most working professionals would pay for.
- Time to experiment — I can spend two weeks trying a completely different architecture without worrying about quarterly reviews
- Subsidized risk — I live in a hostel. My personal burn rate is approximately zero. I can build without needing immediate revenue
- Access to brilliant people — my professors, hackathon judges, and mentors will take meetings with a curious student that they wouldn't take with a random cold email from a founder
- No sunk cost — I have no legacy system, no existing users to protect, no shareholders who expect consistency. I can rethink everything from scratch tomorrow if I need to
The constraint isn't being a student. The constraint is believing that being a student means you're not ready. You are. The tools are available. The infrastructure is accessible. The only thing missing is the decision to start.
What I'm Still Figuring Out
I want to be honest: there's a lot I don't know yet.
I don't know how to manage a team. I've built everything solo, which means I've never had to explain my architecture to another engineer, align on a technical direction, or deal with the specific interpersonal difficulty of giving feedback to someone whose code you depend on.
I don't know how to raise money properly. I've never done a seed round or dealt with term sheets.
I don't know how to build a brand sustainably. HeartEcho's growth has been organic — I've been lucky with word-of-mouth and some distribution wins. I don't have a repeatable acquisition playbook.
These are the things I'm working on now. And I'm comfortable saying I don't know them, because the list of things I didn't know eighteen months ago and now know well is long enough to give me confidence that the next set of unknowns is learnable too.
If You're a Student Reading This at Midnight
You are not behind. You are not too young. You are not lacking experience.
You are at the beginning of a very long compounding curve, and the only thing that matters right now is whether you're building momentum or letting it slip.
The laptop is open. The APIs are affordable. The cloud is accessible.
The only question is whether you will write the first line of something real tonight, or open Netflix instead.
I'm not here to judge either answer. But I know which one you'll be glad you chose.
Om Avchar is a 3rd-year CS student at GWCET Nagpur, the founder of HeartEcho, and a backend engineer obsessed with distributed systems and high-concurrency architectures. He's been known to debug Redis configuration at 3am and consider it a good evening.
