Ship a real SaaS without leaving your IDE using OTF's full prompt loop

The hard part of SaaS is not shipping code. It is bottling the feedback loop so tight you never leave the zone. Typing "add a Team entity, stub a settings screen, update routes, wire it to auth" should be a single dialogue. Done manually, you jump between codebase, browser, and docs. Done with a regeneration tool, you get back half-correct files you spend hours patching — because regeneration is amnesia, not automation.

The alternative: stay in your IDE, point an agent at a kit it can actually read, and say "extend this." No yak shaving, no lateral context loss — just a prompt and a diff. That is the workflow this post walks through: the full loop from prompt to production without leaving the editor. The premise rests on in-IDE agents that genuinely understand a codebase — Cursor, for example, is documented as an agent that reads and works inside your code (Cursor docs) — and on a live artifact the loop is meant to produce, which you can inspect right now at the OTF SaaS demo.

Regeneration is not a workflowCopy Anchor Link

A whole genre of tools promises "instant SaaS" — full-stack apps generated in seconds. As an opinion, not a fact about any named product: that path tends to break the moment the spec touches reality, because every regenerate starts from scratch. Your edits vanish or clash. The model reverse-engineers structure from raw code, drops imports, misses routers, bungles naming. You fight drift between the code in one tab, the spec in another, and the codegen script on the side.

Ship that way and every diff is a minefield. "Just one more change" costs two hours.

Takeaway: generation without extension is demo-ware. Real software needs edit-from-current-state, every time.

What it takes to extend, not replaceCopy Anchor Link

Extension is a different contract:

• The agent can see and navigate the kit: entity schemas, components, routes, auth, docs, tests.
• Every prompt is an edit from the current state — a reviewable change, not a throwaway file.
• The kit carries the developer-experience glue: shared patterns, naming conventions, and AI-readable instructions checked in from the start.

OTF's kits are built to be extended, not regenerated, with agent instructions (CLAUDE.md, .cursorrules, annotated prompts) checked into the repo itself. The exact file inventory drifts as kits evolve, so treat the sketch below as illustrative of the pattern rather than a literal listing:

# CLAUDE.md (illustrative)

You are coding _within_ a TypeScript SaaS dashboard template.

- Only extend, do not regenerate existing entities.
- Reuse the existing component primitives and prop interfaces.
- Mirror naming in routes and components for new entities.

Agents are not guessing — they are on rails. For the conventions that make this work, see our Cursor rules for Next.js and the Cursor prompts guide.

In-IDE, visible, incremental: what the real loop feels likeCopy Anchor Link

Extending an entity, wiring a screen, and testing it should be one loop:

1. Start in your IDE — VS Code, Cursor, or anything that speaks to a repo. Switch to a browser only to preview.
2. Write a prompt near the code, not in a playground — instruct the agent: "Add a Team entity with CRUD screens and link it to User."
3. The agent reads the kit plus the prompt — modern agents load the actual files: schema, routes, components, instruction files.
4. It generates minimal, surgical diffs — only what is new: the schema addition, the route, the form components.
5. Results show up as staged changes — review, tweak, commit, all in your branch.

No file-patch panic. You see every change, run the tests, and ship.

A concrete example: adding Teams to a SaaS kitCopy Anchor Link

In a repo bootstrapped from a SaaS dashboard kit, extending the product looks like a conversation. The prompt below and the schema sketch are illustrative — they show the shape of the loop, not a literal transcript:

Prompt: "Add a Team entity: id, name, creation date. Teams list page with create, edit, delete. Link teams to users. Only visible to logged-in users."

Agent process:

• Extends the data model instead of rewriting it:

// Illustrative schema extension
model Team {
  id        String   @id @default(uuid())
  name      String
  createdAt DateTime @default(now())
  users     User[]   @relation("UserTeams")
}

• Adds a route file and list/form components following existing conventions.
• Threads auth through the kit's existing session helpers.
• Updates docs and inline comments for the new surface.

You review, tweak, test. Zero browser alt-tab. Zero throwaway codegen scripts.

Auth, billing, routes, UI: why the kit must be AI-readableCopy Anchor Link

If the agent cannot follow structure, complexity explodes:

• Auth patterns: it must know how the kit gates routes and API calls.
• Billing wiring: adding an entitlement means touching config, endpoints, and UI in the right places.
• Route conventions: file-based or configured? Where do modals live?
• Component reuse: reuse the kit's primitives every time instead of inventing new ones.

The pattern, again illustrative:

// routes/teams.tsx (illustrative)
import { requireAuth } from "@/lib/auth";

export default async function TeamsPage() {
  await requireAuth();
  // Render teams...
}

Takeaway: the more the kit encodes intent and conventions, the less the agent hallucinates.

Adding a screen: the full loopCopy Anchor Link

• Prompt: "Add a team settings screen for team owners; store notification preferences on the team."
• Agent: reads the existing team files, extends the schema, adds the settings route and form, gates it to owners, reuses kit form validation and components.

All without leaving the IDE. Every step visible, editable, and consistent with existing patterns. When you are ready to take the result live, the ship AI MVP to production checklist covers the path from repo to production URL.

The durable layer: your repo, your rulesCopy Anchor Link

Models churn. Agent wrappers churn. Prompt frameworks churn. The durable asset is the kit that encodes structure, patterns, and how the pieces hang together:

• Agents run on top and are swappable — the instructions-in-repo pattern works regardless of model.
• The core remains the kit: you own the repo, the patterns, and the code. No lock-in.
• When a new surface arrives, the agent runs over the kit, not the other way around.

What this enablesCopy Anchor Link

• Zero-context-switch shipping: from idea to change in one loop, always in the IDE.
• Diffable, testable changes: everything surfaces as reviewable changes before merge. No black-box codegen.
• Reuse: existing auth, billing, and routes are extended, never stomped. Every feature is a first-class citizen of the repo.
• One contract: any model, any editor, same workflow — because the real contract is readable, extensible code.

Stay in the zone: prompt, extend, ship. Adding an entity or a screen stops being a context break and becomes just the next prompt. The repo is yours; the agent is an extra set of hands.

Ready to extend instead of regenerate? Browse the OTF kits →

SourcesCopy Anchor Link

• Cursor documentation — Cursor as a codebase-aware coding agent; cited for the in-IDE agent premise.
• OTF SaaS demo — the live dashboard; cited as the artifact this workflow produces.
• OTF templates — the kit catalog; kit-content claims above are framed as OTF's workflow position, with file sketches marked illustrative.