← Back to blog
Career10 min read

From Startup to Acquisition: What I Learned Building and Selling a Multi-Vendor eCommerce Platform

What I learned co-founding a multi-vendor eCommerce platform while finishing my M.Tech — from first line of code to signing the acquisition papers.

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. Between those two dates I learned more about software, about business, and about myself than any classroom ever offered.

This is the unvarnished version of what happened and what it taught me.

Why We Started

The idea was simple enough to fit on a napkin. Small vendors in our region — clothing stores, electronics shops, handmade goods sellers — had no affordable way to sell online. The big marketplaces charged steep commissions and buried small sellers under algorithm-driven rankings. We wanted to build a multi-vendor platform where each shop got its own storefront inside a shared ecosystem, with shared logistics, shared payments, and shared traffic.

My co-founder handled the business side: vendor onboarding, logistics partnerships, the pitch deck we never actually used for fundraising. I handled everything that touched a terminal. In hindsight, that split was one of the best decisions we made. Neither of us pretended to be full-stack humans — we stayed in our lanes and trusted the other lane was moving.

We bootstrapped. No angel round, no incubator, no safety net. The upside was total control. The downside was that every hour of engineering time came directly out of the hours I was supposed to spend on coursework.

Building the MVP

I chose Java and Spring Framework for the backend, MySQL for persistence, and plain server-rendered HTML with jQuery for the frontend. Not because it was trendy — Spring was far from the cool kid in 2014 — but because I already knew it, the documentation was excellent, and I trusted it wouldn't collapse under load the way a framework I'd learned last week might.

The MVP had four pieces:

  1. Vendor management service — onboarding, product catalog CRUD, storefront configuration.
  2. Order pipeline — cart, checkout, payment capture, order state machine.
  3. Inventory sync — real-time stock tracking across vendors so we never sold a product that wasn't actually available.
  4. A thin customer-facing frontend — product search, vendor pages, checkout flow.

I built the first working version in about ten weeks, working nights and weekends. The code was a monolith — one Spring application, one MySQL database, one Tomcat server running on a rented VPS that cost the equivalent of twelve dollars a month. It was ugly. It worked.

Payment integration was the first real engineering challenge. We integrated with two Indian payment gateways because neither one alone covered all the payment methods our vendors' customers used. Each gateway had its own callback format, its own retry logic, its own definition of what "success" meant. I wrote an adapter layer that normalized both into a common internal event — PAYMENT_CAPTURED, PAYMENT_FAILED, PAYMENT_REFUND_INITIATED — so the rest of the order pipeline didn't care which gateway handled a given transaction. That adapter pattern ended up being one of the most reusable pieces of code in the entire system.

For inventory, I went with optimistic locking on the database. When a customer added an item to cart, we didn't reserve stock — we checked availability at cart-add time and again at checkout time. If the item sold out between those two moments, the customer got a clear error instead of a silent failure. It was a trade-off: we occasionally lost a sale, but we never oversold. For a small platform with no warehouse buffer, overselling would have been fatal to vendor trust.

Scaling to Eighty-Plus Vendors

The first five vendors were friends and family. The next twenty came from cold outreach — my co-founder literally walked into shops with a tablet showing the demo. By vendor thirty, word of mouth started doing the work for us.

Each new vendor exposed a new edge case. One vendor sold items by weight, not quantity. Another needed variant pricing — same shirt, different price for different sizes. A third wanted bundle deals that no one had asked for before. Every feature request was a negotiation between "this helps one vendor" and "this complicates the system for everyone."

I learned to say no to most requests and yes to the ones that solved a class of problems. Variant pricing? Yes — that's a general need. Custom loyalty points per vendor? No — that's a bespoke feature for one shop that adds permanent maintenance cost.

Around vendor forty, the monolith started showing cracks. Page loads crept past three seconds. The order pipeline and the catalog search competed for the same database connection pool. I did the first real refactor: pulled the inventory sync into its own service with its own database, communicating with the main application through a message queue. It wasn't a full microservices migration — it was one extraction that relieved the biggest bottleneck. The pragmatic move, not the architectural ideal.

By the time we passed eighty vendors, the system handled a few hundred concurrent users during peak evening hours. Not AirAsia-scale traffic by any measure, but enough that I had to care about connection pooling, query optimization, and cache invalidation for the first time in a production context. Those lessons stuck. When I later joined Oracle Financial Services and then moved to larger-scale systems, the instincts I'd built debugging slow queries at 11 PM on a twelve-dollar VPS translated directly.

Balancing an M.Tech and a Live Product

I won't romanticize this part. It was brutal.

