"Something like Airbnb, but for X" is a useful way to explain an idea and a useless way to scope one. The visible app is the small part. What takes the time is everything that has to be true before that app can be trusted with someone else's money.

Here is where the months actually go.

A marketplace is three products

You are not building one app. You are building at least three things, and each has its own users and its own release cycle.

  • The demand side. People looking for something. Usually the simplest of the three, and the one everybody designs first.
  • The supply side. People offering something. Onboarding, listings, availability, pricing, payouts, reputation. Almost always underestimated, because founders imagine themselves as the buyer.
  • The operations back office. Approving suppliers, resolving disputes, issuing refunds, removing content, seeing what is happening. Without it, your team runs the marketplace out of a database client, and that stops being funny in week two.

If a quote covers only the first one, it is not an estimate for a marketplace.

What genuinely drives the timeline

Four things, in roughly this order.

Money movement. Taking a payment is easy. Holding it, splitting it, releasing it on a condition, refunding part of it, and paying out to hundreds of individuals across different tax situations is not. Payouts are usually the single largest source of unexpected work, and much of it is paperwork rather than code.

Trust and identity. Who is allowed to sell? What happens when a listing is fake? Verification, ratings and dispute handling are not features you add later — they shape the data model, and retrofitting them means rewriting it.

Moderation. The moment users create content, someone has to be able to remove it quickly. That means tooling, and a decision about what happens automatically versus what a human reviews.

Store review. Apple and Google will look at your app, and marketplaces attract more scrutiny than most categories. Build in time for at least one rejection. It is normal, not a failure.

What can wait, and should

Most first versions are late because of things no early user needed.

In-app chat can start as a notification and an email. Recommendation algorithms are meaningless with two hundred listings; sorting by distance and recency works better. Loyalty schemes, referral trees and multi-currency support are all things you can add once you know the marketplace works.

The one thing we do not recommend deferring is the operations back office. It feels internal, so it gets cut first, and then your team spends its days doing manually what the software should have done — which is the most expensive way to save money.

A shape that tends to work

Rather than one long build, we usually split it in three.

First, a supply-side release with a manual back office: real listings, real suppliers, payments handled with a human in the loop. This is unglamorous and it teaches you more than any amount of design.

Second, the buyer app, once there is something worth browsing.

Third, automation of whatever your operations team is doing most often. By this point you know what that is, which is why it is third and not first.

The hard part is not the app

Marketplaces fail for a reason that has nothing to do with engineering: nobody wants to be the first person in an empty room. Buyers do not come without supply, and supply does not stay without buyers.

Every successful marketplace solved this with something other than software — a narrow geography, a single category, a manually recruited first hundred suppliers, or subsidising one side until the other arrived. If your plan for the cold start is "launch and market it", the app will work and the business will not.

A studio that does not ask you about this is not paying attention.

Shortening it honestly

You can compress the timeline in three legitimate ways: narrow the category, narrow the geography, or keep a human in the loop where automation would be expensive. All three reduce scope without reducing the quality of what you learn.

What does not work is compressing quality assurance, skipping the back office, or building both sides at once with a team too small to do either well.

If you have an idea at this stage and want a realistic breakdown before committing a budget, send us the outline. We will tell you which parts we would cut, including the parts we would rather be paid to build.