I Never Worked as a Developer
Let me get the obvious thing out of the way: I’m not an engineer. Not by career, anyway.
For 10 years I worked in startup operations — Paytm, Fluidworks, Aviyel, and a string of consulting gigs. I was always the ops guy. The one writing launch plans, managing partner integrations, building growth playbooks, and putting out fires at 2 AM so the product team could sleep.
I understood technology deeply. I could spec a feature, argue about database design, and debug a deployment pipeline. But I never wrote the code myself. That was always someone else’s job.
At 36, I’m building two SaaS products completely solo. One of them — Dszape — is a full hotel management platform with 245 API routes, 719 source files, a CMS website builder, a booking engine, a billing system, and a front desk dashboard. The other — Odessis — is live and serving real users.
This isn’t a tutorial project. It’s production software. And I’m building it with AI.
Here’s exactly how.
The Stack That Replaced a Team
When I decided to build, I didn’t pick tools randomly. I asked one question at each layer of the stack, and let the answer guide me.
Database: Is your data relational?
Hotels have deeply interconnected data. A booking references a guest, a room, a room type, a rate plan, a folio, and tax rules. Everything references everything else.
This is textbook relational data. NoSQL would have been a disaster — denormalising all these relationships would mean duplicating data everywhere and praying it stays in sync.
I went with Supabase, which is PostgreSQL underneath. I get full SQL, foreign keys, constraints, and — crucially — Row Level Security (RLS) for multi-tenant isolation. Every hotel only sees their own data, enforced at the database layer, not with app-level if/else statements.
Auth: Do you need multi-tenant isolation?
For a B2B SaaS where every customer has private data, auth isn’t just “who is this person?” — it’s “what data can this person see?” I use Clerk for identity (login, signup, session management) and Supabase RLS for data isolation. Two layers, not one.
Framework: Does SEO matter?
Hotels need public booking pages that Google can index. Guests search “Hotel Golden Eye Goa” and need to find the booking page. This means server-side rendering is non-negotiable.
Next.js 15 with App Router gives me both: server components for SEO-critical pages, client components for interactive dashboards. One framework handles both the public-facing website and the private management dashboard.
Deployment: How fast must you iterate?
As a solo builder, I have zero DevOps budget. No Docker. No CI/CD pipelines to babysit. Vercel deploys on git push — code is live in 30 seconds. That’s the entire deployment process.
AI Development Partner: How deep is your codebase?
This is where it gets interesting. With 719 files, I can’t just paste code snippets into a chat window. I need an AI that understands the entire codebase — the architecture, the conventions, the existing patterns.
Claude Code runs inside the repo. It reads every file, understands how they connect, and writes code that fits the existing patterns. It’s not autocomplete. It’s closer to a junior developer who has read every file in the project and never forgets anything.
How I Actually Work With Claude
Most people use AI like a search engine: paste an error, get a fix, move on. My workflow is fundamentally different.
Step 1: Describe the Problem, Not the Solution
I never say “build me a booking form.” Instead, I describe the actual business problem:
“Hotel guests need to select dates, pick room types with live availability, apply promo codes, see tax breakdowns calculated per Indian state GST rules, and pay via Stripe or Razorpay. Walk-in guests bypass this entirely and go straight to check-in. The folio isn’t created until check-in because walk-ins don’t have prior bookings.”
That level of specificity comes from watching hotel managers struggle with bad software for years. The AI can write code. But only a human who understands the domain can describe what the code needs to do.
Step 2: Architecture First, Code Second
Claude proposes an architecture. I push back based on 10 years of seeing what breaks:
- “Use a flat table for bookings” — No. Bookings reference room_types, rate_plans, and tax_rules. Normalise it.
- “Derive folio status from the balance” — No. We got burned when balance = 0 didn’t mean “settled.” Status must come from the database column, not be calculated.
- “Create the folio when the panel opens” — No. Walk-in guests don’t have bookings. The folio is created at check-in time, not before.
Every pushback comes from a real incident. The billing bug that zeroed out 56 folios? That taught me Rule D-4: financial operations must throw on failure, never return null. The onboarding reset that affected every signed-in user? That taught me Rule R-1: never destructure {data} from a Supabase query without also destructuring {error}.
Step 3: Code Review Like a Tech Lead
Claude writes the code. I review it for:
- Silent error swallowing — the pattern
catch { return null }caused two P0 production incidents - Missing auth checks — every API route must verify the user owns the data they’re requesting
- Wrong column references — we once had code writing to database columns that didn’t exist because a migration was moved without a replacement
- Edge cases in financial operations — rounding errors, currency formatting, tax calculations
Step 4: Test Like a User
The final check is always the same: open the browser, create a booking, check in, add charges, record payment, checkout. If I can’t complete the flow end-to-end as a hotel receptionist would, the feature isn’t done.
This is the part most vibe coders skip. tsc clean and tests pass is not the same as “it works.” Runtime evidence is the only evidence that counts.
What’s Actually Built
Dszape isn’t a landing page with a waitlist. It’s a working platform:
- Booking engine with real-time availability, promo codes, seasonal pricing, and multi-currency support
- Front desk dashboard with guest lifecycle management (booking, check-in, folio, payment, checkout)
- Billing system with automated folio creation, charge posting, payment recording, and settlement
- CMS website builder with templates so hotels can create their own branded booking sites
- Rate calendar with seasonal and weekend pricing, dynamic rate adjustments
- Analytics dashboard connected to PostHog for booking funnel analysis
- Multi-property support designed from day one
Is it perfect? No. The promo codes only work in the public booking flow right now — walk-in and reservation promos are still being built. There are 6 open bugs in the incentive layer. The room creation UI is missing for fresh hotel onboarding.
But it ships. Every day something gets better.
The Honest Failure Log
Building in public means sharing what breaks, not just what ships.
The Folio Apocalypse (P0)
A database migration was moved to a backup folder without a replacement. The billing engine kept writing to columns that no longer existed. Every insert silently failed. Result: 50 out of 56 production folios showed a balance of zero. Every hotel’s billing was broken for weeks before anyone noticed.
Lesson: A migration file on disk does not mean the migration ran. Always verify columns exist in the live database before writing code that references them.
The Onboarding Reset (P0)
Three server-side rendering files each had their own copy of “look up the current user’s hotel.” When the auth client configuration changed, the query started returning errors instead of data. But nobody was checking for errors — the code destructured { data } and treated null as “this user has no hotel.” Every signed-in user got bounced back to onboarding step 1.
Lesson: Silence is not success. Every database query can fail. If you don’t check for the error, you’ll treat the failure as an empty result.
The Dead Routes Graveyard
17 features were “shipped” — code written, routes created, tests passing — but the database migrations were never applied to production. The features returned 500 errors for every request. Some of them sat broken for weeks.
Lesson: A committed migration file is not the same as an applied migration. Verify against the live database, not the file system.
Why Domain Expertise Beats Engineering Headcount
Here’s the non-obvious insight from this journey: the hard part of building software isn’t writing code. It’s knowing what to build and knowing when it’s wrong.
AI handles the syntax. But it can’t tell you that hotel folios shouldn’t be created before check-in. It can’t tell you that deriving status from balance === 0 will break when a hotel comps a room. It can’t tell you that Indian GST calculations differ by state and service type.
That knowledge comes from watching hotel managers use (and curse at) existing software. From sitting in ops meetings where someone explains why the PMS charges are never right. From understanding that a 20-room boutique hotel in Goa has completely different needs than a 200-room business hotel in Mumbai.
10 years of startup operations gave me something more valuable than coding skills: taste. The ability to look at a feature and know whether it will actually work for the person who has to use it eight hours a day.
That’s the real vibe coding skill. Not prompting. Not syntax. Judgment.
The Numbers
Since I’m building in public, here are the honest numbers:
- Source files: 719
- API routes: 245
- Database migrations: 80+
- P0 incidents: 3 (all found and fixed)
- Production folios affected by bugs: 56 (all recovered)
- Team size: 1 human + Claude
- Time to build: ~3 months of active development
- Monthly infrastructure cost: $0 (free tiers of Supabase, Vercel, Clerk)
What This Means for You
If you’re reading this and thinking “I could never do that” — I get it. I thought the same thing two years ago.
But here’s what I’ve learned: the barrier to building software has collapsed. Not gradually — suddenly. The tools in 2026 are fundamentally different from 2023. An AI that can read your entire codebase and write code that fits is a different category of tool than autocomplete.
What hasn’t changed is the need for someone who understands the problem. The domain expert. The person who’s spent years watching customers struggle and knows exactly what they need.
If that’s you — if you’ve spent years in an industry and you know what’s broken — the tools are ready. The only thing missing is the nerve to try.
I’m sharing every step of this journey. Follow along on X (@evan_d_souza) and LinkedIn.
Building something with AI? I’d love to hear about it. Reach out on X or LinkedIn — I respond to everyone.
