Build Log: A Booking App in Six Weeks

A small yoga studio needed online booking. We shipped it in six weeks (fictional client, real process). Call them Stillpoint Yoga: one location in Boulder, Colorado, three instructors, about twenty classes a week and a front desk that was drowning in text messages, sticky notes and a shared spreadsheet that nobody fully trusted. The owner, Maria Chen, wanted members to book and cancel classes from their phones, see how many spots were left and stop texting her at 6 a.m. to ask if the sunrise flow was full.

Here is the log, week by week: what we built, what we argued about and the one feature we cut. If you are planning a small web app with a fixed budget, I hope the shape of it is useful.

Scope before code

Before writing a line of code, I spent two afternoons at the studio watching how bookings actually worked. That turned out to be the most valuable time of the whole project. The spreadsheet had grown columns that only one person understood. Some classes were capped at twelve because of floor space, others at twenty. Members bought ten-class packs that expired after three months, and nobody was sure how many classes were left on anyone’s pack.

We agreed on a short list of must-haves for launch:

• A weekly class schedule members can browse without logging in.
• Booking and cancellation with a clear cutoff of two hours before class.
• Live spot counts and a simple waitlist.
• Class packs and monthly memberships, with remaining credits shown clearly.
• An admin view for the front desk to check people in and manage the schedule.
• Email confirmations and reminders.

Everything else went into a “later” document. Writing that document was easy. Keeping things in it for six weeks was the hard part.

Week 1–2

Data model, auth and the calendar. Boring decisions, made early. I spent most of the first week on the database design, because getting it wrong later would be expensive. Classes, class sessions, members, bookings, packs and payments each got their own table, with clear relationships and very few clever tricks.

A few decisions from those first two weeks that paid off:

1. Store times in UTC, display them in the studio’s local time. Daylight saving bugs are the worst kind of bug.
2. Separate a class from its sessions. “Sunrise Flow” is a class. “Sunrise Flow on Tuesday, March 3” is a session. Recurring schedules become much simpler.
3. Use passwordless email login for members. Yoga students should not need to remember another password.
4. Use a well-known payment provider for card handling, so we never store card details ourselves.
5. Write the booking rules as small, tested functions, not scattered conditions in the interface.

By the end of week two, an admin could create classes, members could log in and a plain, unstyled calendar showed the week’s sessions. It looked terrible and worked perfectly, which is exactly where I want any project to be at that point.

Shipping is a feature.

Leo

Weeks 3–4: the booking engine

The heart of the app was the booking flow, and it was where most of the tricky edge cases lived. What happens if two people tap the last spot at the same moment? What if someone cancels inside the cutoff? What if a class pack expires the day before a booked class?

We handled the race condition with a database transaction that checks capacity and creates the booking in one step, so the last spot can only ever go to one person. Waitlists got a simple rule: when a spot opens more than two hours before class, the first person on the list is booked automatically and emailed. Inside two hours, the spot just opens for anyone.

Week four was the front desk view. Maria’s team needed to see today’s classes, check people in with one tap and add walk-ins quickly. I sat at the desk with them during a busy Saturday morning to test it, and we changed the layout three times before lunch. That afternoon was worth more than any amount of mockups.

The cut

We dropped gift cards for launch. Nobody missed them. Gift cards were on the original wish list, and they sounded simple: sell a card, let someone redeem it. But once I sketched it out, the edge cases piled up. Partial balances, expiration rules, refunds, codes that could be guessed and gift cards bought with other gift cards. It was easily a week of work, and it touched the payment flow, the riskiest part of the app.

Maria and I looked at the numbers together. In the previous year, the studio had sold a small handful of paper gift certificates, mostly around the holidays. The front desk could keep handling those by hand for a few more months. So we cut it, moved it to the “later” document and put that week toward polish and testing instead.

Three months after launch, nobody had asked about gift cards online. When the holidays came around, we added a simple version in about four days, with real usage data to guide it.

Key takeaway: cutting a feature is not failure. It is a decision to ship something reliable now and build the next thing with better information.

Weeks 5–6: polish and launch

The last two weeks were about everything that makes software feel finished: loading states, empty states, error messages written in plain English, accessibility checks, mobile layouts and performance on slower phones. We also wrote a one-page guide for the front desk and recorded a short video for members.

We launched on a Monday, deliberately. Mondays at the studio are quiet, which gave us room to fix anything that broke. A few small issues came up, including a confusing button label and a reminder email that went out an hour early because of a timezone setting, and we fixed both the same day.

What I would do differently

Not everything went smoothly, and a build log that only lists wins is not very useful. I underestimated email. Getting confirmations and reminders to land reliably in inboxes, rather than spam folders, took most of a day of configuration and testing that I had not planned for. Next time I will set up email delivery in week one.

I also waited too long to bring in real members for testing. Maria’s staff tested the front desk view early, but members did not try the booking flow until week five. They found two confusing screens in about ten minutes. Both were easy fixes, but they would have been even easier in week three. Real users always find the things you have stopped seeing, so the sooner they get their hands on it, the better.

Six weeks later

The spreadsheet is retired. Members book from their phones, waitlists fill themselves and the front desk spends more time greeting people than answering texts. Maria told me the best part was getting her mornings back.

The project worked because the scope was small, the decisions were made early and we were willing to cut what did not need to exist yet. None of that is glamorous. All of it is how good small software actually gets built.