Most marketplace apps fail before they launch. Not because the idea was wrong but because the foundation wasn’t right. After building over 180 apps on Adalo, the pattern is always the same: the projects that scale come down to the decisions made in the first week before a single screen is designed.
This is the story of one of those projects.
The Brief
A founder came to me with a marketplace concept; venues, bookings, payments, reviews. It’s the kind of app that sounds straightforward until you start mapping out how everything connects. The brief was simple: build something that could handle real transaction volume, go live in under 30 days, and not require a rebuild six months in when users started growing.
The total build came out at $65,000. Here’s what went into it and why the early decisions determined everything that followed.
One User Collection, Not Two
The first question on every marketplace is always the same. Do you create separate collections for buyers and sellers, or do you keep everyone in one Users collection with a Role property (Field)?
I always go with one collection. In practice, a user who starts as a customer and later wants to list their own venue should not need a new account. Their booking history, their reviews, their profile all stay intact. If you split them into two separate collections from the start, you either force users to manage two accounts or you build a migration path you never planned for.
On this project, users could switch between Customer and Venue Owner directly from their profile settings. One toggle, one action, one collection. The alternative would have doubled the complexity of every filter, every list, and every relationship in the app.
Storing Redundant Relationships on Orders
When a booking is created, the Order record stores three things directly: the Buyer, the Venue Owner, and the Venue. Most builders only store the Venue and assume they can always get to the owner through it. The problem is that pulling the owner through the venue adds an extra step every time the screen loads a list. On a screen showing hundreds of bookings, that extra step adds up and makes the screen noticeably slower. Storing the Venue Owner directly on the Order removes that extra step entirely. One lookup instead of two. The screen loads faster and the app feels more responsive.
Time Slots as Their Own Collection
One of the most common mistakes on booking apps is saving availability as a text property in the database or date directly on the Venue record. It would break immediately when two users try to book the same slot at the same time.
We built a (Time Slots) collection in the database where each slot belongs to one Venue and has a Status field (Available, Booked, or Blocked). When a booking is confirmed, an action updates the linked Time Slot to Booked in the same action sequence as the booking creation. No slot can be double booked because the status changes the moment the first booking is created.
This also gave us a clean real-time availability view. Filter Time Slots by Venue and Date, show only Available. No complex logic. No edge cases. Zero double-booking incidents across twelve months of live transactions.
Building the Admin Layer First
Most builders design the user-facing screens first and treat the admin panel as something to add at the end. We built it first. Every collection and every relationship was designed from day one with the admin view in mind.
This caught three structural problems before a single user-facing screen was built. Problems that would have required a partial rebuild if we had found them after forty screens already existed.
The admin layer is invisible to users and unglamorous to build. It is also the most important thing you can do first on any serious app.
The Result
The app launched in 26 days. It processed its first $65,000 in venue bookings within 90 days of going live. The database structure has not been changed since launch. No migrations, no emergency fixes, no performance patches. It scaled because the foundation was correct from the start.
If you are planning a marketplace, booking app, or any multi-role platform and want to make sure you are starting with the right structure, book a free 20-minute session before you write a single collection name: consultation.webnux.org
Ali Bazzi | Adalo Expert and Community Leader | webnux.org
Work with me: adalo.com/experts/ali-bazzi | Free consultation: consultation.webnux.org
Keep them coming! 
