Web app prompt examples: 10 prompts for SaaS, internal tools and client portals
Ten complete prompts for a web app, one paragraph each, ready to paste into an AI app builder. Each names the roles and who sees what, the login, the main list view, the statuses, the emails and the payments, with the follow-up prompts to send next.
Here are 10 web app prompt examples to copy into an AI app builder: three SaaS products, three internal tools, two client portals and two dashboards. Each is one paragraph, ready to send as a first message. Replace the parts in [brackets] and keep the rest. A web app prompt differs from a website prompt in one way above all: it says who logs in, what each role can see and change, and what happens when a record changes status.
The prompts follow the seven blocks (context, goal, users, screens, data, constraints, tone) of our app prompt examples, and add the five lines a web app with real users needs. For an app that lives on a phone, use our mobile app prompt examples instead.
What a web app prompt must say that a website prompt does not
A website shows the same pages to everyone. A web app shows each user their own data, lets some users change it and others only read it, and moves records from one status to the next. Five lines cover the difference:
Line
What to write
Why it matters
Roles and permissions
Each role, and what it can see and change: "a client sees only their own invoices"
Without this sentence, the AI builds one screen that shows every record to every user
Login
Who signs up, how, and who is invited: "email and Google, clients by invitation only"
Open sign-up and invitation-only are two different apps
Main list view
The columns, filters and search of the screen people use all day
In a business app, most of the time is spent in one table
Statuses
The steps a record goes through, in order: "new, in progress, waiting, done"
Statuses drive the filters, the dashboard and the emails
Emails and payments
Which event sends which email, and what is paid, how often
An email without a trigger becomes spam; a price without a rule becomes a bug
The first line is the one people skip, and the one that matters most. Broken access control, where a user can read or change data that is not theirs, sits at the top of the OWASP Top 10 of web application risks. In an app built on Supabase, those rules become row level security policies in the database, as described in Supabase's documentation. A clear sentence in the prompt is what lets the AI write them.
SaaS prompts
A SaaS has customers who sign up on their own, pay a subscription, and each work in their own space. The prompt must say what one account contains, what is free and what is paid, and what the public side shows before sign-up.
Customer feedback board
SaaS · Product
Build a SaaS web app where [software companies] collect feature requests from their users. Roles: workspace owner, team member, end user (votes and comments, no access to the admin side). Login: owners and team members sign up with email or Google; end users sign in with email from the public board. Screens: public board with requests sorted by votes, request detail with comments, public roadmap in three columns, admin list of all requests with filters by status and tag, workspace settings with the board's logo and colour. Data: a workspace has many boards; a request has a title, a description, tags, a vote count and a status (under review, planned, in progress, shipped). Constraints: one vote per end user per request, an email to voters when a request moves to shipped, a free plan with [1 board] and a paid plan at [$19 a month] through Stripe with unlimited boards. Clean style: white, indigo, compact tables.
Applicant tracking for a small agency
SaaS · Recruiting
Build a web app for [a recruitment agency with 8 recruiters] to track candidates. Roles: admin, recruiter, client (sees only the shortlist for their own job openings). Login: staff by email, clients by invitation link. Screens: job openings list, pipeline for one opening as a Kanban board (sourced, screened, interview, offer, hired, rejected), candidate profile with CV upload, notes and history, client view of the shortlist with approve or decline buttons. Data: a client company has many openings; an opening has many applications; an application links a candidate and an opening and has a stage. Constraints: CV files stored privately and visible only to staff and the related client, an email to the recruiter when a client approves a candidate, search by name and skill, import of existing candidates from a CSV file. Professional style: white, dark green, dense lists.
AI meeting notes
SaaS · AI tool
Build a web app for [consulting teams] that turns a meeting transcript into a summary and a task list. Roles: team admin, member. Login: email or Google; the admin invites members. Screens: paste or upload a transcript (text or .vtt file), AI result (summary, decisions, tasks with an owner and a due date) that the user edits before saving, meetings list with search, task list across meetings filtered by owner and status. AI step: the transcript goes to a language model through a server-side function; the API key never reaches the browser; the user always reviews before saving. Data: a team has many meetings; a meeting has a summary and many tasks; a task has an owner, a due date and a status (open, done). Constraints: members see only their team's meetings, a weekly email to each member with their open tasks, [50 meetings a month] on the paid plan. Calm style: off-white, graphite, one teal accent.
Internal tool prompts
An internal tool replaces a spreadsheet that has grown too big. Nobody signs up on their own: the admin invites the team. The prompt spends its words on the main table, the statuses and who is allowed to change what. Our guide on how to build internal tools covers the method in detail.
Stock and inventory tracker
Internal tool · Operations
Build an internal web app for [a shop selling spare parts with 2 warehouses] to track stock. Roles: admin, warehouse staff (record movements, cannot change prices), sales (read only). Login: email, by invitation only. Screens: product list with stock per warehouse, filters by category and supplier and a "below minimum" filter, product detail with the movement history, form to record a movement (in, out, transfer between warehouses), suppliers list, purchase order draft built from the products below minimum. Data: a product has a reference, a supplier, a minimum level and a stock level per warehouse; a movement has a type, a quantity, a date and the person who recorded it. Constraints: stock never goes below zero, every change is logged with its author, CSV import of the current catalogue, a daily email to the admin listing products below minimum. Practical style: white, navy, large tables.
Sales pipeline CRM
Internal tool · Sales
Build a simple CRM web app for [a B2B team of 5 salespeople] selling [training programmes]. Roles: sales manager, salesperson. Login: email, by invitation only. Screens: pipeline as a Kanban board (lead, contacted, meeting, proposal, won, lost) with drag and drop, deal detail with contacts, notes, next action and amount, companies list, my tasks for today, manager dashboard with the pipeline value per stage and per salesperson. Data: a company has many contacts and deals; a deal has an owner, an amount, a stage and a next action date. Constraints: salespeople see all deals but edit only their own, the manager edits everything, a reminder email in the morning for overdue next actions, CSV import of existing contacts, a reason required when a deal moves to lost. Sharp style: white, black, one orange accent.
Employee onboarding checklist
Internal tool · HR
Build an internal web app for [a 60-person company] to run the onboarding of new hires. Roles: HR admin, manager, new hire. Login: email; the HR admin creates the accounts. Screens: onboarding templates (a list of tasks with the team responsible: HR, IT, manager), active onboardings with a progress bar, onboarding detail with tasks grouped by week, the new hire's own page with their tasks, documents to sign and contacts. Data: a template has many tasks with a responsible team and a day offset from the start date; an onboarding copies a template for one person and a start date; a task has a status (to do, done) and a done date. Constraints: a new hire sees only their own onboarding, managers see their team's onboardings, an email to each responsible team when a task is due, uploaded documents stored privately. Warm style: cream, deep blue, rounded cards.
Client portal prompts
A client portal is an internal tool with a door to the outside: the team works on one side, each client sees only their own records on the other. The permission sentence is the whole product here. More examples in our guide to the client portal.
Accounting firm portal
Client portal · Accounting
Build a client portal web app for [an accounting firm with 4 accountants and 150 small business clients]. Roles: firm admin, accountant, client. Login: staff by email; clients by invitation from their accountant. Screens for clients: documents to provide this month with an upload button, their uploaded documents by year, messages with their accountant, their invoices from the firm. Screens for staff: client list with the number of missing documents, client detail, request a document (title, due date), message threads. Data: a client company has one accountant and many document requests; a request has a due date and a status (requested, received, validated); a document belongs to a request. Constraints: a client sees only their own company, files stored privately, an email to the client when a request is created and a reminder [3 days] before the due date. Trustworthy style: white, dark blue, no decoration.
Agency project and approval portal
Client portal · Agency
Build a portal web app for [a design agency] to share work with clients and collect approvals. Roles: agency admin, designer, client. Login: staff by email; clients by invitation link per project. Screens for clients: their projects, deliverables waiting for approval with a preview, approve or request changes with a comment, project timeline. Screens for staff: projects board, upload a deliverable version, comments thread per deliverable, hours logged per project. Data: a project belongs to a client and has many deliverables; a deliverable has many versions and a status (draft, sent, changes requested, approved). Constraints: clients see only their projects and only versions marked as sent, an email to the client when a version is sent and to the designer when the client answers, approval date and approver stored for each version. Editorial style: white, black, generous spacing.
Dashboard and back-office prompts
A dashboard reads data more than it writes it. Say where the numbers come from, which ones matter, over which period, and who is allowed to see them.
Sales dashboard for a small chain
Dashboard · Retail
Build a web app dashboard for [a chain of 6 coffee shops]. Roles: owner (all shops), shop manager (their shop only). Login: email, by invitation only. Data source: a daily sales CSV per shop uploaded by each manager, with date, product, quantity and amount. Screens: overview with revenue, number of sales and average basket for the selected period, compared with the previous period; revenue by shop and by day as charts; top 10 products; upload page with the history of imported files; settings with each shop's opening hours. Constraints: a manager sees only their own shop, a file for a date already imported replaces the old data after a confirmation, period filter (this week, this month, custom), export of any table as CSV. Clear style: white, coffee brown, readable charts without 3D.
Admin back office for a marketplace
Back office · Marketplace
Build an admin back-office web app for [a second-hand furniture marketplace]. Roles: admin, moderator (reviews listings and reports, cannot issue refunds). Login: email, staff accounts only, created by the admin. Screens: listings waiting for review with approve and reject (reason required), reports from users with the reported listing or member, member detail with their listings, orders and warnings, orders list with filters by status, refund form for admins. Data: a member has many listings and orders; a listing has a status (pending, live, rejected, sold); a report links a reporter, a target and a reason; every admin action is stored with its author and date. Constraints: a rejected listing sends an email to its seller with the reason, a member with [3 warnings] is suspended automatically, all tables searchable and sortable. Functional style: light grey, white panels, red for destructive actions.
Follow-up prompts for a web app
The first prompt builds the skeleton. Then log in with each role and check what it sees before you add anything. Every later message should change one thing: a role, a column, a status, an email, a bug. Say what to build, where it goes, and what must stay untouched.
When
Follow-up prompt to adapt
Add a role
Add a [viewer] role that sees [all projects] in read only, with no edit buttons and no access to [settings]. Other roles unchanged.
Fix a permission
A [client] can currently open another client's [invoice] by changing the URL. Restrict [invoices] to their owner in the database, not only in the interface.
Add a column or a filter
In the [deals] list, add a [next action date] column, sortable, and a filter [overdue only]. Do not change the other columns.
Add payments
Add a [Pro] plan at [$19 a month] with Stripe Checkout. Free accounts keep [1 board]; Pro unlocks unlimited boards. Keep the Stripe secret key on the server.
Fix a bug
On [the stock movement form], a transfer removes the quantity from the first warehouse but does not add it to the second. Expected: both updated together. Fix only this.
On Cadrant's AI web app builder, these prompts produce a React web app with its Supabase backend: database, login, file storage and server-side functions, connected to a Supabase account opened in your name, so the data stays yours. You test each role in the live preview, iterate in conversation, then publish on a Cadrant URL or your own domain. If you are comparing tools, our Lovable alternatives guide sets the main builders side by side. The prompt itself works in any of them: five web lines, one paragraph, and the brackets filled with your project.
Web App Prompt Examples: 10 Prompts for SaaS & Internal Tools | Cadrant