30 Best Replit Prompts for Building Real Apps

<context> App idea: [YOUR APP IDEA] Primary user: [WHO USES THIS] Core job-to-be-done: [THE ONE THING IT MUST DO WELL] Stack preference: [e.g. React + Node/Express + Postgres, or let Agent choose] </context> <task> Build a working web app for the idea above. Before writing code, restate the plan in 3-5 bullets, then proceed. 1. Define the data model: list every table/collection, its fields, types, and relationships. 2. Build the backend: REST endpoints for each core entity (create, read, update, delete) with input validation. 3. Build the frontend: a clean, responsive UI with pages for the main user flow described above. 4. Wire frontend to backend; handle loading and error states. 5. Seed the database with 5-10 realistic sample records so the app is demoable immediately. 6. Run the app, fix any startup errors, and tell me the exact URL and what to click first. </task>

<context> Product: [YOUR APP IDEA] Target visitor: [WHO] Desired action: collect email signups for a waitlist Brand vibe: [e.g. clean and modern, playful, enterprise] </context> <task> Build a single-page marketing site that converts visitors into waitlist signups. 1. Hero section: headline, one-line subheadline, and an email capture form. 2. Three benefit sections with icons and short copy explaining the value. 3. Store submitted emails in a database table with timestamp and basic dedupe on email. 4. Show a success state after submit and validate the email format client- and server-side. 5. Make it fully responsive and add a simple admin route to view captured emails. 6. Deploy it and give me the public URL. </task>

<context> App idea: [YOUR APP IDEA] Users need accounts: yes What each logged-in user should see: [DESCRIBE THE DASHBOARD] </context> <task> Build a web app with user accounts and a private dashboard. 1. Implement email + password signup and login with hashed passwords and session handling. 2. Protect dashboard routes so only authenticated users can access their own data. 3. Scope all data per user — user A must never see user B's records. 4. Build the dashboard UI showing the data described above, with empty states for new users. 5. Add logout and a basic account settings page. 6. Confirm the security model by walking me through how data is isolated per user. </task>

<context> App idea: [YOUR APP IDEA] Main record type: [e.g. tasks, clients, recipes] Fields users care about: [LIST KEY FIELDS] </context> <task> Build a CRUD app for managing the records above with great browsing. 1. Create the data model and CRUD endpoints for the main record type. 2. Build a list view with a search box that filters by [KEY FIELD] in real time. 3. Add filter controls (dropdowns or chips) for [FILTER FIELDS] and sortable columns. 4. Add create and edit forms in a modal, with validation and inline error messages. 5. Add pagination for when the list grows past 25 items. 6. Seed 20 sample records and confirm search, filter, and sort all work. </task>

<context> App idea: [YOUR APP IDEA] Data the API should expose: [DESCRIBE THE RESOURCES] Who consumes it: a frontend in this same project plus external developers </context> <task> Build a documented JSON API and a frontend that consumes it. 1. Design RESTful endpoints for the resources above with sensible status codes and JSON shapes. 2. Add request validation and consistent error responses. 3. Generate simple API docs (endpoints, params, example requests and responses). 4. Build a frontend page that fetches from the API and displays the data cleanly. 5. Add basic rate limiting and an API key check for write endpoints. 6. Run it and give me a sample curl command I can paste to test each endpoint. </task>

<context> What the team manages: [YOUR APP IDEA / DATA] Who uses it: internal team members only Key actions they perform daily: [LIST ACTIONS] </context> <task> Build an internal admin tool for the team. 1. Create the data model for the records the team manages. 2. Build a table view with inline editing, bulk select, and a quick-add form. 3. Add the daily actions above as one-click buttons with confirmation for destructive ones. 4. Add a simple shared password gate so only the team can access it. 5. Add an activity log showing who changed what and when. 6. Seed realistic sample data and confirm the core daily workflow takes under five clicks. </task>

<context> Data source: [CSV UPLOAD / DATABASE TABLE / API] Metrics that matter: [LIST 3-5 KPIs] Audience: [e.g. founders, ops team] </context> <task> Build a metrics dashboard from the data source above. 1. Ingest the data source and store it in a queryable table. 2. Compute the KPIs listed above with clearly defined formulas — show me the formulas first. 3. Display each KPI as a scorecard with the current value and change vs. the prior period. 4. Add 2-3 charts (trend line, breakdown by category) using a charting library. 5. Add a date-range filter that updates all cards and charts. 6. Make it readable on a TV screen and refresh data on page load. </task>

