Marketplace · France
AWS CDK backend for clients and beauty professionals: an 8-state appointment lifecycle, deposits and auto-confirm flows, hourly Stripe Connect payouts in Paris time, reminders over push, SMS and WhatsApp, and a data model built so an AI assistant can drive it safely.
A marketplace that connects beauty clients in France with hairdressers, barbers, nail technicians and lash artists, on iOS and on the web. Clients discover professionals nearby or through a feed of the ones they follow, book a slot or request a quote, pay by card, Apple Pay, Google Pay or on site, get reminders and leave reviews. Professionals activate a profile with hours, addresses, payment methods and Stripe Express, publish services with variants and extras, run a calendar, approve requests, message clients and get paid automatically. Threaded through both sides is an AI agent: a shop admin can say "book this client tomorrow at 14:00 and send a deposit link" and the agent does it, within what that role is allowed to do.
The founder is non-technical, the mobile app is built by a separate team, and an earlier agency system still holds live data. We own the AWS backend and the AI agent, built milestone by milestone against a 66-story product roadmap. V1 is the booking foundation: accounts, shop profiles and catalogues, calendars, search, messaging and quotations, promo codes, booking, payments and cancellations. V2 is the assisted shop: a super-admin back office with an agent operations console, role-based spaces under one account, multi-service checkout, payment links and Tap to Pay, reviews with tips, media consent, gift cards, a seven-part rental system with card-authorisation deposits and AI damage assessment, and the assistant on Instagram, Facebook and WhatsApp. V3 adds virtual try-on, product sales, affiliates and a creator studio; V4 adds recruitment, a B2B store, training and shipping. Every story is written as a workflow (read, propose, approve, track) with agent behaviour per role, so the API and the agent are designed together.
How the system is layered, from the people using it down to the data and the services it depends on.
The choices that made the difference, and why we made them.
Appointments move through pending payment, pending confirmation, confirmed, completed, cancelled, no-show, disputed and refunded. Which path a booking takes is decided by the service: auto-confirm services go straight to confirmed when the Stripe webhook lands; deposit services wait in pending confirmation until the professional accepts. Quote requests, payment expiry, cancellation policies per store and per service, and completion tracking are all fields on the appointment, not conventions in the app.
The hourly payout job computes cutoffs with IANA zoneinfo for Europe/Paris, never a fixed offset, so daylight-saving changes don't pay people an hour early. Each payout is recorded as pending before Stripe is called, the transfer carries an idempotency key derived from the appointment, and a retry job resumes failures with the same key. Commission is copied onto the appointment at booking time, so later changes to plan or payment mode can't alter what a professional is owed.
Every state transition, permission check and price calculation lives in the API, never in the app, which is what makes the marketplace's in-app AI assistant possible: the assistant calls the same endpoints under the same session, so it cannot do anything the app could not. That assistant is its own case study.
EventBridge schedules drive 24-hour and same-day reminders, nudges to professionals with bookings awaiting validation, a daily recap, a completion check an hour after the slot, and rebooking suggestions three weeks after a completed visit. Delivery goes over Firebase push, Twilio SMS and WhatsApp, with inbound Twilio webhooks captured so replies aren't lost. Reminder state lives on the appointment, so a message is never sent twice.
Gift cards are modelled as issued, reserved and spent credit with commission and refund history, so the same value can never be refunded twice. Rentals separate a unit's physical condition from its reservation and its financial status, with preparation buffers so an item is never promised twice; the security deposit is a card authorisation placed at collection, never an upfront debit, and AI compares before-and-after photos against the shop's accepted damage schedule while a human keeps the financial decision. Payment links and Tap to Pay collect deposits, balances or full amounts from a phone. Each of these lands on the same appointment and payout primitives already in production.
The new backend shares a database with an earlier agency-built system. We modelled only the tables we own, versioned every schema change as a numbered migration, and kept Firebase identity as the bridge for users created on either side, so the app could cut over feature by feature instead of in one risky switch.
Tell us what you're building. You'll get a straight answer on scope, timeline and cost, usually within one business day.