I want to tell you about the most chaotic, frustrating, and honestly hilarious chapter of my life as a developer.
The Job That Taught Me Everything (Except Boundaries)
Before all of this, I was working at a company as a Python Developer. Junior title, but the work was anything but junior. I ended up handling Cloudflare security, cloud integrations, API integrations — things way outside my job description. Nobody asked me to. I just did it because someone had to.
Looking back, that job gave me a dangerous amount of confidence. I thought I could handle anything.
Eventually things went sour with our team lead. He ran the team like a closed room — no opinions, no pushback allowed. That's a story for another post. But leaving that place felt like breathing fresh air for the first time.
So naturally, we decided to start a company.
The Google Meet That Started Everything
It was 2024. Late night. Four friends on a Google Meet call.
My friend painted the picture: "It's just websites. Just dashboards. We build, we deliver, clients pay. Easy."
We were excited. The kind of excited where you skip past every red flag because the dream feels too good to question. We had some concerns — no template library, no portfolio, no clients — but we talked ourselves through all of it.
"We'll scrape paid templates from Envato, edit them, deliver. Simple."
Within days we had bought hosting, a domain, and an Envato Elements subscription. The website went live. We gave ourselves titles — CEO, CTO, CSO, Founder — and sat back waiting for orders to roll in.
They did not roll in.
I know. Shocking.
The First (and Last) Client
A few weeks passed. I put up a WhatsApp status about our services. An old friend messaged me almost immediately.
"Bhai, I have a client who needs a dashboard."
We were so ready for this. We'd read about Agile methodologies. We asked for a requirements document like professionals. The friend said the client was non-technical, offered a call instead. We said sure.
Then came the first warning sign, delivered casually: "By the way, this client has been messed around by the previous dev team for a month. Half the team disappeared. Oh, and the client doesn't know."
We should have walked away. We didn't. Old friend, old loyalty. We said we'd handle it.
The brief was simple: a static dashboard with some ChartJS graphs. Student client, tight budget. We quoted fairly, sent a proper proposal via email, got approval, and started.
Scope Creep, Meet Chaos
What followed was a masterclass in everything that can go wrong on a project.
Changes came. Then more changes. Then a WhatsApp group appeared with the client sending voice messages. Budget got revised upward, client said yes every time. We kept building. I was handling the mailing, the project management, the development — basically everything.
When two dashboards in Next.js were finally ready, the client looked at them and said: "The design doesn't match Amazon Seller Central."
I'm a UI guy. Unfortunately. So I matched it. Client was happy. For about three days.
Then our developer got sick. Source code was on his local machine. No repo. Four days of radio silence. My other friend and I kept the project alive by literally changing our names in communications so the client wouldn't notice the team had half-collapsed. I'm laughing writing this, but it was not funny at the time.
When the developer came back, there was a misunderstanding, then an argument, then an uneasy truce because the project wasn't done yet.
The Middleman Problem
Here's the part that still gets me.
All this time, our old friend — the middleman — was relaying messages between us and the client. The client would tell him about new features. We'd send updated quotes and approval documents directly to the client. The client was not reading our emails. He was just telling the middleman what he wanted and assuming it was included.
Nobody caught this until the very end.
When we finally connected all the dots in a proper meeting, we realized the client had no idea what was in our quotes. He thought everything he'd asked for verbally was already covered. We'd been billing for additions he didn't know existed.
To protect the old friendship, we absorbed it. Took the blame. Moved on.
The final invoice was supposed to be $53.78. The client had already paid $35.86. Then, because one advanced feature couldn't be implemented, he said he'd only pay $25.10.
We agreed. Just to close it out. Just to be done.
What Came After
The project ended. And so did the company.
My friends blamed me — it was my reference, my contact, therefore my fault. That hurt more than the $25. I felt like I was the only one who understood what had actually gone wrong, and no one was interested in hearing it.
We went our separate ways.
What I Actually Learned
Not "don't start a startup." Startups are fine. The lesson was more specific than that:
Don't build a company with friends before figuring out who does what. Titles are not roles. CEO doesn't mean anything if there's no sales process, no accountability, no structure underneath it.
Sales comes first. Every student developer I know — myself included, back then — thinks the product is the hard part. It isn't. Getting clients, managing them, scoping projects clearly, following up — that's the hard part. Hire for that first. Everything else can scale later.
Document everything. In writing. Acknowledged by the client. Voice messages in a WhatsApp group are not a contract. A middleman's word is not a contract. If the client didn't read the email, that's a process failure, not just bad luck.
A bad project start doesn't get better with effort. We poured ourselves into that project hoping quality would fix the chaos underneath. It didn't. Sometimes the right move is to stop early.
I'm sharing this because I see a lot of junior developers romanticize the "startup with friends" idea. Sometimes it works beautifully. Sometimes you end up renaming yourself in email threads to hide the fact that your team has fallen apart.
Both outcomes are possible. Just go in with your eyes open.
This is part of an ongoing series where I write about building things — the wins, the disasters, and everything in between.