Everyone tells solo founders to build a horizontal tool. A form builder. A CRM. A “notion for X”. The market is huge, the demos are easy, and you can explain it to anyone in one line.
I did the opposite. I’m building Dszape, a hotel management platform — “Shopify for hotels” — completely solo, with AI doing the heavy lifting on code. 245+ API routes, 719+ source files, 180+ SQL migrations. A booking engine, a folio and billing engine, a front-desk dashboard, a CMS website builder.
Two years ago I would have said this is too much software for one person. It isn’t anymore. But the real lesson isn’t about AI. It’s about why vertical was the right call in the first place, and what hotel software specifically taught me about building deep instead of wide.
Why Vertical Beats Horizontal for a Solo Founder
Horizontal SaaS competes on distribution. Vertical SaaS competes on understanding.
If you build a generic project management tool, you’re up against companies with hundreds of engineers and nine-figure marketing budgets. Your only edge is being cheaper or slightly nicer to use, and both of those erode fast.
If you build for one industry, your competition is usually legacy software that the industry actively hates. Hotel PMS software is a great example. Most of it looks like it was designed in 2009, charges per module, and requires a training week before a receptionist can check someone in.
The bar isn’t “beat a giant”. The bar is “be the first product this receptionist doesn’t curse at”.
There’s a second, less obvious advantage for a solo founder: a vertical product has a finite surface. Hotels need bookings, check-ins, folios, invoices, rates, housekeeping. That list is long, but it ends. A horizontal tool never ends — every customer pulls you in a different direction, and a team of one cannot serve twenty directions.
Domain Depth Is the Actual Moat
Here’s what I mean by depth. These are real objects in Dszape, and every one of them is a small mountain of business logic:
Folios. A folio is the running bill for a stay. Charges get posted to it, payments get recorded against it, and at checkout it has to settle to zero. Sounds simple. Now add: a corporate guest whose company pays for the room but the guest pays for the minibar, so every charge line needs a “bill to” identity. Add a discount applied after the guest has already paid. Add the rule that a settled folio must never accept new charges. I learned the hard way that this last one needs to be enforced in three layers — application code, lint rules, and a database trigger — because one layer always gets bypassed eventually.
Night audits. Hotels post room charges night by night, not as one lump sum. A guest who extends their stay mid-visit needs the extra nights posted at the rate they were originally quoted, not whatever the rate happens to be today. Miss that and you silently under-bill or over-bill people. Both happened to me before I froze a rate snapshot onto every booking at creation time.
Rate plans. Base price, seasonal overrides, day-of-week rates, promo codes, corporate rates. The interaction rules matter enormously: a specific-date price override is absolute, it replaces the base price — it does not get multiplied by a rate-plan multiplier on top. I shipped that multiplication bug. It overcharged guests until my own testing campaign caught it.
Check-in state machines. A stay moves through confirmed, checked in, due today, overstay, checked out. Each stage dictates exactly what the front-desk screen may show. No folio exists before check-in. No payment button after checkout. I keep this as a literal table in my project rules, and any UI that violates the table is treated as a P0 bug.
GST invoices. In India, a corporate guest needs a B2B invoice with their company’s GSTIN on it, or their finance team can’t claim input tax credit. An invoice generator that quietly falls back to the guest’s personal details isn’t a cosmetic bug — it costs your customer real money. Mine did exactly that once. Now the invoice engine refuses to emit a corporate invoice without a valid buyer GSTIN. It throws an error rather than producing a polite, wrong PDF.
None of this knowledge is in a tutorial. Almost none of it is even in the incumbent products’ documentation. It accumulates from watching hotels operate and from getting it wrong in production. That accumulation is the moat. A competitor can copy my UI in a weekend. Copying eighteen months of encoded operational edge cases is a different job entirely.
”Shopify for Hotels” — Why Positioning Against a Platform Works
I describe Dszape as Shopify for hotels, and the analogy is doing real work.
Shopify’s insight wasn’t “merchants need a website”. It was that a merchant needs the storefront, the inventory, the payments, and the back office to be one system, owned by them, without hiring an agency.
Small and mid-sized hotels are in the same position e-commerce merchants were in 2010. They rent their online presence from OTAs — the booking aggregators — and pay hefty commissions for the privilege. Their “website” is often a brochure page with a phone number.
So Dszape bundles what Shopify bundled: a CMS website builder so the hotel owns a real, bookable site; a direct booking engine on that site; and the operational back office (front desk, folios, billing, rates) behind it. The pitch to a hotel owner is one sentence: own your bookings instead of renting them.
The positioning also disciplines the roadmap. When I’m tempted by a feature, I ask whether Shopify would consider its equivalent core. That kills a lot of clever ideas early, which is exactly what a solo founder needs.
Multi-Tenant Isolation with Postgres RLS, in Plain Language
The scariest sentence in B2B SaaS is “Hotel A saw Hotel B’s guests”. One incident like that and you’re finished, and rightly so.
The traditional way to prevent it is app-level filtering: every single database query remembers to add “where hotel_id = the current hotel”. The problem is the word remembers. Across 245+ API routes, someone — human or AI — eventually writes a query that forgets the filter. Now you have a data leak, and no error message, because the query worked fine. It just worked too well.
Postgres Row Level Security flips this. You attach the rule to the table itself: “rows in this table are only visible to the tenant that owns them”. The database enforces it on every query, no matter who wrote the query or what they forgot. Supabase, which is Postgres underneath, makes wiring this to your auth system reasonably painless.
The operator’s way to think about it: app-level filtering is an SOP that says “please lock the door when you leave”. RLS is a door that locks itself. Having spent ten years writing SOPs, I can tell you which one survives contact with reality.
This matters double when AI is writing a lot of your code. My agents generate queries constantly. I’d rather have isolation guaranteed by the database than depend on every generated query being perfect. I wrote more about that whole safety layer in vibe coding in production: guardrails that actually work.
One honest caveat: RLS is not free. Policies can slow queries if written carelessly, debugging “why is this row invisible” takes getting used to, and server-side admin code that bypasses RLS needs its own discipline. It’s still the right default for multi-tenant SaaS.
The India Hospitality Angle
Building from Bengaluru, the Indian market shaped the product in ways a US-focused PMS would never bother with.
India has an enormous long tail of independent hotels, guest houses and boutique properties — exactly the segment global PMS vendors ignore because the contract values are small. But the aggregate is huge, and these owners are more WhatsApp-native than email-native, more price-sensitive, and completely unserved by software that respects them.
The domain specifics are real too. GST compliance isn’t optional decoration; it’s the difference between a corporate client booking with you again or not. Walk-in guests are a far bigger share of business here than in Western markets, so a walk-in flow that skips the whole “booking” concept and goes straight to check-in had to be a first-class citizen, not an afterthought. Pricing in rupees, storing prices in whole units, formatting lakhs correctly — small things that instantly signal whether software was built for this market or ported to it.
Vertical plus geography is a double niche. It sounds limiting. In practice it means every product decision has one clear customer in mind, which is the closest thing to a cheat code a solo founder gets. I’ve written before about pricing SaaS for Indian startups — the same logic applies to hotels.
What I’d Tell a Solo Founder Choosing a Vertical
A few filters that would have saved me time if someone had handed them to me:
Pick an industry you’ve actually watched operate. Not one you’ve read about. The folio edge cases above are invisible from the outside. My ops background is the only reason I could spec them — I’ve made the longer case that this is a repeatable path in from ops manager to solo SaaS founder, and the full story of how AI turns domain knowledge into working software is in how I build SaaS solo with AI. The tooling that makes the volume of code feasible for one person is in the solo founder AI stack.
Check that the incumbents are hated, not just old. Old software with happy users is a terrible market. Old software that staff work around with Excel sheets is a great one.
Make sure the domain has hard rules. GST, folios, settlement, state machines — rules are what make depth defensible. If the domain is vibes, a horizontal tool will eat you.
Respect the finite surface. Write down the list of things the vertical genuinely needs. Build that. Every request outside the list gets a polite no. This is a build-vs-buy decision applied to your own roadmap.
FAQ
Is vertical SaaS really viable for a solo founder?
More viable than horizontal, in my experience. The surface area is finite, the competition is legacy software, and AI coding agents now handle the volume of code a vertical platform needs. The binding constraint is domain knowledge, not headcount.
Why use Postgres RLS instead of filtering by tenant in application code?
Because app-level filtering fails silently the first time one query forgets the filter, and across hundreds of routes one eventually will. RLS makes the database itself enforce tenant isolation on every query. It’s a self-locking door instead of a rule about locking doors.
What makes hotel software so complicated?
The money paths. Folios, night-by-night charge posting, frozen rate quotes, split corporate billing and GST-compliant invoicing all interact, and every combination is a place to silently lose or misbill money. The UI is the easy part.
How is “Shopify for hotels” different from a channel manager or booking engine?
Those are point tools that plug into someone else’s system. The Shopify analogy means the hotel owns the whole loop — their website, their direct bookings, and their back office — in one platform, instead of renting their online presence from OTAs.
I write about building Dszape in public — the wins and the production incidents both. If this was useful, there’s more where it came from on the about page.
