DEV Community

Cover image for Ship a real SaaS without leaving your IDE using OTF's full prompt loop
Dave Kurian
Dave Kurian

Posted on • Originally published at otf-kit.dev

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

The hard part of SaaS isn't “shipping code”. It’s bottling the feedback loop so fast and tight you never leave the zone. Typing out “add a Team as an entity, stub a TeamSettings screen, update routes, wire with auth” should be a single dialogue. Manual? You jump around the codebase, browser, and docs, or weaponize a code LLM to blast out half-correct files you spend hours patching. Regeneration is amnesia, not automation.

The real enable: you stay in your IDE, point an AI at a kit it can actually read, and say, “extend this: add an entity, a screen, hook up auth, wire billing.” No yak shaving, no lateral context loss — just code and a prompt. That’s the SaaS Dashboard workflow at OTF: the agent isn’t hallucinating a greenfield app or smashing regen. It’s extending a kit, and every step is repeatable, editable, and always in your own repo.

This post walks the full loop: closing the agent-ship gap from prompt to production, never leaving your IDE.

1. “Regeneration” is not a workflow

Copy-paste tweets about “instant SaaS” describe tools that “generate full-stack apps in seconds” — demo-ware, not real software. The moment you want a second entity, those tools smash your codebase to dust:

  • Every “regenerate” starts from scratch: your edits vanish or clash. No awareness of what you added.
  • LLMs try to reverse-engineer structure from raw code. They drop imports, miss routers, and bungle naming — the context window always “just missed” something.
  • You fight drift: code in one tab, spec in another, codegen scripts on the side.

Ship this way and every diff is a minefield. You spend two hours making “just one more change”.

Takeaway: The instant-SaaS path is dead on arrival once the spec touches reality.

2. What it takes to extend, not replace

Extension is a different contract:

  • The AI can see and navigate the kit: entity schemas, components, routes, auth, even docs and tests.
  • Every prompt is an edit from the current state — not a throwaway file, but a PR-ready change.
  • The kit handles the devex glue: common patterns, named conventions, and AI-aware comments layered in from the start.

OTF's paid kits (/kits/saas-dashboard, /kits/fitness, /kits/booking) are built to be extended, not regenerated. They wire AI interpreter instructions — CLAUDE.md, .cursorrules, and dozens of annotated prompts — right in the repo:

# CLAUDE.md
You are coding _within_ a TypeScript SaaS dashboard template.
- Only extend, do not regenerate existing entities.
- Use `<Button>`, `<Dialog>`, `<Sheet>` with the existing prop interface.
- Mirror naming in `routes/` and `components/` for new entities.

# .cursorrules
[SCHEMA] Enhance the schema, don't re-create.
[ROUTES] Add new routes using file-based conventions.
[COMPONENTS] Reuse existing primitives unless custom is specified.
Enter fullscreen mode Exit fullscreen mode

Agents aren’t guessing — they’re on rails.

3. In-IDE, visible, incremental — what the real loop feels like

Extend an entity, wire a screen, test in one loop. Here’s the concrete workflow any AI-enabled dev kit must support:

  1. Start in your IDE — VS Code, Cursor, or anything that speaks to a repo. Never switch to a browser unless you’re previewing.
  2. Write a prompt near the code, not “in a playground” — Instruct an agent: “Add a Team entity with CRUD screens and link it to User.”
  3. The agent reads the kit + prompt — With 20k+ context (Claude, GPT-4o), it loads the actual files: schema, routes, components, CLAUDE.md, cursorrules.
  4. It generates minimal, surgical diffs — No mass file overwrites. Just what’s new: prisma/schema.prisma, routes/teams.tsx, components/TeamForm.tsx.
  5. Results show up as PR or staged changes — Review, tweak, commit. All in your branch.

No file-patch panic. You see every change, run tests, and hit “Ship.”

4. A concrete example: add “Team” to the SaaS dashboard kit

In a repo bootstrapped from OTF's SaaS Dashboard kit, you extend the product without leaving your IDE. Here’s what this looks like with an agent (Claude, Cursor, Copilot, take your pick; the loop is the same).