<context> What the CSV contains: [DESCRIBE COLUMNS] Problems in the data: [e.g. duplicate rows, messy dates, missing values] Desired output: [CLEANED TABLE / EXPORTED CSV] </context> <task> Build a tool that imports a CSV, cleans it, and lets me export the result. 1. Add a file upload that parses the CSV and previews the first 10 rows. 2. Detect and report data issues: duplicates, invalid dates, empty required fields. 3. Apply cleaning rules for the problems listed above and show a before/after count. 4. Let me review and approve changes before they apply. 5. Save the cleaned data to a table and add a one-click export to CSV. 6. Handle large files gracefully and show progress for files over 1,000 rows. </task>

<context> What gets approved: [e.g. expense requests, content, time off] Requester role and approver role: [DESCRIBE] Approval steps: [SINGLE APPROVER / MULTI-STEP] </context> <task> Build an internal approval workflow tool. 1. Create a form for requesters to submit items with the relevant fields. 2. Model request states: pending, approved, rejected, with timestamps and reasons. 3. Build an approver queue showing pending items with approve/reject buttons and a comment field. 4. Implement the approval steps above, advancing the state correctly at each stage. 5. Notify the requester of status changes (in-app banner is fine). 6. Add a filterable history view of all past requests and their outcomes. </task>

<context> What knowledge to store: [e.g. SOPs, FAQs, runbooks] Who writes vs. who reads: [DESCRIBE ROLES] </context> <task> Build a searchable internal knowledge base. 1. Create articles with title, body (markdown), tags, and last-updated date. 2. Build a browse view organized by tag and a full-text search across titles and bodies. 3. Add a markdown editor for writers with live preview. 4. Add a role gate so readers cannot edit and writers can create or update articles. 5. Show the 5 most recently updated articles on the home page. 6. Seed 6 example articles and confirm search returns relevant results. </task>

<context> Data source to poll: [API URL / RSS FEED / WEBSITE] How often: [e.g. every hour] What to keep: [FIELDS YOU CARE ABOUT] </context> <task> Build an automation that fetches data on a schedule and stores it. 1. Write a function that fetches from the source above and parses out the fields I care about. 2. Store each fetch in a table, deduping so repeated runs do not create duplicate rows. 3. Run it on the schedule above using Replit's scheduling, and log each run's result. 4. Add a simple page that shows the latest fetched data and the last run time. 5. Handle source downtime gracefully — retry once, then log a clear error. 6. Tell me how to confirm the scheduled job is actually running. </task>

<context> Who sends the webhook: [e.g. Stripe, Typeform, a partner app] Event payload shape: [PASTE A SAMPLE PAYLOAD OR DESCRIBE IT] What should happen on receipt: [THE ACTION] </context> <task> Build a webhook endpoint that reacts to incoming events. 1. Create a POST endpoint that accepts the payload above and validates a shared secret or signature. 2. Parse the relevant fields and store the raw event for auditing. 3. Perform the action described above (e.g. update a record, send a notification). 4. Return the correct status codes so the sender knows it succeeded. 5. Make the handler idempotent so retried events do not double-process. 6. Add a debug page listing the last 20 received events with their processing status. </task>

<context> Trigger: [WHAT EVENT FIRES A NOTIFICATION] Channel: [EMAIL / SLACK / BOTH] Who gets notified: [RECIPIENTS] </context> <task> Build an automation that sends notifications when something happens. 1. Detect the trigger above (a new record, a threshold crossed, a scheduled time). 2. Compose a clear message including the relevant details and a link if applicable. 3. Send via the channel above using a Replit secret for the API key — never hardcode it. 4. Throttle so the same event does not notify more than once. 5. Log every send (recipient, time, success/failure) to a table. 6. Add a test button that sends a sample notification to verify the wiring. </task>

<context> Source system: [APP A AND ITS API] Destination system: [APP B AND ITS API] What to sync and direction: [e.g. new contacts A to B, one-way] </context> <task> Build a sync between the two systems above. 1. Authenticate to both systems using secrets and confirm you can read from A and write to B. 2. Map fields from A's format to B's format — show me the field mapping first. 3. On a schedule, pull new/changed records from A and upsert them into B. 4. Track sync state so you only process records since the last successful run. 5. Log conflicts and errors without crashing the whole run. 6. Add a manual sync button and a status page showing last sync time and record counts. </task>

<context> Data to report on: [SOURCE TABLE / API] Report contents: [METRICS, TABLES, SUMMARY] When and to whom: [e.g. every Monday 9am to the team] </context> <task> Build an automation that generates and sends a recurring report. 1. Query the data above and compute the metrics for the reporting period. 2. Generate a clean report (HTML email body or a shareable page) with tables and a short summary. 3. Schedule it for the cadence above and deliver it to the recipients. 4. Include a period-over-period comparison so trends are visible. 5. Archive each generated report so past reports stay viewable. 6. Send me one test report now so I can confirm the format and numbers. </task>