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

> Extend your SaaS app smoothly inside your IDE with OTF’s kit-aware AI prompts—no regeneration, just focused coding.
> By Dave · 2026-06-07
> Source: https://otf-kit.dev/blog/ship-saas-without-leaving-ide

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:

```md
# 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.
```

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:

    ```prisma
    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.**



![scene — a VS Code window, left: a diffs sidebar showing only the new Team files/components](https://cdn.otf-kit.dev/blog/ship-saas-without-leaving-ide/inline-1.png)



---

## 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.

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

export default async function TeamsPage() {
  await requireAuth();
  // Render teams...
}
```
Primitives are always in one place, named the same on web and mobile. The agent supports reuse:

```tsx
// components/TeamForm.tsx
import { Button, Input } from "@otfdashkit/ui";
```

**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:

    ```prisma
    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.