Booking App MVP: 6 Cuts That Keep the Price Fixed

What a booking v1 can never cut

Before you cut anything, protect the core flow. If one of these is missing, nobody can use the app. Everything else can wait for v2. The test is simple. Does the feature stop a customer from finding a provider, booking a slot and showing up? If not, it goes on the cut list.

• 1. Two roles: customers who book, providers who sell their time.
• 2. Provider profiles with services, durations and prices.
• 3. Weekly availability set by each provider.
• 4. A booking that blocks the slot, so two people can't book it twice.
• 5. A confirmation and a reminder.
• 6. An admin view where you can see bookings and fix problems by hand.

Step 1: check Apple's payment rule first

Apple's rules decide how your app can take money, so settle them before you scope anything else. If your app mixes these, for example one-to-one coaching plus group classes, you will likely need two payment paths. That's a strong reason to launch with only one session type.

• Service happens outside the app (a haircut, a cleaning, a home repair): under guideline 3.1.3(e), you must use a payment method other than in-app purchase, such as Apple Pay or card entry.
• Live one-to-one session in the app (tutoring, a medical consultation, fitness training): under guideline 3.1.3(d), you may use payment methods other than in-app purchase.
• Live one-to-few or one-to-many session (a group class): Apple requires in-app purchase.

Step 2: pick your cuts by revenue model

Your revenue model tells you which payment work v1 really needs. Find your model, keep what is listed under "Keep in v1" and cut what is listed under "Cut first".

• Commission on each booking. Keep in v1: card payment at booking, with provider payouts through Stripe Connect or equivalent. Cut first: deposits, tips, packages, no-show fees.
• Monthly fee paid by providers. Keep in v1: bookings, with customers paying the provider directly. Cut first: all customer payments in the app.
• Free listings, paid later. Keep in v1: bookings only, no money in the app. Cut first: all payments, provider billing.
• Live online sessions. Keep in v1: one session type, external meeting link. Cut first: built-in video, mixing one-to-one and group.

Commission model

If the money goes through your platform, you need a way to split each payment between you and the provider. That runs on a marketplace payment product like Stripe Connect, or an equivalent, and it belongs in v1. The payment split is scoped and priced in your fixed quote after the call. It is not part of the starting price. If you don't want to build payouts at launch, pick a different revenue model, like a provider subscription where customers pay providers directly.

Provider subscription model

If you sell that subscription inside the iOS app to unlock features, Apple's in-app purchase rules can apply. Billing providers outside the app at first keeps v1 simpler. Not sure which model you're in? Book a call. We'll map your money flow before you commit to a scope.

Step 3: the six cuts

Each cut below follows the same format: what to drop, what to ship instead, and the signal that tells you to bring it back.

Cut 1: in-app payments your model doesn't need

Drop customer payments in the app when your revenue model does not depend on them.

• Instead: if providers pay you a monthly fee or listings are free, customers pay the provider directly and the app handles bookings only. If you take a commission, this cut doesn't apply: payments and payouts stay in v1.
• Bring it back when: you move to a commission model, or providers ask you to collect payment for them.

Cut 2: deposits, tips, packages and no-show fees

Each extra payment type adds rules: who gets refunded, when, and who decides. Those rules have to be written and tested.

• Instead: one payment type: full price at booking, or payment on site.
• Bring it back when: providers tell you no-shows cost them money and ask for deposits.

Cut 3: per-provider cancellation rules

Drop separate cancellation rules for each provider.

• Instead: one cancellation policy for every provider, shown at booking.
• Bring it back when: your providers' businesses really differ, and the single policy is losing you good providers.

Cut 4: two-way calendar sync

Drop the sync between the app and external calendars.

• Instead: providers manage availability in the app, and customers get an "add to calendar" option in their confirmation.
• Bring it back when: providers miss bookings or get double booked because they also manage their time in Google Calendar or Outlook.

Cut 5: SMS and WhatsApp reminders

SMS is billed per message, so add it once you know you need it.

• Instead: push notifications for confirmations and reminders. If you also want email, we cover it in the quote.
• Bring it back when: your booking data shows reminders aren't reaching people.

Cut 6: reviews, waitlists, recurring bookings and built-in video

Our feature cost articles go deeper on several of these features.

• Instead: no reviews at launch, single bookings only, and a link to the meeting tool providers already use.
• Bring it back when: you have enough completed bookings for reviews to mean something, or customers keep rebooking the same slot every week.

A worked example: a home cleaning app

Say you're launching a cleaning app in one city. You take a commission on each booking. What's left after the three steps is a v1 that does one job: a customer finds a cleaner, books a slot and pays, and the cleaner shows up. That's what your first users and your investors need to see working.

• Step 1: cleaning happens outside the app, so card payments are allowed and in-app purchase is not.
• Step 2: commission model. Keep card payment at booking, with Stripe Connect or equivalent for payouts. Cut deposits, tips and packages. The payment split goes into your fixed quote after the call, priced on top of the starting price.
• Step 3: one cancellation policy, in-app availability, push reminders, no reviews yet.

How the fixed price works

Here is how we run a project, in the words of our services page.

• 1. Free call. "30-min strategy call. We scope your product and confirm fit." We go through your cut list.
• 2. Fixed quote. "You get a precise price and timeline. No hidden fees." The quote comes after the call, before work starts.
• 3. Build sprint. "20 days. Daily updates in Slack."
• 4. You ship. "We deploy, submit to stores, and support you for 2 weeks post-launch."

What a mobile build covers

A mobile build covers iOS and Android from one Expo project, sign-up and onboarding, your core flow, push notifications, Stripe when you charge, and TestFlight and Google Play submission support. You own 100% of the source code and get 2 weeks of fixes after launch. If your scope includes something from the cut list, the quote says so before you sign. If you're comparing pricing models, read fixed price vs time and materials for an MVP. To see what we've shipped, browse our projects. Ready to scope your booking app? Book a call and we'll go through your cut list. The fixed quote follows the call.

What should I cut from a booking app MVP?

Cut in-app payments your model doesn't need, extra payment types, per-provider cancellation rules, two-way calendar sync, SMS reminders, and extras like reviews and waitlists. Keep sign-up for both roles, provider profiles, availability, booking without double booking, confirmations, reminders and a basic admin view.

Can a booking app take card payments instead of Apple in-app purchase?

Yes, if the service happens outside the app, like a haircut or a cleaning. Apple requires a method other than in-app purchase in that case. Live one-to-one online sessions may also use card payments. Live group sessions must use in-app purchase.

Do I need automatic payouts to providers at launch?

Only if money goes through your platform. If you take a commission, a marketplace payment product like Stripe Connect, or an equivalent, is part of v1, and the fixed quote prices it. If customers pay providers directly, or providers pay you a monthly fee, you don't need payouts.

How long does a booking app MVP take to build?

At BuildMVPFast, a fixed-price MVP ships in about 20 days after a free call and a fixed quote. A tight cut list keeps a booking app within that timeline.