Photo: Google Gemini · AI-generated
The startup advice is familiar. Launch small. Learn fast. Rebuild properly once you have traction.
For most apps that advice is right. For a two-sided marketplace it is dangerous, because the parts that are hardest to add later are exactly the parts your first users judge you on. A marketplace MVP can be small in scope. It cannot be weak in structure.
Here are the three places where “we will fix it after launch” does not work, and what can genuinely wait.
Trust cannot be a version-two feature
A marketplace asks strangers to send money to each other. Every other feature sits on top of that one act of trust.
When we built Atlikarinca, a consumer marketplace for buying and selling new and used products, ratings for both buyers and sellers were in the first release. Not because ratings are complicated. Because a rating system added in month six has no history in month six, which is exactly when you need it. Trust is a stock that accumulates. You cannot buy it later.
The same applies to identity. Social login looks like a convenience feature. It is really the identity layer of the whole platform. Bolting a proper identity model onto a user base that already exists is one of the least pleasant jobs in software. Do it once, at the start.
An offer is a state, not a message
Most marketplace MVPs model negotiation as chat. Buyer writes “would you take 40?”, seller writes “45”, done. It ships in a day.
It also cannot be built on. An offer has states: made, countered, accepted, expired, withdrawn. It has a price at each step. It triggers notifications and, later, disputes and analytics. If that lives inside free text, none of it is available to the product. Atlikarinca modelled offers as their own thing from the start, with a small state machine behind “submit and negotiate”. That is a week of work in the MVP. It is a quarter of work once ten thousand conversations contain prices you cannot parse.
Two sides, two screens
A buyer and a seller want different things from the same listing. The buyer wants to decide. The seller wants to respond. An MVP that shows everyone everything confuses both.
Atlikarinca had separate buyer and seller views from the first release, each showing only that side’s next step. This is cheap at the beginning, when there are two flows. It is expensive later, when six months of features have been added to a screen that was never designed to know which side it is serving.
The backend has to hold the first spike
Marketplace traffic is not a gentle curve. One shared listing lands in the right group and you get a week of demand in an afternoon. If the backend folds, the users who came for that listing do not come back.
This does not mean building for millions on day one. It means not choosing a structure that has to be thrown away. Atlikarinca’s backend was built for marketplace-scale listings and transactions behind a native Android app, so growth was a matter of capacity, not redesign. Dinifi, a startup POS and ordering platform for restaurants, made the same choice from a different direction: cloud infrastructure sized for merchant-scale transaction volume, and an integration layer to the systems merchants already ran. The apps were the visible part. The foundation was the reason they could keep adding to them.
What can wait
Being firm about the spine makes it easier to be relaxed about everything else. Recommendations can wait. Advanced search can wait. The admin dashboard can be a database query for a while. The second platform can wait: Atlikarinca launched on Android alone, because that is where its market was. Payments can start simple, as long as the offer state that a payment attaches to is real.
The point is not to build more. It is to be small in the right dimension. Scope can be tiny. Structure has to be sound in the three places where users, money and traffic meet.
If you are about to build a marketplace, we are happy to look at your plan and say which parts belong in the first release. See how we work with startups, or talk to us directly.