Publish an in-app announcement to your users
Let the owner publish a clear, targeted message inside the app without asking the builder to change the site each time.
When to use this
When you need to tell users about planned downtime, a new feature, a deadline or an important change inside the app.
Before you start
- A working admin login or owner role. If anyone can reach the admin form, do not publish this feature yet.
- The user groups you genuinely need; start with everyone and logged-in users if you are unsure.
- One short test message, a start and end time, and a safe page to link to.
- A decision about whether ordinary information messages may be dismissed.
The prompt
Add an in-app announcement feature so I can publish messages to users without rebuilding the app. Create an admin-only form where I can enter a title, short message, optional link and link text, audience [EVERYONE / LOGGED-IN USERS / A SPECIFIC USER GROUP], start date and time, end date and time, and importance [INFORMATION / IMPORTANT]. Only admins may create, edit, publish or remove announcements. Show the current announcement as a clear banner near the top of the app. Information messages can be dismissed and should stay dismissed for that user unless I publish a newer version. Important messages may stay visible until their end time, but they must never block the entire app or pretend to be a security or payment warning. If several announcements are active, show the most important current one and put the rest in a small message list users can open. Hide expired messages automatically. The link must open the correct internal page or safe external address. Display the message as plain text, not hidden computer instructions or raw HTML, which is code used to structure web pages, so pasted content cannot run code. Make it readable on a phone, reachable by keyboard, and announced clearly by screen readers, which are tools that read a page aloud for people who cannot see it. Keep the visual style calm and consistent with the app. Create one unpublished test announcement for [TEST AUDIENCE], then tell me how to preview, publish, edit, expire and remove it.
Already building? Paste this into your project. Starting fresh? Open a free account with a compatible builder below.
Build it on
What this creates
- An admin-only announcement editor
- Scheduled, expiring banners for selected audiences
- Dismissal that is remembered per user for ordinary messages
- A small list for additional current announcements
- Safe text display and accessible mobile behavior
Check it worked
Paste the prompt, wait for the build to finish, then confirm these — in plain language, no technical checks needed:
- As an admin, you can create and preview a test announcement before publishing it
- A normal user cannot open the announcement editor, even by typing its address directly
- The chosen audience sees the message and an excluded test user does not
- Dismissing an information message keeps it hidden after a refresh
- The message disappears after its end time, and its link opens the page you selected
- You can reach and dismiss the banner using only the keyboard
Something missing? That's normal — ask for it in one short follow-up message rather than re-running the whole prompt.
Next steps
Add a read confirmation
For a policy or operational change users genuinely must acknowledge
For announcements marked [REQUIRES ACKNOWLEDGEMENT], add an I understand button and record the user and time when it is clicked. Do not block access to unrelated pages unless [SPECIFIC LEGITIMATE REASON]. Give admins a simple list of who has and has not acknowledged it.
You'll know it worked when: A test user's acknowledgement is recorded once and visible only to admins.
Target one user group
When a message applies only to members, staff or another existing group
Add [USER GROUP] as an announcement audience using the app's existing roles or membership information. Do not create a second copy of user permissions. Test with one included account and one excluded account, and keep all existing announcements unchanged.
You'll know it worked when: Only the selected group sees the targeted test announcement.
Add an announcement archive
When users need to find previous messages
Add a simple announcement archive that logged-in users can open from [MENU LOCATION]. Show published announcements that applied to that user, newest first, but hide drafts and messages for other audiences. Keep expired announcements readable without showing them as current alerts.
You'll know it worked when: A user can find past relevant messages without seeing drafts or another group's messages.
Watch out for
- Overusing banners trains people to ignore them. Reserve the persistent style for information that affects the user's next action, and give every announcement an end time.
- Hidden admin buttons are not security. The edit and publish actions must reject normal users at the data level, not merely disappear from the menu.
- Pasted formatting can become a security problem. Store and display plain text unless rich text is deliberately cleaned before display; never render arbitrary pasted HTML.
- Time zones can publish at the wrong moment. Show the selected time zone beside both start and end times in the admin preview.
- Urgent-looking messages can resemble scams. Never imitate password, payment or account-lock warnings unless the app is showing a real verified account state.
Platform notes
All three core platforms can build this when the app has a place to store announcements and a way to identify admins. Base44 can use its built-in storage and access rules. Lovable can use Lovable Cloud's database, authentication and private server logic, or optional Supabase. v0 can build the private app logic but needs a selected database and authentication provider. On a site with nowhere to save announcements, the simpler alternative is a fixed banner that requires republishing for every change.
Spend fewer credits
Every builder charges you for the work its AI does — so the cheapest habit is thinking before you build. These six rules cut most of the waste, whichever platform you choose.
- Plan in a free chat first. Sketch the whole thing in ChatGPT, Claude or Gemini — pages, features, what each form collects, what it should look like. Thinking there is free; thinking inside a builder is billed.
- Start from a written prompt, not a sentence. "Make me a website" is the most expensive sentence in AI building. A complete first prompt — like the ones on this site — saves dozens of correction rounds.
- Don't be lazy with the details. Every detail you leave out comes back as a correction you pay for. Business name, colors, every page, every form field, what happens after someone submits — put it all in the first prompt.
- One change per message afterwards. "Fix the header, and the form, and the colors" produces a tangle that costs more to unpick than it saved.
- Stuck? Stop patching. If the same fix fails about three times, don't send a fourth correction — describe the whole section's desired end state in one fresh message instead.
- Start free. Upgrade when you need more. Use the free allowance to build and explore your first version. Upgrade when you need more usage or paid features, and check any connected service costs before launch.
The prompts on this page are written to do most of this work for you — that's the point of them.
Read the full guideRelated playbooks
Last reviewed: 2026-08-27