A typical day during the worst of it: attend lectures from 9 AM to 1 PM, work on the platform from 2 PM to midnight, squeeze in thesis research in whatever gaps remained. Sleep happened in five-hour blocks. Meals were an afterthought. My thesis advisor knew about the startup and was cautiously supportive, but "cautiously supportive" doesn't extend deadlines.

The saving grace was that building the platform was my education. Every distributed systems concept from the M.Tech curriculum — consistency models, fault tolerance, CAP theorem trade-offs — I was seeing in production the same week I read about them in papers. The gap between theory and practice wasn't a gap for me; it was the same Tuesday.

I submitted my thesis on time. The platform didn't go down during exam weeks. Both outcomes felt like minor miracles. The cost was that I had essentially no social life for two and a half years, and I burned out in a way that took months to recover from after the acquisition.

If you're considering building something while in school, the honest advice is: it's possible, it teaches you enormously, and it will cost you more than you think. Have that conversation with yourself before you start, not after.

The Acquisition

By early 2017 the platform was generating consistent revenue, but growth had plateaued. We didn't have the capital to invest in marketing or logistics infrastructure, and we didn't want to take on debt or dilutive funding for a business that was profitable but not explosive.

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 time. We hadn't been looking for a buyer, but the offer made sense.

The negotiation took about two months. The hardest part wasn't the financial terms — it was the emotional terms. This thing I'd built from nothing, that I'd lost sleep over, that I'd debugged at 3 AM more times than I could count — I was handing it to strangers. My co-founder handled most of the negotiation, which was the right call. I was too attached to be objective about valuation.

We closed the deal in May 2017. The terms were fair. Not life-changing money, but enough to validate that the three years weren't just an expensive hobby. More importantly, the vendors kept their storefronts, the customers kept their accounts, and the acquiring company kept the team (such as it was — two contractors and us) for the transition period.

I walked out of that experience with no regrets and a very clear understanding of what I wanted next: to build at larger scale, with more resources, at companies where the engineering challenges were bigger than what a two-person team could tackle. That led me to Oracle Financial Services, then Bottomline Technologies, then Kotak Securities, and eventually to AirAsia where I work on systems processing 130 million daily transactions.

Lessons for Technical Founders

Three years of building, shipping, and selling distilled into the things I'd actually tell someone starting today.

Ship the ugly version first. Our MVP was architecturally embarrassing. It was also live, collecting payments, and teaching us what users actually needed — things no amount of whiteboarding would have revealed. The beautiful rewrite can happen after you've proven the business. Paul Graham's essay on doing things that don't scale captures this perfectly.

Pick boring technology. Java and Spring in 2014 wasn't going to win any hackathons. But it had mature tooling, a massive ecosystem of libraries, and documentation written for humans. When our payment integration broke at midnight, I could find a Stack Overflow answer in under a minute. Boring technology compounds reliability over time. Dan McKinley's Choose Boring Technology is the best articulation of this I've read.

Solve the class, not the instance. When vendor number thirty-seven asks for a feature, don't build it for vendor thirty-seven. Ask what general problem it represents, and build the general solution — or don't build it at all. Every special case is a maintenance liability that outlives the vendor who requested it.

The adapter pattern is your best friend. External integrations — payment gateways, shipping APIs, SMS providers — will change their interfaces, go down, or get replaced. Wrap every external dependency in an adapter that exposes a stable internal contract. The rest of your codebase should never know or care which specific vendor is behind the adapter. This single pattern saved us more debugging hours than any other architectural decision.

Cofounder alignment matters more than 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.

Know your exit conditions before you need them. We didn't have a formal "we'll sell if X happens" trigger, and that made the acquisition decision more emotional than it needed to be. If I did it again, I'd write down the conditions under which we'd sell, shut down, or raise money — before we launched. Having those criteria on paper makes the eventual decision clearer and faster.

Burnout is not a badge of honor. I pushed through it because I was young and stubborn. In retrospect, taking one full day off per week would not have killed the company and would have made me a better engineer on the other six days. The myth of the founder who never sleeps is exactly that — a myth that damages real people.

Where It Led

That startup taught me to build systems that handle real money, real users, and real consequences. It gave me scars and skills in roughly equal proportion. Every role I've held since — building OpenBanking APIs at Oracle, scaling microservices at AirAsia, architecting an algorithmic trading system — connects back to those nights on a twelve-dollar VPS, making a marketplace work for eighty vendors who were counting on us.

If you're building something right now — whether it's a side project, a startup, or an internal tool at a company that doesn't appreciate it yet — the work compounds. The lessons stick. And the code you're embarrassed by today is the code that teaches you to write something better tomorrow.

I write about systems engineering, career decisions, and the messy reality of building production software. If you're working on something similar or want to talk shop, reach out.

Related Articles