Using AI in SaaS Builds Without the Generic Output

I use AI on almost every project now. It saves hours. It also ships embarrassing mistakes if I let it run without guardrails.

On DealGPT the models helped draft agent configs and early UI states. On Zesty they were useful for menu copy and internal docs. Neither product would be better if I had pasted model output straight into production. The useful part was speed on the boring bits, then my team arguing about what actually mattered for restaurant staff at 8pm on a Friday.

This is how I think about AI-assisted SaaS development after ten years of building web and mobile products: AI is a fast intern with confidence problems. You still need judgment.

What "AI slop" looks like when you are building

Slop is not just bad blog posts. You see it in products too.

A landing page that mentions "streamline workflows" and "unlock insights" but never says who pays or why. A dashboard with six charts and no obvious next step. Code that demos fine until two accounts try to access the same record. Docs that answer questions nobody asked.

You have probably shipped some of this. I have. Usually right before a founder realizes the MVP needs another two weeks and the AI-generated scope doc was lying.

Give AI a job title, not the whole company

The failure mode I see most: one person asks the model to be PM, architect, designer, engineer, QA, and marketer in a single thread. You get a coherent document and an incoherent product.

What works better is narrow tasks. Cluster interview notes. Propose three schema options with tradeoffs. Draft test cases for a billing webhook. Rewrite an empty state so it tells the user what to upload. Summarize fifty support tickets by topic.

You decide what is true, what ships, and what gets cut.

Start with evidence, not prompt engineering theater

The best outputs I get are never from clever system prompts. They come from messy real inputs.

Last week that might mean twelve interview snippets, a Loom of someone failing onboarding, or a spreadsheet of manual steps a client still does in Excel. Strip anything sensitive, paste the substance, ask a focused question.

Weak:

Give me ideas for a SaaS app.

What I send instead:

Here are 12 customer interview notes from agency owners who struggle with client approvals.
Identify repeated pain points, quote the customer language, group the jobs-to-be-done, and suggest three focused MVP workflows. Do not suggest features unless they directly solve a repeated pain.

Use AI to shrink scope, not inflate it

Founders love asking "what features should my app have?" Models love answering with a thirty-item backlog.

Flip the question. Ask what you can remove and still deliver the first useful outcome. For a client approval tool, the loop might be:

1. Agency uploads a deliverable.
2. Client gets a private review link.
3. Client approves or leaves structured feedback.
4. Agency sees status without chasing email.

That is buildable. It is also marketable. Compare that to a generic "project management platform." See the SaaS MVP checklist for how I cut scope on client projects without cutting learning.

A discovery workflow that survived contact with reality

This is close to what I run on new products:

1. Dump raw notes from calls, chats, reviews.
2. Remove private data.
3. Ask the model to cluster pains and pull exact phrases people use.
4. Turn clusters into jobs-to-be-done, not feature names.
5. Rank by urgency, frequency, and whether someone will pay this quarter.
6. Sketch two or three narrow workflow options.
7. Stop and talk to humans again.

Step seven is non-negotiable. AI organizes evidence. It does not know your market.

Architecture: boring on purpose

Ask a model for "SaaS architecture" and you often get Kubernetes, event buses, and three databases. For most MVPs I have shipped, that is future pain disguised as progress.

My default stack thinking:

Every extra service is maintenance on a small team. I have regretted premature splits more than I have regretted a well-structured monolith.

Code from models still gets a code review

I treat generated code like a fast junior: useful, inconsistent, occasionally dangerous.

Before merge I always re-read auth, authorization, billing, file uploads, webhooks, background jobs, and anything that touches another tenant's data. On multi-tenant SaaS that is where demos die.

Where AI fails on security (and what I still do by hand)

Models are confident about auth. That is exactly why I do not let them own it.

AI-generated route handlers often look correct until you test IDOR: User A swaps an ID and lands in User B's project. Or the UI hides an admin button but the API still answers yes. Or a webhook handler updates subscription state without checking the signature. The code compiles. The demo works. Production is where it breaks.

I use AI to draft test ideas, threat-model notes, and checklist gaps. I do not use it as the final reviewer for anything that touches authentication, authorization, billing, file access, or tenant boundaries. Those get a manual pass with two test users and two organizations, the same way I describe in the SaaS MVP go-live guide.

Principles I do not outsource:

• Access control on the server, every time a record is read or mutated by ID.
• No trust in client-supplied identity fields (org, role, plan, price).
• Schema validation on bodies, params, and webhooks.
• Safe errors that do not leak stack traces, SQL, or internal paths.
• Signed, idempotent webhooks for payments and lifecycle events.

If a model generated the middleware, I still read the middleware.

Rate limits and legal pages: AI will skip both

Ask a model for a "production-ready SaaS" and you will get auth, a database, and a Stripe button. You probably will not get login throttling, export caps, a sensible privacy policy, or terms that match your refund rules.

Rate limiting needs product judgment. Which routes are expensive? What should happen when someone scripts your signup form at 3am? Should limits track IP, account, or organization? AI can suggest numbers. You decide what failure looks like when the limiter is down.

Legal pages need accuracy more than polish. A model can draft privacy policy boilerplate in seconds. It cannot know your subprocessors, retention rules, or whether you train on customer uploads. Templates are a starting point. Compare them to what the app actually collects and what your payment provider requires. Link policies from signup, footer, and checkout before you charge.

UI copy: small words, big difference

Operational SaaS lives or dies on clarity. Hierarchy, status, empty states, error text. Models can draft these. You still need to read them out loud like a tired user at midnight.

SEO content without the hollow middle

AI makes it easy to publish ten articles in a day. Google and humans both notice when nothing new was said.

I use models for outlines, keyword clustering, and turning support themes into briefs. The paragraphs come from what we built, what broke, and what customers argued about in calls. If I cannot point to a real decision or mistake, the piece stays in drafts.

How I edit before publish

1. Name the reader and the question they typed into Google.
2. Outline first. Argue with the outline before writing body text.
3. Add inputs only I have: screenshots, metrics, tradeoffs we considered.
4. Delete any line that fits a thousand other SaaS posts.
5. Add something usable: checklist, diagram, prompt that worked.
6. Read aloud. Fix the stiff bits.

Quality pass before anything customer-facing

Does this solve one specific workflow? Are permissions enforced on the server? Do rate limits exist on routes someone will abuse? Do privacy and terms match what we actually ship? Would I stake my name on this article?

Where AI earns its keep (and where it does not)

Judgment got more valuable, not less

Software is cheaper to start. That does not make taste free. The products I am proud of, like Zesty and Soma, are narrow on purpose. They do one job cleanly for people who do that job every day.

If you are building something similar and want a second pair of eyes on scope or architecture, get in touch. Happy to talk through what is worth building first.