Replit for Beginner: create your first app without code

Positioning Replit vs. Lovable, Bolt, v0. Replit's real edge: backend + database + deployment in one browser tab. The two-mode overview: Design Canvas (visual, no backend) and App mode (functional). Honest: where each competitor wins. Why non-technical users are Replit's explicit target audience in 2026.

Free tier reality: 10 Agent checkpoints per month total (not per day), apps sleep after 5 minutes, no custom domains, 1 published app. Core plan: $20–25/month, $20 in credits, always-on hosting, private repos. Realistic course budget: $20–40/month. Why free plan blocks you mid-course. Credit Cost Cheatsheet introduced.

Two Agent modes: Economy (cost-optimised for simple tasks and exploration) and Power (most capable models for complex builds and harder problems). Extended Thinking: an Advanced settings toggle you enable per-request for complex or open-ended problems — not a separate mode, but significantly more expensive. Checkpoint before every risky prompt — live demo of rollback. BYOK (Bring Your Own Key): connect your own Claude API key to reduce costs. The golden rule: one specific change per prompt.

A guided tour of only what matters: Design Canvas board, Agent chat panel, Preview tab, Deployments, database viewer, Secrets (for API keys). A map of where things live — not a feature encyclopaedia.

Two types of validation: demand (does anyone want this?) and product (does this work?). Module 2 = demand. Modules 3–6 = product. For students without an idea: the Idea Starter Kit (30 validated concepts in 6 categories). The one qualifying question: "Who has this problem and would they pay to solve it?" ClientLoop example: consultants pay to avoid the "any update?" email chase.

The most common mistake: building too much. Framework: what is the ONE thing a user must do for this to be worth using? Everything else is v2. Students write their one-feature definition here. ClientLoop: the one feature is "client sees project status and leaves a comment." Nothing else in v1.

Fill in the App Spec Template without using Replit Agent. Define the target user, problem, core action, data stored, required screens, scope limits, and success criteria. Instructor fills it in for ClientLoop, and students fill it in for their own idea. This spec becomes the source material for the first Agent prompt later in the course. No credits required.

Explain when visual planning helps and when it wastes time or credits. Design Canvas is optional and useful for exploring layout, visual direction, and interface structure before building. Figma is optional. Plain text is enough for many simple MVPs. Students decide whether they need a rough visual direction or can proceed with the App Spec only.

Dropbox and Buffer both validated with landing pages before building the product. The goal: 20 real email signups from people you don't know. If you can't get 20, the MVP doesn't matter yet. What a strong validation landing page contains: one problem, one promise, one action. No feature list.

Live build. Instructor builds the ClientLoop landing page in Canvas mode. One hero, one value proposition, one email capture form. Design in Canvas first — get it right before converting. Economy mode throughout. Show checkpoint workflow from the start.

Convert from Canvas to App mode. Connect the signup form to Replit's built-in database. Test: submit a real email, verify it appears in the database viewer. Why owning this data matters vs. depending on Mailchimp or Typeform.

One-click always-on deployment (Core plan required). Custom domain walkthrough. Smoke test: share the URL with someone who has never seen it and confirm it loads on their device. The difference between "preview" and "deployed."