Prompt:

"Add a Team entity:

  • Team has id (uuid), name (string), createdAt (DateTime).
  • Make a Teams list page with create/edit/delete.
  • Link Team to User (user can belong to many teams).
  • Auth: only show Teams to logged-in users."

AI agent process:

  • Scans prisma/schema.prisma for models, injects:

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

model User {
  id     String   @id @default(uuid())
  // ...
  teams  Team[]   @relation("UserTeams")
}

  • Adds a route: routes/teams.tsx

  • Generates components/TeamList.tsx, components/TeamForm.tsx

  • Updates menu: injects <NavItem href="/teams" label="Teams" />

  • Threads auth logic: backend guards + frontend checks via kit's useSession

  • Updates docs (README.md, inline comments) for the new surface

  • Writes migrations as a one-liner: npx prisma migrate dev --name add-team

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

[[IMG: scene — a VS Code window, left: a diffs sidebar showing only the new Team files/components, right: the full code diff preview, below: the prompt as code-comment]]

5. Auth, billing, routes, UI: why the kit must be AI-readable

If the agent can't follow structure, complexity explodes:

  • Auth patterns: It must know how the kit gates routes and API calls.
  • Billing wiring: Adding a subscription or entitlement demand insertion in config, endpoints, UI.
  • Route conventions: Are screens file-based? Does a modal live with its route?
  • Component reuse: Don’t invent a “FancyButton” — use the kit’s Button, every time.

OTF's kits are annotated and predictable: every pattern is explicit, conventions are green-lit for extension, and AI rules act as guide rails.

// routes/teams.tsx
import { requireAuth } from "@/lib/auth"; // agent can see and reuse

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

Primitives are always in one place, named the same on web and mobile. The agent supports reuse:

// components/TeamForm.tsx
import { Button, Input } from "@otfdashkit/ui";
Enter fullscreen mode Exit fullscreen mode

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

6. “Add a screen”: the full loop (not a pipe dream)

  • Prompt: Write “Add a TeamSettings screen for team owners, save notificationPrefs (json) on Team.”

  • Agent: Reads existing Team files, sees CRUD, notices Team is linked to User, extends the schema:

    model Team {
  id                 String   @id @default(uuid())
  name               String
  createdAt          DateTime @default(now())
  users              User[]   @relation("UserTeams")
  notificationPrefs  Json?
}

  • Adds a file: routes/teams/settings.tsx

  • Generates components/TeamSettingsForm.tsx

  • Wires up the route only for logged-in users with role: "owner"

  • Integrates with form validation and uses kit components

All without leaving the IDE. Every step is visible, editable, and sticks to existing patterns.

7. The durable layer: always your repo, always one API

Every tool churns — model IDs, agent wrappers, prompt frameworks. The OTF thesis: your actual working loop is the kit that encodes structure, patterns, and “how it hangs together”.

  • AI runs on top: swap Claude for GPT-4o, or your preferred agent. The glue (CLAUDE.md, .cursorrules) works regardless.
  • The core remains the kit: You own the repo, patterns, and code. No lock-in.
  • When a new surface arrives (OpenRouter, Cursor’s Matrix, Lovable), the agent runs over the kit, not the other way around.

Every OTF SaaS kit ships with CLAUDE.md, .cursorrules, and 20+ scenario prompts. No more “regenerate from scratch.” You prompt, you extend, you ship.

What this enables

  • 1. Zero-context-switch shipping: From idea to change in one loop, always in the IDE.
  • 2. Diffable, testable changes: All code is surfaced as PR/staged changes before merge. No more black-box codegen.
  • 3. Reuse: Existing auth, billing, and routes are extended, never stomped. Every new feature is a first-class citizen of the repo.
  • 4. One contract: Any AI model, any editor, same workflow, because the real contract is readable, extensible code.

Stay in your zone — prompt, extend, ship. With OTF kits, adding a new entity or screen is no longer a context break or a regen-panic: it's just the next prompt. No browser, no stray gen script, no fighting drift. The repo is yours. The agent’s just your extra set of hands.

Top comments (0)