Three Ways to Structure the Transaction 

Not every marketplace handles the actual transaction the same way, and the three real structures carry very different build complexity. 

Yaya works as a directory with direct contact, letting families search and filter caregivers, then message and hire them directly. The actual working relationship continues outside the app afterward, closer to how a trusted personal referral would work. Hey Gorgeous runs a full transactional booking flow instead, handling search, booking, deposits, and payment inside the app from the first visit to the checkout. Treffpunkt's Transfer Market is a third pattern, an embedded offer layer inside a broader social app that connects football players and club managers without any payment processing at all. 

Choosing the transaction model shapes everything else in the build: 

• Choose a directory with direct contact when the relationship matters more than the transaction, since trust and ongoing fit, the way Yaya handles caregiver hiring, outweigh instant booking 

• Choose full transactional booking when the service is standardized enough to price and schedule in advance, the way Hey Gorgeous handles beauty appointments 

• Choose an embedded offer layer when the goal is adding lightweight matching to a product that already has an audience, rather than building a standalone marketplace 

These are not fixed choices forever. A directory can add booking later, once trust and volume justify the build. An embedded offer layer can grow into a fuller marketplace too, if the demand for it turns out to be real. Starting at the lightest model the category can honestly support is usually the safer bet. 

How to Scope the First Version 

Most marketplace apps fail on sequencing, not on the feature set. A first version that seeds one side deliberately beats one that opens to both sides at once and hopes they meet in the middle. 

• Pick the transaction model first, since a directory and a full booking flow are genuinely different builds, not variations of the same screens 

• Decide which side to seed before launch, since supply almost always needs to come first, and a handful of real providers matters more than a marketing push aimed at customers with nothing yet to book 

• Design the trust signal, ratings, verification, or both, before opening broadly, since two strangers transacting need more reassurance than either side of a typical social app 

Teams that open to both sides simultaneously usually end up manually recruiting supply after launch anyway. That happens once an empty provider list makes the app feel broken to the first customers who show up. 

What a Realistic Build Timeline Looks Like 

Shipped examples in this category took four to six months, and four stages make up that window. 

• Discovery and scope, where the team locks the transaction model, the trust signals, and the seeding plan before any screen gets designed 

• Core build, the largest block on the calendar, where profiles, search or filtering, and either messaging or booking come together against that locked scope 

• Two sided testing, run with real providers and real customers rather than one team member playing both roles, since trust dynamics only show up between actual strangers 

• Launch and monitor, the first few weeks live, when the seeding plan gets tested against whether real supply and real demand actually meet 

Skipping real two sided testing is the most common reason a marketplace that looked balanced in an internal walkthrough feels lopsided the moment real users on both sides show up.