Message 5 people in your network today. What to say. What counts as real validation vs. polite support from friends. What zero signups actually means (the message isn't landing — not that the idea is bad). How to iterate the page copy before building anything else.

PWA: runs in browser, installs on home screen, works on any device, no App Store required. Native: Apple Developer account ($99/year), App Store review, platform-specific UX. For validation PWA wins every time — one build, all devices. iOS limitations: no background sync, limited push notifications — set honest expectations. Native path covered in Bonus Module.

The wrong way: prompt the Agent to "build the whole app" → inconsistent colours, broken layout, hard to iterate. The right way: (1) define design tokens first — brand colour, font, spacing, border radius — in one dedicated prompt; (2) build components one by one (button, card, form, nav); (3) assemble app from components. Every future prompt references these tokens automatically. Demo: setting up ClientLoop's design system before building any feature.

The wrong way: prompt the Agent to "build the whole app" → inconsistent colours, broken layout, hard to iterate. The right way: (1) define design tokens first — brand colour, font, spacing, border radius — in one dedicated prompt; (2) build components one by one (button, card, form, nav); (3) assemble app from components. Every future prompt references these tokens automatically. Demo: setting up ClientLoop's design system before building any feature.

Live build using the App Spec from lesson 1.3. Power mode for the initial scaffold. The skeleton: navigation, screen layout, design tokens applied. Adding Replit's built-in auth: login, signup, protected routes. Test with two browser windows simultaneously. Checkpoint after every working state.

Building the one core user action and persisting it. Viewing real data in the database viewer. The difference between prototype placeholder data and real user data. ClientLoop: project card with status dropdown and client comment, saved and retrieved from database.

Describe what you want, not what's wrong. One change per prompt. Always checkpoint before iterating. Rollback when broken — live demo. When to push through vs. start fresh. Real examples: bad prompt vs. good prompt for the same change. The credit cost difference between efficient and inefficient iteration.

Test on a real phone via QR code. The "Add to Home Screen" moment — this is the demo students show people. Asking the Agent to fix mobile layout issues with specific prompts. Verify PWA install on iOS Safari and Android Chrome. Known iOS limitations: no background sync, limited push notifications.

The most powerful validation signal is payment. Replit has native one-click Stripe integration — the Agent wires up the integration, data models, and sandbox environment automatically. Demo: add a $9/month subscription to ClientLoop. Test with Stripe test card 4242 4242 4242 4242. The mindset shift: "does anyone want this?" vs. "will anyone pay for this?" Even one real payment is more signal than 100 email signups. Switching from sandbox to live keys when ready.

Two integrations every validator needs. Email: transactional email on signup and key events using Resend or SendGrid — both via a single Agent prompt. Google Sheets: sync your database to a Sheet for reporting without building a dashboard. Both done via Agent with API keys stored in Replit Secrets. ClientLoop demo: welcome email on signup + signups logged to a Sheet.

Three things that make a prototype feel credible: consistent colour (tokens from 3.2 handle this), readable typography, no broken states. One polish prompt: 'Apply a final visual consistency pass across all screens.' The rule: fix what distracts, ignore what doesn't matter yet. Do not over-build.

Empty states ('you have no projects yet') are forgotten in most prototypes but matter hugely for beta feedback quality. Error messages that don't say 'undefined'. Prompting the Agent to add them systematically. Then: sign out, create a fresh account, complete the core flow from scratch using the new-user checklist.

Four failure modes with solutions: (1) Agent loops — rollback and rephrase; (2) layout breaks after UI change — always checkpoint before visual changes; (3) database schema mismatch — describe exact field names; (4) auth stops working — separate auth changes from feature changes. Taught from real failures discovered during instructor pre-build.

The 17-point checklist (Resource 03) before sharing with anyone: signup works, core flow completes, data persists, looks right on mobile, Stripe sandbox payment completes, email notification sends, empty states exist, no broken error messages, URL is always-on. Every unchecked box is a bad first impression.

Define the beta hypothesis, target tester profile, core task, success criteria, and what counts as useful signal. Prepare the exact tester scenario before sending the app to anyone. Includes a short final share-link sanity check: deployed URL, core flow, and mobile must work before recruiting.

Where to find testers: personal network, waitlist from Module 2, relevant communities, clients, peers, and niche groups. How to prioritize real target users over polite friends. How to ask without overselling. Copy-paste invitation scripts. What to tell testers and what not to tell them before the test.

How to run a useful beta session or async test. Track whether users complete the core flow, where they get confused, whether they would use it again, and whether payment intent exists. Use Tally, Loom, Google Sheets, or a 15-minute call. Then interpret results: strong signal, weak signal, no signal. Decide whether to iterate, pivot, or stop.

Decision framework for what to do after beta. When staying on Replit is enough: internal tools, early SaaS prototypes, small user bases, ongoing validation, demos, and operational tools. What to harden before inviting more users: deployment type, database persistence, secrets, custom domain, cost limits, monitoring, and basic reliability. When Replit is no longer enough: reliability needs, compliance, scale, team engineering workflow, or cost predictability.

Explain the main next-step paths after strong signal: keep iterating in Replit, migrate parts of the app to tools like Vercel/Railway/Supabase, hand the codebase to developers, rebuild more intentionally, or consider native mobile if the product is truly mobile-first. Native apps and App Store submission are framed as an advanced path, not the default next step.

Recap the full journey: idea → App Spec → waitlist page → MVP → auth/database → mobile/PWA → Stripe sandbox → email/Sheets → polish → beta feedback. Then give a practical next-30-days plan based on signal: strong signal = improve and test payment; weak signal = fix positioning or workflow; no signal = stop or return to problem discovery.