Building a SaaS MVP with Antigravity: A 90-Day Roadmap from Idea to First Revenue

Phase 2: Technical Foundation (Days 15–30)

Choosing Your Tech Stack

For an MVP, the right question isn't "what's the best tech stack?" — it's "what stack lets me ship fastest while remaining maintainable?" Here's the Antigravity-optimal stack for 2026 that hits both criteria:

Full-Stack Framework

• Next.js 15 (App Router) + TypeScript: Excellent for full-stack SaaS; seamless API routes and Server Actions
• shadcn/ui + Tailwind CSS v4: High-quality components with zero design overhead
• Cloudflare Pages + Workers: Global edge deployment, generous free tier, excellent DX

Database and Authentication

• Supabase: PostgreSQL + real-time subscriptions + built-in auth + storage in one platform — ideal for rapid MVP development
• Alternatively: Neon (serverless Postgres) + Clerk (auth) for teams that want more separation
• Row Level Security (RLS) in Supabase eliminates entire categories of security bugs

Payments

• Stripe: The industry standard, with excellent documentation and an Antigravity-friendly API

Set this stack in your Antigravity project context file so that every implementation suggestion aligns with these choices automatically.

Days 15–17: Project Bootstrap and Context Configuration

# Run in Antigravity's terminal
npx create-next-app@latest my-saas --typescript --tailwind --app --src-dir
cd my-saas
npx shadcn@latest init
npm install @supabase/supabase-js @supabase/ssr stripe

After project creation, the highest-leverage action you can take is asking Antigravity to help you craft a comprehensive AGENTS.md file. This file acts as your project's constitution — it tells Antigravity everything it needs to know about your SaaS to give consistently relevant suggestions:

# AGENTS.md
## Project Overview
[SaaS Name] is a [category] tool for [target user] that solves [problem].
The primary value proposition: [one sentence that captures what makes this special].
 
## Business Context
- Subscription plans: Free (3 projects, 30-day history) / Pro ($9.99/month, unlimited)
- Current phase: MVP development — prioritize shipping over perfection
- Success metric for MVP: 10 paying customers within 90 days of launch
 
## Tech Stack
- Next.js 15 App Router + TypeScript (strict mode)
- Supabase (PostgreSQL + Auth + Storage)
- Stripe (subscriptions + customer portal)
- Cloudflare Pages + Workers (deployment)
- shadcn/ui + Tailwind CSS v4
 
## Code Conventions
- All server data fetching via Server Components or Server Actions
- Client Components only when interactivity requires it
- Zod schemas for all API inputs and environment variables
- Error boundaries at route segment level
- No any types — use unknown and type guards
 
## Security Requirements
- All database operations require authenticated user context
- RLS policies on every table — no exceptions
- Stripe webhook signatures must be verified before processing
- Environment variables never exposed to client components

With this AGENTS.md, every Antigravity conversation starts with full project context — which means less back-and-forth and more immediately usable code.

Days 18–22: Authentication Implementation

A full auth implementation used to be one of the most time-consuming parts of building a SaaS. With Antigravity and Supabase, it's now a half-day task.

