Vibewright

The expertise you need. The attitude you want.

The expertise you need. The attitude you want.

Before you vibe-code: plan your app's architecture and data model in one page

AI coding tools are fast. That's the problem. Ask for "a SaaS app with teams and billing" and you'll have screens in an afternoon, plus a database shape nobody chose, three different ways of reading the same table, and a payment status that lives in the browser. A week later every new feature breaks an old one.

The fix isn't to slow down. It's to spend one sitting on a one-page plan before the first prompt, so your coding agent builds into a shape you picked. This guide walks through the method built into Vibewright's Vibe-Coding Tech Lead · App Architect builds, which are live now. It works whether you build in Cursor, Claude Code, GitHub Copilot, Replit, Lovable, Bolt or v0.

Step 1: write down what the app actually is

Before any stack talk, answer five things in plain words:

  1. Users: who signs in, and do they belong to a team or company?
  2. Core flows: the three to five things a user must be able to do. Not twenty. Five.
  3. Data: the nouns those flows create and change.
  4. Integrations: payments, email, AI models, anything third-party.
  5. Scale: a realistic guess for the next 12 months, not your dream number.

Anything that isn't on this list goes in a "non-goals" line. That line is what stops your coding agent from helpfully adding a notifications system nobody asked for.

Step 2: pick boring defaults

The App Architect builds start every MVP from the same proven defaults and only move off them for a stated reason:

Write one line per choice saying why, and one alternative you considered. If two options are close, score them on fit for your skills, how well your AI tool handles them, cost at your expected scale, lock-in and ecosystem, then pick one and move on.

Step 3: design the data model first

The data model is the hardest thing to change later, so it gets the most care. The rules the builds follow:

Then walk your three core flows through the schema on paper. "User creates a project, invites a teammate, teammate edits it." If a flow needs a column or table that isn't there, you just found a bug before writing any code.

Step 4: decide tenant isolation now

If users belong to teams or companies, put tenant_id (or org_id) on every table a tenant owns, and enforce isolation in one place: either in the database with row-level security or in a single data-access layer. Bolting this on after launch is one of the most painful rewrites there is.

If you use Supabase, its row-level security docs are clear on the stakes: a table in an exposed schema without RLS is readable and writable by any role with a grant on it. Enable RLS on every exposed table, set grants to only what each role needs, write a policy per operation, and keep the service_role or secret key on the server. Our pre-launch security checklist covers the rest.

Step 5: sketch it and record the hard decisions

Draw the app as a simple text diagram: client, then API, then database and outside services. Then write your first three Architecture Decision Records. An ADR is a short markdown file per decision with the context, the decision, the alternatives, the consequences and the date, kept in docs/adr/. Good first three: the database, the auth provider, and how tenants are isolated.

ADRs aren't paperwork. They're how future you, and every future AI session, learns why the app is shaped the way it is instead of "fixing" it back into a mess.

Step 6: hand the plan to your coding agent

Turn the plan into conventions your tool reads every session. In Cursor, that's a project rule in .cursor/rules (rule files there use the .mdc extension) or a plain AGENTS.md in the project root, per Cursor's rules docs. Claude Code reads a CLAUDE.md file. Put the stack, the data-model rules, the tenant rule and "read docs/adr before changing the schema" in it.

Then break the build into 5 to 15 small tasks, each testable in one sitting, and give each one a prompt with context, files to touch, acceptance criteria and a "don't touch" list.

Step 7: plan for the next stage only

The builds think in four stages: a prototype on one server and one database; paying users, which adds backups, monitoring, staging and indexes; growth, which adds caching, queues, read replicas and rate limits; and scale, where services split because load or team size demands it. Build the stage you're in and know what the next one needs. Don't build stage three on day one.

Where the App Architect build fits

Each App Architect build is a ready-to-paste system prompt for Claude Projects, ChatGPT Projects, Gemini, Grok, Cursor and other agent frameworks. Say "run onboarding" and it builds a project profile, then runs workflows for idea-to-architecture, data model design, a stack selection matrix, a refactor plan for AI-generated sprawl, a scale and cost review, and integration design (webhook signatures, idempotency, retries). Every answer ends with an architecture check: does this change fit the design, add coupling or cost, or call for a decision record?

It's guidance, not a certified security audit, and you review and test everything it suggests before production.

Setup guides: Claude Projects, ChatGPT Projects and Gemini Gems and skills. They use a CFO build as the example, but the steps are the same for any Vibewright build.

Then pick the tech lead you'll actually listen to at 1 a.m. The App Architect comes in seven tones: Aggressive (hard deadlines, no excuses), Affirming (earned praise, then the next step), Dry (answer first, numbered steps), Funny (one joke, then the real plan), Sarcastic (wry, fully useful under the snark), Boardroom Professional and Calm Zen. Same method, different voice. See how tones change an agent.

Get the App Architect

Choose your App Architect tone on /pricing · Or grab the free sample

← All guides