What nine industries taught us about building Solera.
Solera is our platform for small operators — bookings, reservations, customer records, the quiet operational machinery that makes a small business work. We built it for nine industries. Here’s what a restaurant, a clinic, a hair studio, a car rental, an esports arena, and four others taught us.
When we started, the pitch in our heads was clean. Build a good reservation and operations platform. Let small operators configure it for their industry. One product, many verticals. Economies of scale.
The reality was messier. And the mess taught us something important about where software platforms actually add value.
The premise
Look at a villa rental, a konoba, a wedding venue, a hair studio, a dental clinic, a physiotherapy centre, a car rental, a rooftop bar, and an esports arena. They look wildly different on the surface. Different customers, different rhythms, different seasonalities, different regulations.
But they all do the same three things. They all take bookings of some kind. They all keep customer records. They all have some version of a capacity problem — rooms, tables, chairs, slots, cars, VIP sections, gaming stations.
If we could build one platform that solved these three well, and let each operator skin it to their industry, we could serve nine markets with one product. That was the bet.
What's the same everywhere
More than we expected.
Every operator wants a calendar. The calendar is the heart of the product. It needs to be fast, it needs to be touch-friendly, it needs to show availability at a glance, and it needs to be editable quickly on a phone at 8pm on a Tuesday.
Every operator wants customer records that remember things. The last booking, the notes the operator made, the preferences, the family that came last summer, the allergy, the preferred stylist. The difference between a platform customers love and one they merely tolerate is whether it remembers them.
Every operator wants simple, fast entry. A new reservation on the phone in four taps. If the tenth tap is for a compulsory field, the operator will stop using the platform inside a month.
Every operator wants an assistant for repeat work. Reminder messages to customers. Follow-ups. Re-booking prompts. The operational chores of customer communication that every small business theoretically does and almost none actually does consistently.
That's the core. It turned out to be remarkably portable. We built these once, well, and they serve every vertical.
What's different everywhere
Also more than we expected.
A restaurant reservation and a dental appointment are both "a person coming in at a time" — but everything around them differs. The restaurant wants to know the party size, allergies, whether it's a special occasion. The dentist wants insurance info, last visit, medical notes, current treatment plan. The hair studio wants stylist preference, last service, hair history. None of these field sets overlaps meaningfully with another.
Capacity rules differ. A restaurant can combine two tables into one. A clinic cannot combine two appointment slots. A car rental can move a car between locations; a hair studio cannot. A VIP section has bottle minimums that nothing else has.
Timing granularity differs. Wedding venues think in weekends. Restaurants think in 90-minute windows. Clinics think in 15-minute slots. Car rentals think in days with pickup/return times.
The structure is universal. The content isn't. The craft of a platform like this is not forcing the content to be universal when it isn't.
The abstraction that broke us
Early on we tried to be clever. We defined a universal "booking" object with a flexible metadata field — any industry could attach its own extra fields. A restaurant booking would have party size and allergies. A dental booking would have insurance and medical notes. Same object, different data.
This worked beautifully in the schema and was a nightmare in every other layer. Every form in the admin panel needed to know which fields to show for which industry. Every email template needed to know. Every report. Every search filter. Every CSV export. The logic for "show the right fields for this vertical" polluted every screen in the product.
We rewrote it. Each industry now has its own booking type — with its own fields, its own forms, its own reports — that shares the universal parts (calendar, customer, capacity, communication) but ships its own specifics.
This duplicates some code. It ships more per industry than the abstraction did. We don't care. The product is dramatically easier to maintain, the screens are dramatically simpler, and adding a new vertical is now a two-week project instead of a three-month one. The abstraction was optimising for the wrong thing.
The nine verticals we landed on
Stays & Suites — the one we started with. Villas, apartments, guesthouses, hotels. Multi-unit calendars, direct bookings, seasonal pricing.
Dining — full-service restaurants. Floor plan view, table combinations, peak-season walk-in rules.
Events — weddings and private events. Date enquiries, package configurator, deposit tracking.
Salon & Studio — hairdressers, barbers, tattoo studios, nail salons. Staff-column calendars, service packages, customer history.
Clinics — dental, GP, specialist. Patient records, treatment plans, e-prescription integration.
Wellness — physiotherapy, rehabilitation, spas that run treatment courses. Recurring-slot scheduling, progress notes, insurance.
Rentals — cars, equipment, bikes. Fleet calendars, handover checklists, deposits and contracts.
VIP & Nightlife — clubs, lounges, rooftop bars. Table reservations, bottle service, host commissions.
Atlas — esports arenas, LAN cafés, gaming venues. Station-level bookings, session timers, tournament brackets, member accounts. The newest of the nine, and the one that pushed us hardest on real-time state — an active gaming session is the most data-dense booking we’ve modelled.
These aren't obvious groupings. We arrived at them by refusing to add a new vertical until at least two interested operators existed. That filter stopped us from launching five specs-of-one, which would have been disastrous.
What it tells us about platform work
The honest meta-lesson: we underestimated how much of a platform is specific and how little is universal. The universal parts are bigger than a single-vertical SaaS suggests (which is why Solera can exist at all), but they're smaller than the "configure anything" pitch suggests (which is why most "configurable" platforms feel like nothing in particular).
The right ratio, for us, has turned out to be something like 60% shared, 40% vertical-specific. The shared 60% is the core product. The vertical-specific 40% is what the operator actually hires Solera for. Getting both right is what the work is.
Solera is still in development. Console launches June 2026; the consumer companion, Solera Go, follows in August. Nine verticals at launch, with more planned for late 2026. If you run a small business that does some version of reservations or bookings — and your current tools aren't quite right — we'd love to hear from you.