Instead of giving you the typical “how to build an MVP in 4 weeks” guide, I’m going to tell you what really happened when I built an MVP for a real client 3 months ago. With timestamps, with problems that arose, with decisions I made on the fly, and with what the client changed mid-project (because something always happens).
It’s a log. I write it in the past tense so you know what happened, not what you should do. If it helps you as a guide, great. If not, at least you’ll have had a laugh at my mistakes.
The project: an app for a fitness coach to manage sessions with his clients, with chat, calendar, and integrated payment. The client is called James, has been doing 1-on-1 sessions in London for 4 years, and wants to launch the app to open up to online clients across Europe. The MVP has to validate whether people are willing to pay for online sessions (not just in-person).
Stack agreed: React Native + Expo + Supabase + Stripe. Why this: I explain it in the stack comparison post, but summarised, because James has no technical experience and needs something I can deliver fast and maintain without him having to learn anything weird.
Budget: €2,200, in 2 sprints of 2 weeks. No permanence, payment at the end of each sprint.
Week 1: setup, auth, first screen (10-14 March 2026)
Monday 10 March, 09:30. I start the project. I check the email with James: he’s sent me 3 PDFs with the workflows he wants in the app, 4 photos of his sessions to use as mockup, and a link to a competitor’s app he likes. Good client: clear documentation from day 1.
Monday 10 March, 10:00-13:00. Project setup. Expo CLI, TypeScript, ESLint, Prettier, Supabase as backend. I configure the repository on GitHub with James’s account as owner. I make the first commit: “Initial commit”. 3 hours.
Monday 10 March, 16:00-18:00. Kickoff call with James (via Google Meet, 1 hour, half in English, half in Spanish because James lived 3 years in Madrid). I show him the base project, I explain the architecture, I tell him what I expect from him this week. He confirms that the payment schedule is OK, and that he prefers Stripe Checkout (instead of Stripe’s native API) because it’s simpler.
Tuesday 11 March, 09:00-12:00. Login screen with Supabase Auth. Email + password + magic link. Works the first time (rare, usually you have to fight with Expo’s deep link config). 3 hours.
Tuesday 11 March, 15:00-17:00. Figma mockups of the 6 main screens: login, dashboard, sessions calendar, session detail, chat, profile. James had asked for only 4, but when explaining the flow I realised he needed 2 more (past vs future sessions, and profile settings). 2 hours.
Wednesday 12 March, 10:00-14:00. Supabase database. 4 tables: users, sessions, messages, payments. I define them with SQL, not with the Supabase UI, because it’s faster and cleaner. 4 hours.
Thursday 13 March, problem. When I try to connect the app to Supabase from James’s mobile (which is Android), it fails with a CORS error. I spend 2 hours until I realise the problem is that the Supabase URL I’m using is Expo’s internal, not the public one. I change it, and it works. 2 lost hours I lick my wounds.
Friday 14 March, 11:00-13:00. Dashboard screen with placeholder. The app starts, looks good, can be navigated. I send James a screenshot via WhatsApp. He tells me: “perfect, when can I try it on my mobile?”. I tell him: “Friday of next week”. End of week 1.
Total time week 1: 18 hours. Deliverable: base app with login, empty dashboard, 6 mockups, database ready.
Week 2: sessions calendar + detail (16-20 March 2026)
Monday 16 March, 09:30. I start week 2. The sprint is more complex: calendar screen, session detail, booking and cancellation logic. James sent me feedback over the weekend: he likes the dashboard but wants the main screen to be the calendar, not the dashboard. It’s a small change, but important: it gives more prominence to sessions.
Monday 16 March, 10:00-13:00. Change dashboard to calendar in navigation. 1 hour. I start with the visual calendar screen with React Native Calendars. 3 hours.
Tuesday 17 March, all day (8 hours). The calendar is giving me problems: past and future sessions mix, days with session don’t stand out well, and performance drops when there are more than 20 sessions. I fight 6 hours with the library before deciding to switch libraries. I try react-native-calendar-events (the native iOS/Android one) + my own UI. Better performance and more control. 8 hours.
Wednesday 18 March, 09:00-13:00. Session detail screen: shows date, time, session type (online/in-person), client, coach notes, cancel button. 4 hours.
Wednesday 18 March, 16:00-17:00. Call with James (1 hour). I show him the calendar and session detail. He likes it, but asks for a change: instead of “cancel session”, he wants “reschedule session” (so the client can choose another date/time without cancelling the current one). It’s a good idea, I tell him I’ll add it on Friday. 1 hour.
Thursday 19 March, 09:00-14:00. Reschedule session screen. Modal with new date/time selection, validation that it doesn’t clash with another session, confirmation. 5 hours.
Friday 20 March, 10:00-13:00. Integration of the reschedule screen with the calendar. Manual testing of the 4 flows: view session, cancel session, reschedule session, view past sessions. 3 hours.
Friday 20 March, 16:00. End of sprint 1. I send James the app to test on TestFlight (iOS) and on Expo Go (Android). I give him feedback on the sprint and the changes he asked for.
Total time week 2: 22 hours. Deliverable: app with calendar, session detail, cancellation, rescheduling, connected database.
Week 3: chat + Stripe Checkout (23-27 March 2026)
Monday 23 March. I start sprint 2. Most critical: coach-client chat, and payment with Stripe Checkout. If something fails here, the MVP doesn’t validate anything.
Monday 23 March, 09:00-14:00. Chat screen with Supabase Realtime. List of conversations on the left, messages on the right, input below. Realtime works the first time (Supabase makes it very easy). The most expensive part: the UI, because James wants the chat to look like WhatsApp (bubbles, time, “typing…” indicator). 5 hours.
Tuesday 24 March, all day (7 hours). The “typing…” indicator is giving me a war. It turns out Supabase Realtime has a specific channel for “presence” that can be used, but the documentation is confusing. I fight 4 hours until I find a working example on GitHub. I adapt it, and it works. 7 hours.
Wednesday 25 March, 10:00-13:00. Stripe Checkout integration. I follow the recommended flow: the client taps “Pay session” in the app, Stripe Checkout opens in the browser (not in the app, due to Apple/Google policies), pays, returns to the app with the session marked as paid. It’s 1 hour of real implementation + 2 hours of testing with Stripe’s test card. 3 hours.
Wednesday 25 March, 15:00-16:00. James tests the app and gives me feedback. All good, except one detail: on the chat screen, when a new client opens the app for the first time, they don’t see their conversations because there’s a race condition with the initial load. I fix it on Thursday.
Thursday 26 March, 09:00-12:00. Race condition fixed (it was an order of operations in the useEffect). I start doing onboarding: when a new client enters for the first time, they see 3 explanation screens of the app. 3 hours.
Friday 27 March, 10:00-14:00. UX polish: empty states (what happens when there are no sessions, what happens when there are no messages), loading states, error states. 4 hours.
Friday 27 March, 16:00. End of sprint 2. The app is complete: login, calendar, session detail, reschedule, cancel, chat with realtime, payment with Stripe Checkout, onboarding. I send James the app.
Total time week 3: 21 hours. Deliverable: complete app with all requested features.
Week 4: closed beta, bugs, final deploy (30 March - 3 April 2026)
Monday 30 March, all day (7 hours). Closed beta with 12 real users (5 of James’s friends, 4 of his clients, 3 of mine). I send them the app via TestFlight and Expo Go. I ask them to use it for 3 days and tell me what fails. 7 hours (setup + monitoring).
Tuesday 31 March, monitoring. I receive 8 bug reports in 24 hours:
- 3 people couldn’t register (the magic link didn’t arrive at their corporate emails).
- 2 people saw the calendar blank even though they had sessions (bug in the date filter).
- 2 people couldn’t pay with debit cards (credit only, Stripe configuration issue).
- 1 person had a crash when opening the chat (error in the Realtime component).
I start fixing them all. 6 hours.
Wednesday 1 April, all day (8 hours). I continue fixing bugs. Plus:
- I rewrite the onboarding to be clearer.
- I add an FAQ inside the app with the 6 most frequent questions.
- I improve the calendar’s performance when there are more than 30 sessions. 8 hours.
Thursday 2 April, 09:00-12:00. Final testing. I test the app on 4 different devices (iPhone 13, iPhone 15, Pixel 7, Samsung Galaxy S22). Everything works. 3 hours.
Thursday 2 April, 15:00-17:00. Final call with James. I show him everything, I explain how he’ll manage users, sessions, payments from his Supabase panel. I deliver:
- Source code on GitHub (with his account).
- App published on TestFlight and Google Play Internal Testing.
- 2 hours of training with him and his assistant.
- Written documentation (user manual, troubleshooting, FAQ).
- Access to my Trello board with all tasks and their status. 2 hours.
Friday 3 April, 10:00-12:00. Project closure. I invoice €2,200 (the 2 complete sprints). James tells me he’s happy and that when he has 50 active users he’ll call me for sprint 3 (advanced analytics, integration with Zoom for online sessions, etc.).
Total time week 4: 26 hours. Deliverable: app in production with 12 beta users, 0 critical bugs, complete training.
The breakdown of the 4 weeks
| Week | Hours | Delivered | Problems |
|---|---|---|---|
| 1 | 18 h | Base app, login, dashboard, mockups, DB | Change from dashboard to calendar |
| 2 | 22 h | Calendar, detail, reschedule | Change of calendar library (6h) |
| 3 | 21 h | Realtime chat, Stripe Checkout, onboarding | “Typing…” (4h) |
| 4 | 26 h | Beta with 12 users, bugs, training | 8 bugs, 14h fixing them |
| Total | 87 h | App in production | 22h of problems (25% of total) |
The project finished 7 hours above the 80h I had initially estimated. I didn’t charge James because it was my fault for switching libraries mid-sprint 2. Next time it happens to me, I’ll charge it. It’s a lesson I learned: debugging hours are in the budget, not “extra free”.
Despite the problems, the MVP was delivered in exactly 4 weeks, as agreed. James validated the hypothesis: 3 of the 12 beta users paid for an online session in the first week. That’s 25% conversion, brutal for an MVP. The app is still in production and James is managing 6 online clients with it as of today.
What I learned from this project (and apply to all)
- Always reserve 20% extra hours for bugs and problems. If you use them, charge them. If you don’t, they’re yours. But have them in the budget from day 1.
- Document every client change that affects scope. I do it by email after each call. This avoids discussions at the end of the project.
- Don’t change libraries mid-sprint if you can avoid it. It cost me 6 hours that shouldn’t have been necessary.
- Sprint 4 is always the most expensive because it’s when the real usage bugs appear. Budget this from day 1.
- Onboarding with real beta testers is what really validates the MVP, not the code itself. 12 beta testers give you more information than 1,000 hours of internal testing.
If you want to apply this same approach to your MVP, write to me at landinowebs@gmail.com or via WhatsApp. I send you a fixed quote sprint by sprint. No permanence, no commitment.
And if you want to see the complete case of the Westside Wellness app (which is a larger and more serious project), you have it here: Westside Wellness — case study (under NDA, contact me for screenshots).