In February 2014 I was twenty-two, halfway through an M.Tech, and convinced I could build a marketplace that would change how local vendors sold online. Three years later the platform was serving eighty-plus vendors, processing real money, and I signed the papers that handed it to someone else.
This is the short version of that story, and the seven things it taught me.
The Setup
Small vendors in our region had no affordable way to sell online. Big marketplaces charged steep commissions and buried small sellers. We wanted to build a multi-vendor platform where each shop got its own storefront with shared logistics, payments, and traffic.
My co-founder handled business. I handled everything that touched a terminal. We bootstrapped — no angel round, no incubator. Every hour of engineering time came directly out of the hours I was supposed to spend on coursework.
Building on a Twelve-Dollar VPS
I picked Java and Spring for the backend, MySQL for persistence, jQuery for the frontend. Not trendy, but I trusted it wouldn't collapse at midnight when I was the only person on call.
The MVP took ten weeks of nights and weekends. One Spring monolith, one database, one Tomcat server on a VPS that cost twelve dollars a month. It was ugly. It worked.
The first real challenge was payment integration. Two Indian payment gateways, each with its own callback format, retry logic, and definition of "success." I wrote an adapter layer that normalized both into common internal events — PAYMENT_CAPTURED, PAYMENT_FAILED, PAYMENT_REFUND_INITIATED — so the rest of the order pipeline didn't care which gateway handled a transaction. That pattern ended up being the most reusable code in the entire system.
Scaling and Cracking
Each new vendor exposed a new edge case. Weight-based items. Variant pricing. Bundle deals. Every feature request was a negotiation between "this helps one vendor" and "this complicates things for everyone."
Around vendor forty, the monolith started cracking. Page loads crept past three seconds. I extracted the inventory service into its own process with its own database. Not a full microservices migration — one pragmatic extraction that relieved the biggest bottleneck.
Meanwhile I was attending lectures from 9 AM to 1 PM, building the platform from 2 PM to midnight, and squeezing thesis research into whatever gaps remained. The saving grace: every distributed systems concept from the M.Tech curriculum — consistency models, fault tolerance, CAP theorem — I was seeing in production the same week I read about them in papers. The gap between theory and practice wasn't a gap. It was the same Tuesday.
The Exit
By early 2017 the platform was profitable but growth had plateaued. A regional eCommerce company approached us. They wanted our vendor network and our technology — specifically the vendor management system and the payment adapter layer, which they said would save them six to eight months of development.
The negotiation took two months. We closed in May 2017. The terms were fair. The vendors kept their storefronts, the customers kept their accounts. I walked out with no regrets and a clear picture of what I wanted next: building at larger scale, which eventually led me to Oracle Financial Services, Kotak Securities, and AirAsia where I now work on systems processing 130 million daily transactions.
Seven Lessons for Technical Founders
1. Ship the ugly version first. Our MVP was architecturally embarrassing. It was also live, collecting payments, and teaching us what users actually needed. The beautiful rewrite can happen after you've proven the business.
2. Pick boring technology. Java and Spring in 2014 won zero hackathons. But when our payment integration broke at midnight, I could find a Stack Overflow answer in under a minute. Boring technology compounds reliability.
3. Solve the class, not the instance. When vendor thirty-seven asks for a feature, ask what general problem it represents. Build the general solution or don't build it at all. Every special case is a maintenance liability that outlives whoever requested it.
4. Wrap every external dependency in an adapter. Payment gateways, shipping APIs, SMS providers — they will change their interfaces, go down, or get replaced. Your codebase should never know or care which vendor sits behind the adapter.
5. Cofounder alignment beats cofounder skills. We never argued about direction because we agreed on the fundamentals before we started: bootstrap, stay profitable, build something vendors actually use. Technical skills can be hired. Strategic alignment cannot.
6. Know your exit conditions before you need them. We didn't have a formal trigger for when to sell, and that made the decision more emotional than necessary. Write down the conditions under which you'd sell, shut down, or raise money — before you launch.
7. Burnout is not a badge of honor. I pushed through it because I was young and stubborn. One full day off per week would not have killed the company and would have made me a better engineer the other six days.
That startup gave me scars and skills in roughly equal proportion. If you're building something right now — side project, startup, internal tool at a company that doesn't appreciate it — the work compounds. The code you're embarrassed by today teaches you to write something better tomorrow.
Originally published on krishnakky.com — the full version has more detail on the technical architecture, payment integration patterns, and the acquisition negotiation.
Top comments (0)