I did not arrive here as a software engineer
I spent a decade in startup operations across roles at Paytm, Fluidworks and Aviyel, followed by independent work. I wrote launch plans, managed partner integrations, built operating playbooks and investigated the awkward failures that sit between teams. Code was usually someone else’s job.
Now I am building Dszape, a hotel software product, with AI as part of the development system. I also publish BeckyOS on npm, the agent operating system that grew out of this work.
That does not make me a career engineer, and it does not make AI a substitute for engineering judgment. It means the distance between a domain problem and a testable implementation has shortened enough for me to work differently.
This is a first-hand account of that workflow. It is not a customer-outcome report. An earlier version carried precise codebase counts, build times and incident-impact numbers without one public, dated evidence package behind them. I have removed those numbers. Precision is useful only when another person can see what was counted, when it was counted and what the number excludes.
The durable story is better than the inflated one: I turn hotel workflows into explicit contracts, use AI to help implement them, and refuse to call the result finished until the running system produces evidence.
The work AI did not remove
The hard part is rarely typing the first version of a function. It is deciding what correct means when several systems and people touch the same event.
Consider a hotel check-in. A reservation may refer to a guest, room type, assigned room, rate plan, tax configuration, payment state and folio. A walk-in follows a different entry path. A late room assignment should not corrupt availability. A failed financial write should not look like an empty result.
AI can help trace those relationships and implement the contract. It cannot invent a trustworthy contract from a vague prompt. That is why my workflow begins with the operating problem, not the interface.
This is also why I reject the phrase “the stack replaced a team.” I am one builder using tools. Security review, accounting judgment, domain validation and customer support remain real disciplines even when one person coordinates them.
My stack is a set of decisions, not a shopping list
I chose each layer because of a project constraint. These choices are not universal recommendations.
Relational data and tenant boundaries
Hotel records are relational, so Dszape uses PostgreSQL through Supabase. Supabase documents how Row Level Security policies can restrict which rows a request may access.
That documentation proves the platform has the capability. It does not prove my policies are correct. My implementation still needs tenant-isolation tests that attempt cross-property reads and writes with the wrong identity.
I use Clerk for identity and session handling. Clerk’s current Next.js reference explains the integration surface, but a configured SDK is not an authorization oracle. Identity answers who is making a request. Database policy and application rules still decide what that identity may do.
Public pages and private workflows
Dszape has public pages that need stable URLs and indexable content, alongside authenticated operational screens. Next.js supports several rendering and caching choices, so I can choose the route behavior that fits each surface.
I used to describe server rendering as non-negotiable for SEO. That was too absolute. Google can process JavaScript, and its own JavaScript SEO guidance explains both the capability and the practical constraints. My narrower decision is to give important public routes predictable HTML and URLs while keeping interactive work where it belongs.
Repository-aware AI
I use Claude Code inside the repository. Anthropic’s official overview describes its ability to inspect a codebase, edit files and run commands.
I no longer say that it reads every file or never forgets. Context is finite. A useful session depends on project rules, relevant source files, current runtime evidence and a clear task boundary. The quality of the surrounding system matters as much as the model.
Deployment is a release path, not proof
Git-connected deployment makes iteration convenient. Vercel documents how Git events can create deployments. I removed my old claim that every change was live in a fixed number of seconds because a deploy log, not memory, should support a timing claim.
More importantly, a successful deployment only proves that a build reached an environment. It does not prove that a receptionist can complete a check-in or that a financial write reached the expected table.
How I work with AI now
1. Describe the operating problem
I start with actors, states, constraints and failure paths.
Instead of “build a booking form,” the useful brief says who is booking, what availability means, when a room becomes unavailable, which price is authoritative, what happens when payment fails and which state another team sees next.
This is the same reason I treat a software build as an operating-system problem. The seven-layer startup operating-system map separates promises, decisions, workflows, evidence and learning before a tool is allowed to hide the gaps.
2. Ask for architecture before implementation
I ask the agent to trace the existing data model, callers, side effects and rollback path. Then I challenge the proposal with domain constraints.
A folio status should not be inferred from a convenient number if the business has explicit settlement states. A room assignment should not be duplicated across tables without an ownership rule. A tax calculation should not come from model intuition. Tax treatment needs a reviewed product contract and qualified advice, not a plausible paragraph generated during coding.
The practical question is not whether AI can produce code. It is whether the proposed architecture preserves the business invariant when the happy path stops being happy.
3. Make implementation inspectable
The agent can write migrations, routes, UI states and tests, but each change needs a bounded diff. I want to know:
- which contract changed;
- which data is read and written;
- which permissions are required;
- how failure is represented;
- how the change can be rolled back;
- which existing workflow could regress.
My build-versus-buy framework uses the same logic. Building is not cheaper merely because code generation is fast. The ongoing evidence, security and maintenance burden still belongs to someone.
4. Review the seams
AI-generated code often looks locally reasonable. The dangerous defects live between files and systems: a migration that has not reached the live database, an authorization check that exists on one route but not its sibling, or an error converted into null and mistaken for “no record.”
I review those seams explicitly. The detailed controls are in my production guardrails for AI-assisted coding.
5. Test the real journey
A clean type check is useful. A passing unit test is useful. Neither proves the complete user journey.
For a hotel workflow, I want to open the browser, create or select the relevant record, move through the actual states and inspect the final database effect. When the change touches money or permissions, I also need negative paths: failed writes, wrong-tenant access, duplicate actions and interrupted retries.
My agent-assisted QA workflow explains how I turn those journeys into repeatable tests without pretending automated checks are a complete quality certification.
6. Attach evidence to the claim
This is the step that changed my build process most.
Every release claim should name its evidence. “The build passed” points to a build log. “The journey works” points to a browser trace or recorded test. “The migration is live” points to a database inspection. “The incident is fixed” points to a regression test plus the recovery check.
I made the worksheet I now use for that handoff available here:
Download the solo SaaS claim-to-evidence ledger
The CSV is intentionally plain. Replace every REPLACE field with evidence from your own system. A blank evidence cell is not a failure to write better copy. It is a release gap.
Three failures that changed my rules
These are bounded recollections from my own build, not independently audited customer case studies. I am sharing the failure pattern and the rule it produced. I am not repeating the old customer counts, durations or recovery totals because I do not have a public evidence package that responsibly supports them.
A migration existed in Git but not where the code needed it
A write path targeted columns that were absent from the environment receiving the request. The code and migration history looked plausible when reviewed separately.
Rule: a migration file is an intention. Verify the live schema before releasing code that depends on it.
An error looked like an empty result
An identity-to-property lookup returned an error. Code checked only the data value, treated the absence as “no property” and sent the user down the wrong path.
Rule: destructure and handle both data and error. Empty, denied and failed are different states.
Routes existed without a runnable dependency chain
Some feature routes had code and tests but depended on environment state that had not been established.
Rule: a route is not shipped until its dependencies are present and the complete workflow runs in the target environment.
These lessons are less dramatic without giant numbers. They are also more useful. Each one can become a testable release gate.
What I can prove publicly, and what I cannot
The public Dszape website establishes that the product is positioned around hotel websites, direct booking and management workflows. It does not prove every authenticated feature, every private tenant configuration or any customer outcome.
The npm registry establishes that BeckyOS is a published package. It does not prove that the method will work for another team.
My private repository, database and deployment history contain more operational evidence, but private evidence should not be converted into precise public claims by confidence alone. When I want to publish a number, I need a dated, redacted artifact that another person can inspect without exposing customer data or security-sensitive detail.
That boundary is not modesty theatre. It is part of building in public responsibly.
What operations experience contributes
My operations background does not make engineering disciplines optional. It gives me a particular advantage at the start of the loop: I know to ask who owns the exception, what the next team sees and how a silent failure changes the customer promise.
That domain judgment is especially useful in vertical software, where a generic workflow can be technically correct and operationally wrong. I have written separately about what building vertical SaaS taught me.
The broader lesson is not “anyone can build anything now.” It is this: a domain operator can move much closer to implementation, provided they build an evidence system around the speed AI gives them.
A release checklist I can defend
Before I describe a feature as shipped, I want five answers:
- Contract: What user promise or internal invariant changed?
- Authority: Who or what is allowed to make the change?
- State: Which source of truth records the result?
- Failure: How does the system represent denial, interruption and retry?
- Evidence: Which runtime artifact proves the target journey and its important negative path?
That checklist is deliberately smaller than a complete engineering standard. It is the minimum bridge between an impressive diff and a responsible claim.
For founders, the same discipline exposes a second risk: the product can become dependent on one person who holds every decision and exception in their head. The founder dependency audit is the operating companion to this build workflow.
The honest conclusion
AI changed who can attempt a software build and how quickly implementation can move. It did not remove architecture, security, testing, operations or accountability.
The most valuable skill I brought from operations was not a secret prompt. It was judgment: recognising the difference between an output that looks finished and a system another person can safely depend on.
I still use AI every day. I also ask for harder proof than I did when I began.
FAQ
Can a non-developer build SaaS with AI?
They can build and test meaningful software, but code generation is only part of the responsibility. Domain definition, architecture, security, data boundaries, runtime verification and incident response still need competent ownership. The consequence of the workflow should determine where qualified engineering or specialist review is mandatory.
What is the biggest risk in AI-assisted SaaS development?
False confidence. Code can compile while a migration is missing, a permission boundary is wrong or a real user journey is broken. Treat generated code as a proposal until the running system supplies evidence.
Does AI replace software engineering judgment?
No. It can accelerate implementation, exploration and review. Someone must still define correct behaviour, decide which trade-offs are acceptable and own the result.
What should a solo founder automate first?
Start with repeatable, observable and reversible work. Keep financial changes, permissions, sensitive data and consequential customer actions behind deterministic checks or human approval until the workflow has stronger evidence.
Is a free-tier infrastructure stack enough for production?
It may support an early build or limited workload, but a free tier is not a permanent cost model. Measure database, compute, storage, bandwidth, observability and support requirements against real usage. I removed the exact zero-cost claim from this article because I did not attach a dated billing record.
Why publish an evidence ledger?
Because it forces each release sentence to name the artifact that supports it. It also makes uncertainty visible before a confident claim reaches a customer, investor or public article.