Implement complete authentication for Next.js 15 App Router + Supabase SSR.
Requirements:
- Google OAuth + email/password login
- Middleware-based route protection (dashboard/* requires auth, / is public)
- Redirect to /dashboard after successful login
- Redirect to /login when unauthenticated users try to access protected routes
- Typed session helper for Server Components
- TypeScript strict mode throughout

Antigravity generates a production-ready implementation covering the Supabase SSR client setup, middleware configuration, login UI with shadcn/ui components, and typed auth helpers for Server Components. What would have taken two days is done in an afternoon.

Days 23–30: Data Model and Core CRUD

Spend these days designing your core data model and implementing the CRUD operations for your main entity. Invest time up front in the data model — changing it later is the most disruptive type of refactor.

-- Ask Antigravity: "Based on these user stories [paste stories],
-- design a PostgreSQL schema for Supabase with proper RLS"
 
create table public.projects (
  id uuid default gen_random_uuid() primary key,
  user_id uuid references auth.users not null,
  name text not null,
  description text,
  status text default 'active' check (status in ('active', 'archived', 'completed')),
  settings jsonb default '{}',
  created_at timestamptz default now(),
  updated_at timestamptz default now()
);
 
-- Automated updated_at
create or replace function update_updated_at()
returns trigger as $$
begin
  new.updated_at = now();
  return new;
end;
$$ language plpgsql;
 
create trigger update_projects_updated_at
  before update on public.projects
  for each row execute function update_updated_at();
 
-- Row Level Security — no exceptions
alter table public.projects enable row level security;
 
create policy "Users own their projects"
  on public.projects for all
  using (auth.uid() = user_id)
  with check (auth.uid() = user_id);

Antigravity generates these schemas from natural language requirements. Your job is to verify that the RLS policies accurately reflect your access control requirements — this is security-critical and requires your attention, not just trust in generated code.

Phase 3: Core Feature Implementation (Days 31–60)

The Antigravity Development Loop

This phase is where Antigravity's leverage is highest. The key is establishing an efficient development loop that minimizes wasted effort. Here's the pattern that works:

Step 1 — Plan before coding:

I'm implementing [feature]. Before writing any code:
1. List all files that will be created or modified
2. Describe the implementation in ordered steps
3. Identify edge cases and error scenarios to handle
4. Propose a testing approach

Don't write any code yet — confirm the plan with me first.

This step takes about five minutes and prevents the specific failure where you discover a mistaken assumption about scope halfway through the implementation. I have not instrumented it carefully enough to quote a reduction percentage, so treat it as an operating rule — always stop once before you start — rather than a measured number.

Step 2 — Implement incrementally:

Once the plan is confirmed, implement one step at a time. After each step, verify the code works before moving to the next. Never ask Antigravity to implement an entire feature in a single response — the smaller the increment, the higher the quality.

Step 3 — Fix errors immediately:

When something breaks, paste the complete error message and relevant code into Antigravity without editing it. Incomplete error information leads to incomplete fixes. Antigravity's root-cause analysis will often catch secondary issues that would have caused the next bug, effectively making your debugging compounding.

Prioritizing Features for Your MVP

The most important discipline during this phase is ruthless scope management. Here's the framework:

MUST (required to launch — nothing else matters until these work):

• User authentication and profile management
• Core CRUD operations for your primary entity
• Basic dashboard with a useful default view
• Working Stripe subscription (implemented in the next phase)

SHOULD (aim to include in v1.0, but won't block launch):

• Email notifications for important events
• Data export (CSV or similar)
• Basic usage analytics for users
• Search and filtering improvements

NICE TO HAVE (v2 roadmap — document it, don't build it now):

• Team/organization support
• Public API with key management
• Advanced reporting and dashboards
• Third-party integrations

Here's the critical insight: because Antigravity lets you build faster, the temptation to add SHOULD and NICE TO HAVE features into your MVP is stronger than ever. You can implement something in two hours that would have taken two days. The discipline to say "that's v2" is harder when building it feels effortless.

Protect your scope by making it public. Write your MVP scope in a README. Tell people on Twitter what you're not building. The accountability helps.

Days 45–55: UI Polish and Responsive Design

Antigravity's multimodal capabilities transform UI polish from a painful iteration cycle into a fast feedback loop. Take a screenshot of any screen, paste it alongside the relevant component code, and describe what you want to improve:

See this screenshot [attached] of my dashboard. Issues to fix:
1. The data table overflows its container on mobile — needs horizontal scroll or card layout
2. In dark mode, the chart colors are nearly invisible against the background
3. Empty state (no projects yet) needs a more helpful prompt with a clear CTA
4. Loading skeleton is missing — show a shimmer effect while data fetches

Use shadcn/ui components wherever possible. Keep the existing color scheme.

Antigravity generates targeted fixes for each issue, explained clearly enough that you understand what changed and why.

Phase 4: Stripe Billing Integration (Days 56–70)

Overall Billing Architecture

Stripe integration is the point where many indie developers stall — the combination of webhooks, idempotency, subscription state management, and security requirements feels daunting. With Antigravity, it's a structured implementation problem, not a scary unknown.

Request the complete billing flow from Antigravity:

Implement a complete subscription billing system for Next.js 15 + Stripe + Supabase:

1. Checkout session creation endpoint (/api/checkout) that creates a Stripe session
   and associates it with the authenticated user's Supabase account
2. Webhook handler (/api/webhooks/stripe) that:
   - Verifies the Stripe signature before processing
   - Handles: subscription.created, subscription.updated, subscription.deleted,
     checkout.session.completed, invoice.payment_failed
   - Syncs subscription state to a `subscriptions` table in Supabase
3. Customer portal redirect endpoint (/api/portal) for plan changes and cancellation
4. A useSubscription() hook that reads current subscription status for UI feature gating
5. A SubscriptionGate component that conditionally renders content based on plan

Use TypeScript + Stripe SDK v16. Include error handling and logging.

Critical Implementation: Webhook Handler

// src/app/api/webhooks/stripe/route.ts
import { stripe } from '@/lib/stripe';
import { createClient } from '@/lib/supabase/server';
import { headers } from 'next/headers';
 
export async function POST(req: Request) {
  const body = await req.text();
  const headersList = await headers();
  const signature = headersList.get('stripe-signature') ?? '';
 
  let event;
  try {
    event = stripe.webhooks.constructEvent(
      body,
      signature,
      process.env.STRIPE_WEBHOOK_SECRET!
    );
  } catch (err) {
    console.error('Webhook signature verification failed:', err);
    return new Response(`Webhook Error: ${err}`, { status: 400 });
  }
 
  const supabase = await createClient();
 
  switch (event.type) {
    case 'customer.subscription.created':
    case 'customer.subscription.updated': {
      const subscription = event.data.object;
      const customerId = subscription.customer as string;
 
      // Find the user associated with this Stripe customer
      const { data: profile } = await supabase
        .from('profiles')
        .select('id')
        .eq('stripe_customer_id', customerId)
        .single();
 
      if (profile) {
        await supabase.from('subscriptions').upsert({
          user_id: profile.id,
          stripe_subscription_id: subscription.id,
          stripe_customer_id: customerId,
          status: subscription.status,
          price_id: subscription.items.data[0].price.id,
          current_period_start: new Date(
            subscription.current_period_start * 1000
          ).toISOString(),
          // Where the period end lives can move between API versions.
          // Log the raw subscription object once before locking this in.
          current_period_end: new Date(
            subscription.current_period_end * 1000
          ).toISOString(),
          cancel_at_period_end: subscription.cancel_at_period_end,
        });
      }
      break;
    }
 
    case 'customer.subscription.deleted': {
      const subscription = event.data.object;
      await supabase
        .from('subscriptions')
        .update({ status: 'canceled' })
        .eq('stripe_subscription_id', subscription.id);
      break;
    }
 
    case 'invoice.payment_failed': {
      const invoice = event.data.object;
      // Notify the user and update subscription status
      console.error('Payment failed for customer:', invoice.customer);
      break;
    }
  }
 
  return new Response(null, { status: 200 });
}

When Webhooks Process Nothing At All

The most common way billing fails is the way that produces no error at all. The UI works. Checkout completes. Stripe shows the subscription. Only your subscriptions table stays empty.

The leading cause is reading the wrong header during signature verification. Stripe sends the signature in stripe-signature, but the secret used to verify it lives in an environment variable named STRIPE_WEBHOOK_SECRET — so the header name gets typed as stripe-webhook-secret. Reading a header that does not exist yields an empty string, constructEvent throws every time, and the handler returns 400 for every event Stripe sends.

To see exactly how absolute that failure is, I reproduced Stripe's signature scheme (t=<unix timestamp>,v1=<HMAC-SHA256(timestamp + "." + raw body)>) in isolation:

// verify-header-name.mjs — how much the header name actually matters
import crypto from 'node:crypto';
 
const secret = 'whsec_test_dummy_value';
const payload = JSON.stringify({ id: 'evt_1', type: 'customer.subscription.created' });
const ts = Math.floor(Date.now() / 1000);
const sig = crypto.createHmac('sha256', secret).update(`${ts}.${payload}`).digest('hex');
 
// The header Stripe actually sends
const headers = new Headers({ 'stripe-signature': `t=${ts},v1=${sig}` });
 
function verify(raw, header, secret) {
  if (!header) throw new Error('No signatures found matching the expected signature for payload.');
  const parts = Object.fromEntries(header.split(',').map((p) => p.split('=')));
  const expected = crypto.createHmac('sha256', secret).update(`${parts.t}.${raw}`).digest('hex');
  if (expected !== parts.v1) throw new Error('signature mismatch');
  return JSON.parse(raw);
}
 
for (const name of ['stripe-webhook-secret', 'stripe-signature']) {
  const h = headers.get(name) ?? '';
  try {
    console.log(name, '->', verify(payload, h, secret).type);
  } catch (e) {
    console.log(name, '-> THROW:', e.message);
  }
}

Output on Node.js v22:

stripe-webhook-secret -> THROW: No signatures found matching the expected signature for payload.
stripe-signature -> customer.subscription.created

The wrong name fails 100% of the time. Which is useful: if your Stripe event log shows an endpoint returning 400 across the board, check one line before you start suspecting the network or the database.

Three things are worth confirming by eye before you take billing live:

The second row catches people most often. The App Router makes req.json() available and convenient, so parsing first feels natural. But the HMAC is computed over bytes, and turning the payload into an object and back into a string can change key order or whitespace enough to break the match. Capture the raw body first, verify it, and take your parsed object from the verified event.

Testing webhooks locally is non-negotiable before going to production:

# Install Stripe CLI
brew install stripe/stripe-cli/stripe
 
# Authenticate and forward webhooks to your local server
stripe login
stripe listen --forward-to localhost:3000/api/webhooks/stripe
 
# In another terminal, trigger a test event
stripe trigger customer.subscription.created

Never test webhooks only in production. The Stripe CLI makes local testing reliable and fast.

Pricing Strategy for Indie SaaS

Your free plan should be designed to be valuable enough to attract users but limited enough to create upgrade motivation. The most common mistake is making the free plan so generous that there's no reason to upgrade.

A proven framework for indie SaaS pricing:

• Free: Core functionality with meaningful limits (e.g., 3 projects, 30-day history, no export, basic support)
• Pro ($9.99–$19.99/month): Full access, priority support, advanced features, higher limits
• Team ($29.99–$49.99/month): Everything in Pro, plus multi-user, admin dashboard, team analytics

Price to the value delivered, not to your costs. If your tool saves someone $500/month of effort or generates $500/month of additional revenue, charging $49.99/month is a steal for them.

Phase 5: Beta Launch and First Revenue (Days 71–90)

Building a High-Converting Landing Page

Your landing page has one job: convert a skeptical visitor into a free trial user. Antigravity can generate a strong foundation:

Create a high-converting SaaS landing page in Next.js + Tailwind CSS + shadcn/ui.

Product: [name] — [one-line description]
Target: [specific role] at [company type/size]
Core problem it solves: [description]
Key benefits (not features): [B1], [B2], [B3]
Social proof available: [testimonials, logos, user counts if any]
Pricing: Free forever / Pro $9.99/month

Page structure:
- Hero: headline, subheadline, primary CTA, product screenshot
- Problem section: acknowledge the pain your users feel today
- Solution section: show how you solve it (benefits, not feature list)
- Feature highlights: 3 specific features with visuals
- Social proof: testimonials or usage metrics
- Pricing: clear plan comparison
- FAQ: address the top 5 objections
- Final CTA: low-friction sign-up prompt

Focus the copy on outcomes, not features. "Close 40% more deals" resonates more than "advanced CRM features."

Deployment to Cloudflare Pages

For production, Cloudflare Workers is the natural choice if you want edge execution, and Vercel is the path of least resistance if you want every Next.js feature to work untouched. Either way, the first thing that breaks is an environment variable that exists locally and not in production. Before you deploy, walk your platform's environment settings and confirm each value individually: the Stripe secret key, the webhook signing secret, the Supabase URL, and the service role key.

User Acquisition: What Actually Works for Indie SaaS

1. Warm outreach to validation participants

The people who gave you feedback during validation are your most likely first customers. Reach out personally when you launch. They already understand the problem you're solving.

2. Community participation

Join the online communities where your target users spend time: relevant Subreddits, Discord servers, Slack workspaces, LinkedIn groups. The key is to become a genuinely helpful participant for 2–4 weeks before mentioning your product. People can smell promotional intent instantly; authentic contribution builds real trust.

3. Product Hunt launch

Use Antigravity to prepare everything in advance: your Product Hunt listing copy, your maker post, a set of thoughtful comment response templates for common questions, and a launch day announcement for your email list and social channels. Preparation is the difference between a 100-upvote launch and a 1,000-upvote one.

4. Personal outreach at scale

Use Antigravity to research and personalize cold outreach emails at scale. The format: one sentence about something specific to them, one sentence connecting their situation to the problem you solve, one sentence about your product, and a single low-friction ask (a 15-minute call, or a free trial invitation). Generic email blasts don't work — personalized notes do.

5. Content that ranks

Antigravity can consistently produce high-quality SEO content targeting "how to [do the thing your SaaS does]" queries. Start with 4 articles per month, measure which keywords generate signups (not just traffic), and double down on those. Organic search has the best CAC of any channel for indie SaaS — it just takes time to compound.

Days 80–90: Feedback Analysis and Rapid Iteration

Use Antigravity to make sense of early user feedback systematically:

I have the following user feedback from my first 30 users [paste all feedback].
Please analyze it and provide:
1. Top 3 themes that appear across multiple users
2. Features users mention most positively (don't remove these)
3. The single highest-impact improvement for reducing churn
4. Verbatim quotes that best capture the core value users are experiencing
5. Suggested priority order for the next two-week sprint

The output from this analysis becomes the input to your next sprint planning. Antigravity is fast enough to help you analyze feedback from 50 users in 10 minutes — close the loop between user signals and product decisions as tightly as possible.

Common Failure Patterns and How Antigravity Helps You Avoid Them

Failure 1: Scope Creep Accelerated by Antigravity's Speed

Because Antigravity makes implementation so fast, the temptation to "just add one more thing" is stronger than ever. A feature that would have taken a week to consider and reject (because of implementation cost) now costs only 2 hours — so the mental barrier to adding it disappears.

The fix: make your scope commitment public. Write your MVP feature list in your README. Tweet "I'm not building [feature] until I have 100 paying customers." Give your future self fewer opportunities to rationalize scope additions.

Failure 2: Chasing Code Perfection Before Shipping

Endless cycles of asking Antigravity to refactor, optimize, and improve code before launch is one of the most seductive traps in AI-assisted development. There's always a better way to write something — but a launch delayed by perfect code helps no one.

The rule: apply rigorous review only to security-critical paths (auth, billing webhooks, data access). For everything else, the bar is "does it work correctly and won't create production incidents" — not "is it the most elegant possible implementation."

Failure 3: Trusting Generated Code Without Verification

Antigravity's code is excellent by default — but you're the one responsible for it running in production. Three areas where you should always review manually:

• RLS policies: Verify that every path to access data requires authentication and that users can only see their own data
• API key and secret handling: Ensure sensitive values are only accessed in server contexts, never exposed to the client
• Webhook validation: Confirm that Stripe webhook signatures are verified before any business logic runs

These reviews take 15 minutes each and prevent catastrophic security incidents.

Failure 4: Ignoring Churn Signals Until It's Too Late

First-month churn rates above 20% in a SaaS indicate a serious problem with product-market fit, onboarding, or perceived value. Use Antigravity to draft short, direct email surveys to users who haven't logged in within 14 days. Understanding why people leave is often more valuable than understanding why people stay.

What to Expect After 90 Days

With disciplined execution of this roadmap, here's a realistic picture of Day 90:

• Product: A functional MVP live on Cloudflare Pages with core features working reliably
• Users: 20–50 beta users, 100+ free-plan registrations
• Revenue: At 5–10% paid conversion, $1,000–$5,000 MRR (depending on pricing)
• Learning: A clear, evidence-based roadmap for the next 90 days, grounded in real user feedback

First revenue doesn't need to be large. What matters is that you've proven paying customers exist, understood what they value most, and built the foundation for sustainable growth.

For advanced revenue automation strategies once you're post-MVP, see the Complete AI Revenue Automation Playbook. For production-grade Supabase architecture as you scale beyond MVP, the Supabase Complete Production Guide has everything you need.

Summary

Here's the 90-day SaaS MVP roadmap in brief:

• Days 1–14 (Validation): Define the problem precisely, confirm willingness to pay, scope your MVP, and build a prototype that generates real feedback
• Days 15–30 (Foundation): Select your tech stack, configure Antigravity's project context, implement authentication and your core data model
• Days 31–60 (Implementation): Build core features with a plan-first development loop, maintain rigorous scope discipline, polish the UI
• Days 56–70 (Billing): Integrate Stripe subscriptions and customer portal with proper webhook handling
• Days 71–90 (Launch): Build a converting landing page, deploy to production, pursue multiple user acquisition channels, analyze feedback and iterate

What Antigravity shortens is implementation time, not the judgment about what to build and who to build it for. That part stays yours, and keeping it is what makes the rest go faster. Use the speed to run more experiments, not to pack more features into each one.

The expensive mistakes across ninety days are rarely the architectural ones. They look like the stripe-signature line above: small, invisible while the UI keeps working, and capable of costing weeks. Around billing especially, run the generated code yourself once before it reaches production.

For a concrete next step, do only Days 1–3 of Phase 1. Write no code and find ten people who say they would pay to have this problem solved. If you cannot fill that list, the remaining eighty-seven days of implementation sit on an untested assumption.