A field report from a recent DevLK project — how we took a photography studio from email-and-spreadsheet chaos to a booking platform their admin team actually likes. Stack choices, mistakes, and results.

When a photography studio in Colombo first reached out to us, their entire booking operation ran through a shared Gmail inbox and a Google Sheet. Three staff members were answering the same messages. Double bookings happened roughly twice a month. Pricing mistakes were worse than that.

This article is a practical field report on the rebuild. No marketing fluff: what we changed, what broke, what we would do differently, and the numbers we can actually measure.

The real problem was not software

Before we wrote a line of code, we spent two afternoons sitting next to their front-desk staff. That is where we found the real problem: the studio owner had a different price sheet in his head than the one his team was quoting from. The "system" everyone blamed was just a symptom.

So the first thing we shipped was not software — it was a single canonical price list as a shared document, with version history. That alone reduced refund disputes before we touched code.

The lesson we keep re-learning: if the existing process is broken, automating it just breaks it faster. Fix the process first, then build the tool to enforce it.

The stack we picked, and why

We use Laravel + PostgreSQL as our default for this kind of internal business app, and that is what we picked here. The reasons, honestly:

• The team already knows Laravel well. We can predict how long a feature will take in it.
• PostgreSQL gives us real transactions, real JSON columns, and real constraints. Double bookings should be a database-level impossibility, not an application-level check.
• Hosting is boring and cheap in Colombo and on regional clouds — a $20/month VPS is enough for a studio doing a few hundred bookings a month.

We did briefly consider a no-code tool. It would have been faster to demo, but we could not enforce the business rules the owner cared about (blackout dates, package-specific deposits, photographer-level availability). When a tool cannot express your rules, you end up writing them in people's heads — which is exactly where they started.

The one database constraint that mattered

The single most valuable line of code in this project was a database exclusion constraint on the bookings table. In plain English: the database itself refuses to save two overlapping bookings for the same photographer on the same day.

Before this constraint, we wrote application-level "is this slot free" checks. Those checks have a race condition — two tabs open, two confirmations clicked, one succeeds, one fails, and you only know at 6pm when both customers arrive. After the constraint, the same race ends with a graceful error shown to the second clicker. The user is annoyed for four seconds; the studio is not scrambling at 6pm.

If you remember one thing from this write-up: enforce your hard rules in the database, not in the framework.

What we got wrong the first time

We shipped an initial version where customers could self-serve-cancel up to 24 hours before a shoot. We thought this would reduce admin work. It reduced admin work by roughly zero and created a new problem: cancellations spiked on Friday evenings when deposits had already been paid out to second shooters.

We pulled the feature back and replaced it with a "request to cancel" flow that reaches staff first. This is not the more elegant solution. It is the one that matches how the business actually operates.

Lesson: self-service features are only wins if the operational cost they remove is real. Sometimes the existing friction is doing unglamorous work you do not see.

What the numbers look like

Three months after go-live, on the same volume of inbound inquiries:

• Double bookings: zero, down from ~2/month.
• Average time to confirm a booking: about 40 minutes, down from roughly half a day.
• Admin hours spent on booking-related email: down from ~8 hours/week to ~3.
• Refund disputes: one, handled in a day, down from several per month that dragged on for a week.

We deliberately did not measure revenue lift because the studio was already busy. The win was operational clarity and a team that no longer dreaded Monday mornings.

If you are thinking about doing this for your business

A few things we tell SMEs when they ask about this kind of project:

• Ship the boring parts first. The calendar view and the invoice PDF are not impressive, but they are what the team uses every day.
• Be wary of feature checklists from competitors. Most of those features were built because one vocal customer asked. They are not free — somebody maintains them.
• Plan for your team to hate the first version for two weeks. That is not a failure. That is the cost of changing a habit.

If you have a similar set-up — manual ops held together by spreadsheets, a willing owner, and a team who would benefit from clarity — we usually scope this kind of build in two-week increments. Happy to talk it through if useful.

Original Source: https://devlk.com/blog-details.php?slug=rebuilding-a-studio-booking-platform-lessons-from-the-field