# Introduction
Source: https://docs.bettter.app/1.getting-started/1.1-introduction
What Bettter is and how its feature board, roadmap, changelog, and support portal fit together.
Bettter is a one-time-payment feedback platform for indie makers, SaaS founders, and product teams. You collect feature requests, share a public roadmap, publish a changelog, and offer support — without monthly subscription fees.
## What Bettter includes
Each **project** gives you four customer-facing modules and a settings panel to configure them.
Collect feature requests from customers. Let the most voted rise to the top.
Show planned, in-development, and shipped work in one kanban-style view.
Share product updates and launches on a dedicated timeline page.
Give users a contact form that sends tickets to your support email.
## How a project fits together
A **project** is not a generic workspace. It is one complete feedback portal with its own subdomain (`{slug}.bettter.app`), four tabs, and all related settings.
```mermaid theme={null}
flowchart LR
subgraph project [Project]
Features[Features board]
Roadmap[Roadmap]
Changelog[Changelog]
Support[Support]
end
Owner[Owner dashboard] --> project
project --> Portal[Public portal]
```
You manage content in the **dashboard** (owner admin area). Your customers interact with the **public portal** at your project subdomain or custom domain.
## Owner vs visitor
Sign in at [bettter.app/dashboard](https://bettter.app/dashboard) to create projects, edit settings, manage features, drag cards on the roadmap, and publish changelog entries. Opening a project lands on its Features board — there is no separate Dashboard tab inside a project.
Visitors browse your feature board, read the roadmap and changelog, submit support tickets, and — when enabled — suggest features, vote, and comment after signing in. Pending features are visible only to you, not on the public board.
## Try it live
Explore a live example of the feature board, roadmap, changelog, and support form.
## Get started
[Sign up](https://bettter.app/sign-up) and choose a lifetime plan (Basic, Pro, or Max).
From `/dashboard`, create a project with a name and slug. Your portal will be available at `{slug}.bettter.app`.
Use the project settings panel to configure branding, then open the public portal link to see what your customers will see.
After these three steps you have a working feedback portal you can share with users.
## Pricing
All plans are one-time payments with lifetime updates:
* **Basic** — \$59, 1 project
* **Pro** — \$119, 5 projects
* **Max** — \$299, unlimited projects
Every plan includes custom domain, unlimited users, features, changelog entries, and support tickets. See [pricing on the homepage](https://bettter.app/#pricing) for full details.
## Next
Continue to [What is a project](/1.getting-started/1.2-what-is-a-project) to learn how the four modules and settings panel connect inside a single project.
# What is a project
Source: https://docs.bettter.app/1.getting-started/1.2-what-is-a-project
How a Bettter project works — subdomain, four modules, settings panel, and admin home.
In Bettter, a **project** is the core unit of your account. It is not a generic workspace or folder — it is one complete feedback portal with its own address, four customer-facing tabs, and a settings panel to configure everything.
## Your portal address
Every project gets a unique subdomain:
```
{slug}.bettter.app
```
When you create a project, you choose a **slug** — the part before `.bettter.app`. Slugs must be lowercase letters, numbers, and hyphens only, between 1 and 32 characters. Reserved slugs such as `www`, `dashboard`, and `docs` are blocked.
On paid plans you can also connect a **custom domain** (for example `feedback.yourdomain.com`) instead of the default subdomain. See [Custom domain](/3.configure/3.6-custom-domain) for setup instructions.
## Four modules
Each project includes four tabs that your customers see on the public portal. You manage all of them from the owner dashboard.
**Owner:** Create, edit, and moderate feature requests. Filter by status including Pending.
**Visitors:** Browse the board, suggest features, vote, and comment when enabled.
**Owner:** Drag cards between Planned, In Development, and Shipped columns.
**Visitors:** Read-only kanban view of your product direction.
**Owner:** Create, edit, and delete changelog entries.
**Visitors:** Read-only timeline of product updates.
**Owner:** See where support tickets are sent.
**Visitors:** Submit tickets through a contact form.
You can show or hide each tab individually in **Controls** within the settings panel. When a tab is disabled, visitors see a message that the page is disabled by the app owner.
## Settings panel
Open the settings panel from the project list at `/dashboard` — click **Add project** to create, or the gear icon on a project card to edit.
The panel opens as a right-side sheet with accordion sections. Each section has a dedicated page in [Configure](/3.configure/3.1-primary-settings):
Project name and slug (subdomain).
Website URL, SEO title, and meta description.
Brand color, theme, font, UI language, logo, favicon, and Open Graph image.
Support email and descriptive message shown on the support form.
Connect and verify a custom hostname (paid plans).
Embed script, trigger button, and section toggles (paid plans).
Notification address and toggles for new features, comments, and status changes.
Tab visibility, open for voting, comments enabled, and shared navigation strip.
## Admin home is Features
There is no separate **Dashboard** tab inside a project. When you open a project from `/dashboard`, you land on its **Features** board at `/dashboard/[slug]`. Use the tab bar to switch to Roadmap, Changelog, or Support.
```mermaid theme={null}
flowchart LR
subgraph project [Project]
Features[Features board]
Roadmap[Roadmap]
Changelog[Changelog]
Support[Support]
end
Owner[Owner dashboard] --> project
project --> Portal["Public portal at slug.bettter.app"]
```
You manage content in the **dashboard**. Your customers interact with the **public portal** at your subdomain or custom domain.
## Next
Continue to [Creating and managing projects](/1.getting-started/1.3-creating-and-managing-projects) to learn how to create, edit, open, and delete projects from the project list.
# Creating and managing projects
Source: https://docs.bettter.app/1.getting-started/1.3-creating-and-managing-projects
Create, edit, open, and delete projects from the dashboard project list, and understand plan limits.
The project list at [bettter.app/dashboard](https://bettter.app/dashboard) is your home base. From here you create projects, open settings, visit the public portal, and delete projects you no longer need.
## Projects list
The page title is **Projects**. Next to it you see two badges:
* **Plan badge** — your plan name (`BASIC`, `PRO`, `MAX`) or `free` if you have not purchased a plan yet
* **Count badge** — how many projects you have versus your limit, for example `1/1`, `3/5`, or `2/unlimited`
Each project appears as a card showing its name, slug, and action buttons.
## Create a project
Click **Add project** in the header. If you are on the free tier with no plan, you see **Upgrade plan now** instead — you must purchase a lifetime plan before creating projects.
The **Create new project** panel opens. Under **Primary**, enter:
* **Name** — 1–32 characters (required)
* **Slug** — your subdomain prefix; the field shows `.bettter.app` as a suffix. Lowercase letters, numbers, and hyphens only.
Expand any accordion sections you want to set now:
* **SEO** — website URL, SEO title, meta description
* **Branding** — brand color, theme, font, UI language (logo and favicon uploads are available after the project is created)
* **Support** — support email and descriptive message
* **Controls** — tab visibility, open for voting, comments, shared navigation
Click **Create**. The panel closes and the project list refreshes. You stay on `/dashboard` — Bettter does not automatically navigate into the new project.
Your portal is live at `{slug}.bettter.app` as soon as the project is created.
## Plan limits
Each lifetime plan sets how many projects you can create:
| Plan | Projects |
| -------------- | -------------------- |
| Free (no plan) | 0 — upgrade required |
| Basic | 1 |
| Pro | 5 |
| Max | Unlimited |
When you reach your limit, **Add project** is disabled and the count badge shows your cap (for example `1/1`). Attempting to create another project returns the error **"Project limit reached for your plan."**
See [pricing on the homepage](https://bettter.app/#pricing) for plan details.
## Edit project settings
Click the **Settings** (gear) icon on a project card to open the **Edit project** panel. The accordion sections are the same as during creation, with branding uploads now enabled.
Make your changes, then click **Update**. The button stays disabled until something has changed. While saving, it shows **Updating…**.
## Open the public portal
There are two ways to preview what your customers see:
* Click the **external-link icon** next to the project name on the project card
* After opening a project, click **Open public portal** in the admin header
Both open `{slug}.bettter.app` in a new browser tab.
## Delete a project
Deleting a project permanently removes all associated data — features, comments, changelog entries, and settings. This cannot be undone.
Click the **Trash** icon on the project card footer.
A dialog titled **Are you sure?** appears. It explains that deleting a project also deletes all data associated with it.
Enter `DELETE` in the confirmation field exactly as shown. The **Delete Project** button enables once the text matches.
Click **Delete Project**. While deleting, the button shows **Deleting…**. If deletion fails, a **Deletion failed** banner appears.
## Next
Continue to [Dashboard overview](/1.getting-started/1.4-dashboard-overview) to learn how admin navigation works inside a project and what only you can see as the owner.
# Dashboard overview
Source: https://docs.bettter.app/1.getting-started/1.4-dashboard-overview
Navigate the owner dashboard — Features, Roadmap, Changelog, and Support — and understand owner-only capabilities.
Once you open a project from `/dashboard`, you enter the owner admin area for that project. This is where you manage content, moderate suggestions, and preview what visitors will see on the public portal.
## Entering a project
Click a project card on the project list. You land on the **Features** board at:
```
/dashboard/[slug]
```
There is no separate Dashboard tab — Features is the default home for every project.
## Header and navigation
The admin header includes:
* **Back** — returns to the project list at `/dashboard`
* **Sign Out** — top right
* **Project bar** — your project logo and name on a brand-colored rounded bar
* **Open public portal** — opens `{slug}.bettter.app` in a new tab
Below the header, a tab bar lets you switch between the four modules:
| Tab | Route |
| --------- | ----------------------------- |
| Features | `/dashboard/[slug]` |
| Roadmap | `/dashboard/[slug]/roadmap` |
| Changelog | `/dashboard/[slug]/changelog` |
| Support | `/dashboard/[slug]/support` |
**Search** is available on Features, Roadmap, and Changelog — not on Support.
On mobile, tabs show icons only. On larger screens, they show text labels.
## What you can do in each tab
* Title: **Features**
* **Suggest new feature** with the full status picker (Pending, Open for voting, Planned, In development, Shipped)
* Filter by status: All, Pending, Open for voting, Planned, In development, Shipped
* Sort by most voted, least votes, newest, or oldest
* Click a card to open its detail page; use the edit pencil to update or delete
* Vote on features when voting is enabled
* Title: **Roadmap**
* Three columns: **Planned**, **In Development**, **Shipped**
* Drag cards between columns to update their status (dashboard only)
* Pending and open-for-voting cards do not appear in roadmap columns
* **Add new log** to create entries with title, description, type, publish date, and optional image
* Click an entry to edit or delete it
* Title: **Support**
* Shows where tickets arrive: **Your support tickets arrive at **
* If no support email is configured, tickets go nowhere until you set one in project settings
## Owner vs public
Full control over content and settings. See pending features, edit any card, drag roadmap items, and publish changelog entries.
Read-only roadmap and changelog. Feature board without pending cards. Voting, suggesting, and commenting when enabled and signed in.
| Capability | Owner | Public |
| ---------------------- | ---------------------------- | -------------------------------- |
| See pending features | Yes | No |
| Edit or delete content | Yes | No |
| Vote and comment | Yes, when enabled | Signed-in visitors, when enabled |
| Roadmap drag-and-drop | Yes | Read-only columns |
| Changelog CRUD | Yes | Read-only |
| Support | View destination email | Submit ticket form |
| Search | Features, Roadmap, Changelog | Features, Roadmap, Changelog |
## Pending features
**Pending** features are visible only to you as the owner. They appear on your Features board (use the Pending filter) and on card detail pages in the dashboard. They are hidden everywhere on the public portal — the board, roadmap columns, and direct card URLs all exclude pending items.
When **Open for voting** is turned off in Controls, new visitor suggestions go to **Pending** for your review. When it is on, suggestions appear on the board immediately as **Open for voting**. See [Creating a feature](/2.manage-content/2.1-creating-a-feature) for the full moderation flow.
## Disabled tabs
If you turn off a tab in **Controls**, it disappears from the public portal navigation. Visitors who navigate to a disabled tab see:
> The page is disabled by app owner ()
You can also hide the entire navigation strip on the public portal with **Show shared tabs**.
## Help
A fixed **?** button in the bottom-right corner of every dashboard page links to the Bettter support portal.
## Next
You have completed Getting started. Continue to [Creating a feature](/2.manage-content/2.1-creating-a-feature) to learn how to add and moderate feature requests on your board.
# Creating a feature
Source: https://docs.bettter.app/2.manage-content/2.1-creating-a-feature
Add feature requests from the dashboard or public portal — title, description, status, and expected delivery.
Feature requests live on the **Features** board. You and your visitors can suggest new features through the same **Suggest new feature** dialog — but what each person can set depends on whether they are the project owner or a signed-in visitor.
## Where to create a feature
| Context | Route |
| --------------- | -------------------- |
| Owner dashboard | `/dashboard/[slug]` |
| Public portal | `{slug}.bettter.app` |
Click **Suggest new feature** on the Features board to open the dialog.
## Dialog fields
| Field | Required | Details |
| --------------------- | ---------- | ------------------------------------------------------------------------------- |
| **Title** | Yes | 12–80 characters. Placeholder: `"Enter feature title (12–80 characters)"` |
| **Description** | Yes | 40–480 characters. Placeholder: `"Describe the feature... (40–480 characters)"` |
| **Status** | Owner only | Five-tab picker: Pending, Voting, Planned, In Dev, Shipped |
| **Expected delivery** | Owner only | Shown when status is Planned or In Dev — pick a month/quarter and year |
Click **Cancel** to close without saving, or **Submit** to create the feature. While submitting, the button shows **Submitting…**.
The creator automatically receives one vote on the new feature.
## Owner vs visitor flow
You see the full **Status** picker and can set any status including **Pending**. When status is **Planned** or **In Dev**, you can set an **Expected delivery** date. The dialog closes immediately on success.
Visitors must sign in before submitting. Unsigned users see a **Please sign up** prompt.
There is no status picker — the initial status depends on your **Open for voting** setting in Controls:
* **Open for voting ON** → status is **Open for voting**; the feature appears on the public board immediately
* **Open for voting OFF** → status is **Pending**; the feature is hidden until you review it
After submitting, visitors see a thank-you message:
* If open for voting: *"Your idea is live on the board — others can vote on it now."*
* If pending: *"Your idea has been received. We'll review it shortly..."*
## Expected delivery
When you set a feature to **Planned** or **In Dev**, an **Expected delivery** field appears:
* **Month or quarter** — January through December, or Q1–Q4
* **Year** — current year through five years ahead
This date is shown on the feature card and detail page to set customer expectations.
## Next
Continue to [Editing a feature](/2.manage-content/2.2-editing-a-feature) to update title, description, status, and expected delivery after a feature is created.
# Deleting a changelog entry
Source: https://docs.bettter.app/2.manage-content/2.10-deleting-a-changelog-entry
Remove a changelog entry permanently from the edit dialog.
You can delete any changelog entry from the edit dialog. Deletion is permanent and cannot be undone.
## How to delete
1. Open the **Changelog** tab at `/dashboard/[slug]/changelog`
2. Click the entry you want to remove
3. In the **Edit Changelog Entry** dialog, click the **Trash** icon
4. Confirm in the delete dialog
## Confirmation dialog
* **Title:** Delete Changelog Entry
* **Body:** *"Are you sure you want to delete this changelog entry? This action cannot be undone."*
* **Buttons:** **Cancel** or **Confirm**
Deleted entries are removed from both the dashboard and the public changelog immediately.
## Next
Continue to [Receiving support tickets](/2.manage-content/2.11-receiving-support-tickets) to learn how support submissions reach your inbox.
# Receiving support tickets
Source: https://docs.bettter.app/2.manage-content/2.11-receiving-support-tickets
Configure a support email and receive visitor tickets from the public portal form.
The Support module gives visitors a contact form on your public portal. Submissions are emailed to the support address you configure in project settings.
## Dashboard Support tab
Open the **Support** tab at `/dashboard/[slug]/support`. The page shows:
* **Heading:** Support
* **Body:** Your support tickets arrive at
If no support email is configured, the page shows **nowhere** instead of an email address — tickets cannot be delivered until you set one.
## Configure support email
In the project settings panel, expand the **Support** accordion:
| Field | Details |
| ----------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| **Email** | Destination address (placeholder: `support@example.com`). Marked optional in the form, but required to enable the Support tab |
| **Descriptive message** | Text shown above the public support form (placeholder: `"How visitors can reach you or what to expect"`) |
The **Support** tab toggle in **Controls** is blocked until a valid support email is entered.
## Public support form
Visitors submit tickets at `{slug}.bettter.app/support`:
| Field | Label |
| ----------- | ------------------------------------------------------------ |
| Bug toggle | Reporting a bug? |
| Name | Your Name \* |
| Email | Your Email \* |
| Subject | Subject \* |
| Message | Describe your issue as detailed as you can \* |
| Attachments | Screenshots (optional) — PNG/JPG, up to 3 images, 4 MB total |
Submit button labels: **Submit Ticket**, **Report a bug**, or **Sending…** while in progress.
On success, visitors see: **"Your message was sent. We will get back to you soon."**
## Email delivery
When a visitor submits a ticket, Bettter sends an email to your configured support address:
* **From:** New Support Ticket (or New bug report for bug reports)
* **Reply-To:** the submitter's email address
* **Subject:** the visitor's subject line (max 200 characters)
* **Body:** includes the submitter's name and message
You can reply directly to the email to respond to the visitor.
## Enable the Support tab
To show Support on your public portal:
1. Set a valid support email in project settings
2. Enable the **Support** toggle in **Controls**
If the Support tab is disabled, visitors see the standard disabled-page message.
## Next
You have completed Manage content. Continue to [Support settings](/3.configure/3.4-support-settings) to configure your support email and descriptive message.
# Editing a feature
Source: https://docs.bettter.app/2.manage-content/2.2-editing-a-feature
Update a feature's title, description, status, and expected delivery from the board or detail page.
As the project owner, you can edit any feature request at any time. Visitors cannot edit features — they can only suggest new ones, vote, and comment.
## Where to edit
| Surface | How to open |
| ------------------- | ----------------------------------------------------- |
| Features board | Click the pencil icon on a card (`Edit feature card`) |
| Feature detail page | Click the pencil icon in the card header |
Both open the **Edit Feature Request** dialog.
## Editable fields
| Field | Details |
| --------------------- | --------------------------------------------------------------- |
| **Title** | 12–80 characters |
| **Description** | Can be cleared on edit; if non-empty, must be 40–480 characters |
| **Status** | Pending, Voting, Planned, In Dev, or Shipped |
| **Expected delivery** | Available when status is Planned or In Dev |
Placeholders match the create dialog: `"Enter feature title (12–80 characters)"` and `"Describe the feature... (40–480 characters)"`.
## Save changes
Click **Update** to save. The button is disabled until something has changed. While saving, it shows **Updating…**.
If you try to save with no changes, Bettter shows **No changes detected**.
Only the project owner can edit features. Attempting to edit as a non-owner returns **"You don't have permission to edit this card"**.
## Feature detail pages
Each feature has a dedicated detail page with full description, vote count, and comments:
| Context | URL |
| --------------- | ------------------------------- |
| Owner dashboard | `/dashboard/[slug]/[cardSlug]` |
| Public portal | `{slug}.bettter.app/[cardSlug]` |
Editing from the detail page uses the same **Edit Feature Request** dialog as the board.
## Next
Continue to [Deleting a feature](/2.manage-content/2.3-deleting-a-feature) to remove a feature and all associated votes and comments.
# Deleting a feature
Source: https://docs.bettter.app/2.manage-content/2.3-deleting-a-feature
Remove a feature request and all its votes and comments from the edit dialog or detail page.
Deleting a feature permanently removes the card and all associated data — votes and comments included. Only the project owner can delete features.
## How to delete
1. Open the **Edit Feature Request** dialog from the Features board (pencil icon) or the feature detail page
2. Click the **Trash** icon in the dialog header
3. Confirm in the **Delete Feature Request** dialog
## Confirmation dialog
* **Title:** Delete Feature Request
* **Body:** *"Are you sure you want to delete this feature request? This action cannot be undone."*
* **Buttons:** **Cancel** or **Confirm** (shows **Deleting…** while in progress)
Deletion is permanent. All votes and comments on the feature are removed along with the card.
## What gets deleted
Bettter removes data in this order:
1. All votes on the feature
2. All comment likes
3. All comments on the feature
4. The feature card itself
On success, you may see a confirmation such as **"Card deleted successfully! (N vote(s) removed)"**.
## After deletion
If you delete from a feature detail page, Bettter redirects you back to the Features board.
Only the project owner can delete features. Non-owners see **"Only the project owner can delete this card"**.
## Next
Continue to [Feature statuses](/2.manage-content/2.4-feature-statuses) to understand the status workflow and where each status appears.
# Feature statuses
Source: https://docs.bettter.app/2.manage-content/2.4-feature-statuses
The feature status workflow — pending, open for voting, planned, in development, and shipped.
Every feature request has a **status** that controls where it appears on your board, roadmap, and public portal. As the owner, you can set any status. Visitor suggestions get an initial status based on your **Open for voting** setting.
## Status workflow
```mermaid theme={null}
flowchart LR
pending[Pending] --> voting[Open for voting]
voting --> planned[Planned]
planned --> inDev[In development]
inDev --> shipped[Shipped]
```
Statuses are not strictly linear — you can move a feature to any valid status at any time from the edit dialog.
## Status reference
| Status | Admin label | Public label | Where it appears |
| ----------------- | ----------- | --------------- | ------------------------------------------------ |
| `pending` | Pending | Hidden | Dashboard Features board only (owner filter) |
| `open-for-voting` | Voting | Open For Voting | Features board (admin + public) |
| `planned` | Planned | Planned | Features board + Roadmap (Planned column) |
| `in-development` | In Dev | In Development | Features board + Roadmap (In Development column) |
| `shipped` | Shipped | Shipped | Features board + Roadmap (Shipped column) |
## Visibility rules
Visible only to you on the dashboard Features board and detail pages. Hidden from the public board, roadmap, search, and direct URLs (public card URLs return 404).
Visible on the public Features board. Does not appear in roadmap columns — use Planned or later statuses for roadmap placement.
Visible on both the Features board and the Roadmap in their respective columns.
## Filtering
**Admin board filters:** All, Pending, Open for voting, Planned, In development, Shipped
**Public board filters:** All, Open for voting, Planned, In development, Shipped (no Pending option)
## Moving features through the workflow
Typical owner workflow:
1. Visitor suggests a feature → **Pending** (if open for voting is off) or **Open for voting** (if on)
2. Review pending suggestions → change to **Open for voting** to publish, or delete
3. Prioritize popular ideas → move to **Planned** with an expected delivery date
4. Start building → move to **In development**
5. Release → move to **Shipped**
You can also drag cards between roadmap columns — see [Moving cards with drag and drop](/2.manage-content/2.7-moving-cards-with-drag-and-drop).
## Next
Continue to [Voting](/2.manage-content/2.5-voting) to learn how voting works and how the Open for voting setting affects new suggestions.
# Voting
Source: https://docs.bettter.app/2.manage-content/2.5-voting
Let signed-in users vote on feature requests from the board and detail page.
Voting helps you prioritize feature requests by showing which ideas your users care about most. Signed-in users can upvote features on the board and on individual card detail pages.
## Open for voting setting
The **Open for voting** toggle lives in project settings under [Controls](/3.configure/3.5-controls):
> If active, then newly suggested features from your users will be immediately available for public view and voting. Otherwise, the status will be set as "Pending" and will proceed for your moderation.
**Open for voting** controls the **initial status** of visitor suggestions — not whether vote buttons appear. Vote buttons are shown on all visible (non-pending) features for signed-in users.
| Setting | New visitor suggestion | Public visibility |
| ------- | ---------------------- | ------------------------------ |
| ON | Open for voting | Live on board immediately |
| OFF | Pending | Hidden until you change status |
See [Creating a feature](/2.manage-content/2.1-creating-a-feature) for the full suggest flow.
## Where users can vote
| Surface | Voting |
| ------------------- | --------------------------------------------- |
| Features board | Yes — upvote button on each card |
| Feature detail page | Yes — same upvote control |
| Roadmap | No — vote buttons are hidden on roadmap cards |
## How voting works
* Click the upvote button to add a vote (`aria-label`: **Upvote**)
* Click again to remove your vote (`aria-label`: **Remove upvote**)
* Confirmation messages: **Vote added!** or **Vote removed!**
* The feature creator automatically receives one vote when the feature is created
## Sign-in required
Visitors must be signed in to vote on the public portal. Unsigned users who try to vote see a **Sign in to continue** dialog.
On the server, unsigned vote attempts return **"Unauthorized. Please sign in to vote."**
## Sorting by votes
On the Features board, sort cards by **Most voted** or **Least votes** to surface popular requests at the top.
## Next
Continue to [Comments](/2.manage-content/2.6-comments) to enable discussion on feature detail pages.
# Comments
Source: https://docs.bettter.app/2.manage-content/2.6-comments
Enable comments on feature detail pages — create, like, and delete for signed-in users.
Comments let users discuss feature requests in detail. They appear on the **feature detail page only** — not on the board list (though the board may show a comment count icon when comments exist).
## Enable comments
The **Comments** toggle lives in project settings under [Controls](/3.configure/3.5-controls):
> When disabled, visitors cannot post new comments on feature card detail pages. Existing comments remain visible.
| Setting | New comments | Existing comments |
| ------------ | --------------------------- | ----------------- |
| ON (default) | Allowed for signed-in users | Visible |
| OFF | Compose box hidden | Still visible |
## Where comments appear
Open any feature card to see the **Comments** section below the description and vote controls.
| Element | Label |
| ------------------- | ----------------------------- |
| Section heading | Comments |
| Compose placeholder | Write a comment... |
| Submit button | Comment |
| Empty state | No comments yet |
| Like | Like comment / Unlike comment |
| Delete | Delete comment (trash icon) |
## Who can comment
* **Signed-in visitors** can create, like, and delete their own comments
* **Project owner** can delete any comment
* **Unsigned visitors** see a sign-in prompt when trying to comment
Comments must be 1–2000 characters.
## Pending features
Non-owners cannot comment on **Pending** features. If a visitor tries, they receive **"Cannot comment on pending cards"**. As the owner, you can still comment on pending features from the dashboard.
## Comment actions
Type in the compose box and click **Comment**. Requires sign-in on the public portal.
Click the like button on any comment to toggle your like. Requires sign-in.
Click the trash icon to delete. Authors can delete their own comments; the project owner can delete any comment.
## Next
Continue to [Moving cards with drag and drop](/2.manage-content/2.7-moving-cards-with-drag-and-drop) to update feature status from the Roadmap tab.
# Creating a changelog entry
Source: https://docs.bettter.app/2.manage-content/2.8-creating-a-changelog-entry
Publish product updates with title, description, type, date, and an optional image.
The Changelog tab lets you share product updates, bug fixes, and improvements with your users. Entries appear on both the admin dashboard and the public portal (read-only for visitors).
## Where to create
Open the **Changelog** tab at `/dashboard/[slug]/changelog` and click **Add new log**.
## Dialog fields
| Field | Required | Details |
| --------------- | -------- | --------------------------------------------------------------------------------- |
| **Title** | Yes | 12–160 characters. Placeholder: `"Enter log title (12–160 characters)"` |
| **Description** | Yes | 40–4000 characters. Placeholder: `"Describe the changes... (40–4000 characters)"` |
| **Type** | Yes | **New**, **Fix**, or **Improvement** (tab picker) |
| **Date** | Yes | Calendar picker; defaults to today |
| **Image** | No | PNG, JPEG, or WebP up to 5 MB. Recommended size: 720 × 480 pixels |
Click **Cancel** to close, or **Create** to publish. While creating, the button shows **Creating…**.
## Entry types
| Type | Use for |
| --------------- | -------------------------------------- |
| **New** | New features or capabilities |
| **Fix** | Bug fixes and corrections |
| **Improvement** | Enhancements to existing functionality |
## Optional image
Upload an image to accompany the entry. The upload dialog title is **Upload changelog image** with helper text:
> Recommended size: 720 × 480 pixels. PNG, JPEG, or WebP up to 5 MB.
Images appear on the changelog card in the timeline view.
## Public changelog
Visitors see all published entries on `{slug}.bettter.app/changelog` in read-only mode — they cannot create, edit, or delete entries.
## Next
Continue to [Editing a changelog entry](/2.manage-content/2.9-editing-a-changelog-entry) to update an existing entry.
# Editing a changelog entry
Source: https://docs.bettter.app/2.manage-content/2.9-editing-a-changelog-entry
Update an existing changelog entry from the Changelog tab.
You can edit any changelog entry after it is published. Changes appear immediately on both the dashboard and the public portal.
## How to open the edit dialog
1. Navigate to the **Changelog** tab at `/dashboard/[slug]/changelog`
2. Click any changelog entry card
3. The **Edit Changelog Entry** dialog opens
## Editable fields
The edit dialog includes the same fields as creation:
| Field | Details |
| --------------- | --------------------------------------------- |
| **Title** | 12–160 characters |
| **Description** | 40–4000 characters |
| **Type** | New, Fix, or Improvement |
| **Date** | Publish date via calendar picker |
| **Image** | Upload, replace, or remove the optional image |
Click **Cancel** to discard changes, or **Update** to save. While saving, the button shows **Updating…**.
Only the project owner can edit changelog entries. The public changelog is read-only.
## Next
Continue to [Deleting a changelog entry](/2.manage-content/2.10-deleting-a-changelog-entry) to permanently remove an entry.
# Primary settings
Source: https://docs.bettter.app/3.configure/3.1-primary-settings
Set your project name and slug — the subdomain your public portal lives at.
Primary settings define your project's identity and public address. They live in the **Primary** accordion of the project settings panel.
Open the panel from `/dashboard` — click the gear icon on a project card to **Edit project**, or **Add project** when creating a new one.
## Fields
| Field | Label | Required | Details |
| ----- | ----------- | -------- | --------------------------------------------------------------------------------------- |
| Name | **Name** \* | Yes | 1–32 characters. Placeholder: `"Enter project name (1–32 characters)"` |
| Slug | **Slug** \* | Yes | Subdomain prefix with `.bettter.app` suffix shown inline. Placeholder: `your-subdomain` |
**Slug helper text:** Lowercase letters, numbers, and hyphens only.
## Validation rules
| Rule | Error message |
| ----------- | ---------------------------------------------------------------------- |
| Name empty | Name is required |
| Name length | Name must be at least 1 character / Name must be 32 characters or less |
| Slug empty | Slug cannot be empty |
| Slug length | Slug must be 32 characters or less |
| Slug format | Slug must contain only lowercase letters, numbers, and hyphens |
Slugs are automatically lowercased as you type. Reserved slugs such as `www`, `dashboard`, and `docs` are blocked.
If you choose a slug that already exists, Bettter returns **"A project with this slug already exists. Please choose a different slug."**
## Your portal URL
Once saved, your public portal is available at:
```
{slug}.bettter.app
```
Changing the slug updates your portal address. Update any bookmarks or embed scripts that reference the old URL.
## Next
Continue to [SEO](/3.configure/3.2-seo) to configure your website URL, browser tab title, and search result description.
# SEO
Source: https://docs.bettter.app/3.configure/3.2-seo
Configure website URL, browser tab title, and meta description for search results.
SEO settings control how your portal appears in browser tabs and search engine results. All fields are optional — Bettter uses sensible defaults when left empty.
Open the **SEO** accordion in the project settings panel.
## Fields
| Field | Label | Details |
| -------------------- | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Website | **Website** | Your site's public URL. Input shows a `https://` prefix; placeholder: `example.com`. Helper: *Optional. Your site's public URL* |
| SEO title | **SEO title** | Browser tab title. Placeholder: `"Browser tab title (defaults to project name)"`. Helper: *Optional. Shown in the browser tab and search results*. Max 60 characters |
| SEO meta description | **SEO meta description** | Search snippet text. Placeholder: `"Short summary for search results"`. Helper: *Optional. Shown in search results*. Max 320 characters |
## Validation
| Field | Error |
| ------------------------- | -------------------------------------------------------------------------- |
| Website (if set) | Please enter a valid URL (e.g. [https://example.com](https://example.com)) |
| SEO title (if set) | SEO title must be 60 characters or less |
| Meta description (if set) | SEO meta description must be 320 characters or less |
Websites are normalized to `https://…` automatically. When set, a **Website link** badge appears in the public portal header.
## Defaults
If SEO title is empty, Bettter falls back to your project name. Meta description can remain empty — search engines will generate their own snippet from page content.
## Next
Continue to [Branding](/3.configure/3.3-branding) to customize colors, theme, fonts, language, and images.
# Branding
Source: https://docs.bettter.app/3.configure/3.3-branding
Customize brand color, theme, fonts, UI language, logo, favicon, and Open Graph image.
Branding settings control the look and feel of your public portal. Open the **Branding** accordion in the project settings panel.
Logo, favicon, and Open Graph image uploads are available after the project is created. During initial creation, uploads are disabled with the message *"You need to create a project first to upload a ."*
## Brand color
* **Label:** Brand color
* **Default:** `#c7ff10`
* **Control:** Color picker with hex value, eye dropper, and hue slider
* **Validation:** Color is required / Please enter a valid hex color (e.g. #c7ff10)
Brand color applies to buttons, accents, and the project header bar on your portal and widget.
## Theme
* **Label:** Theme
* **Options:** Light | Dark (tab picker with Sun/Moon icons)
* **Default:** Light
* **Helper:** Theme is applied to the public portal
## Font style
* **Label:** Font style
* **Placeholder:** Select font style
* **Helper:** Applies to page titles and card titles on the public portal
| Value | Label |
| ------------- | ----------- |
| `default` | Default |
| `sans_serif` | Sans serif |
| `serif` | Serif |
| `mono` | Mono |
| `handwritten` | Handwritten |
## UI language
* **Label:** UI language
* **Placeholder:** Select UI language
* **Helper:** System labels on the public portal are shown in this language
* **Default:** English
| Code | Language |
| ---- | ---------- |
| `en` | English |
| `es` | Spanish |
| `ru` | Russian |
| `fr` | French |
| `de` | German |
| `pt` | Portuguese |
| `it` | Italian |
Navigation labels, buttons, empty states, and form text on the public portal use the selected language.
## Image uploads
| Asset | Label | Recommended size | Formats |
| ---------- | --------------- | ---------------- | -------------------------- |
| Logo | Logo | 256 × 256px | PNG, JPEG, WebP up to 5 MB |
| Favicon | Favicon | 96 × 96px | PNG, JPEG, WebP up to 5 MB |
| Open Graph | OpenGraph Image | 1200 × 630px | PNG, JPEG, WebP up to 5 MB |
Upload via drag-and-drop or **Browse**. Server rejects unsupported formats, empty files, or files over 5 MB.
## Next
Continue to [Support settings](/3.configure/3.4-support-settings) to configure where support tickets are sent.
# Support settings
Source: https://docs.bettter.app/3.configure/3.4-support-settings
Set the support email and descriptive message for your public support form.
Support settings determine where visitor tickets are delivered and what message appears above the support form. Open the **Support** accordion in the project settings panel.
## Fields
| Field | Label | Placeholder | Helper |
| ------------------- | ----------------------- | -------------------------------------------- | -------- |
| Email | **Email** | `support@example.com` | Optional |
| Descriptive message | **Descriptive message** | How visitors can reach you or what to expect | Optional |
## Validation
| Field | Rule | Error |
| ---------------------------- | ------------------- | --------------------------------------------------- |
| Email (if set) | Valid email format | Please enter a valid email address |
| Descriptive message (if set) | Max 2000 characters | Descriptive message must be 2000 characters or less |
## Enabling the Support tab
Although the email field is labeled optional, a **valid support email is required** to enable the Support tab on your public portal.
* The **Support** toggle in **Controls** is blocked until a valid email is entered
* If email is empty or invalid when you save, the Support tab is forced off even if the toggle was on
See [Receiving support tickets](/2.manage-content/2.11-receiving-support-tickets) for how tickets are delivered and what the public form looks like.
## Descriptive message on the portal
When set, the descriptive message appears above the support form on `{slug}.bettter.app/support`. Use it to set expectations — for example response times or what information visitors should include.
## Next
Continue to [Controls](/3.configure/3.5-controls) to configure tab visibility, voting moderation, comments, and navigation.
# Controls
Source: https://docs.bettter.app/3.configure/3.5-controls
Configure tab visibility, open for voting, comments, and the shared navigation strip.
Controls let you choose which modules appear on your public portal and how visitors interact with features. Open the **Controls** accordion in the project settings panel.
## Tab visibility
Each tab has a switch and a copy-link button to copy the public URL for that section:
| Tab | Default | Copy button label |
| ------------- | ------- | ----------------------------- |
| **Features** | ON | Copy public link to Features |
| **Roadmap** | ON | Copy public link to Roadmap |
| **Changelog** | ON | Copy public link to Changelog |
| **Support** | ON | Copy public link to Support |
When a tab is disabled, it is hidden from public navigation. Visitors who navigate directly to a disabled tab see:
> The page is disabled by app owner ()
The **Support** toggle cannot be turned on until a valid support email is configured in [Support settings](/3.configure/3.4-support-settings).
## Open for voting
* **Title:** Open for voting
* **Default:** OFF
* **Description:** If active, then newly suggested features from your users will be immediately available for public view and voting. Otherwise, the status will be set as "Pending" and will proceed for your moderation.
This controls the **initial status** of visitor suggestions — not whether vote buttons appear. See [Voting](/2.manage-content/2.5-voting) for full voting behavior.
## Comments
* **Title:** Comments
* **Default:** ON
* **Description:** When disabled, visitors cannot post new comments on feature card detail pages. Existing comments remain visible.
See [Comments](/2.manage-content/2.6-comments) for how commenting works on the portal.
## Show shared tabs
* **Title:** Show shared tabs
* **Default:** ON
* **Description:** If active, the navigation menu appears at your public portal. Use the switches above to choose which tabs are included.
When **Show shared tabs** is off, the entire navigation strip is hidden on the public portal. Individual pages remain reachable by direct URL.
## Next
Continue to [Custom domain](/3.configure/3.6-custom-domain) to connect your own hostname (paid plans).
# Custom domain
Source: https://docs.bettter.app/3.configure/3.6-custom-domain
Connect a custom hostname like feedback.yourdomain.com and verify DNS.
A custom domain lets visitors reach your portal at your own hostname — for example `feedback.acme.com` — instead of `{slug}.bettter.app`.
Custom domains are available on paid plans (Basic, Pro, or Max). Free users see: *"Custom domains are available on paid plans (basic, pro, or max)."* with an upgrade option.
Open the **Custom domain** accordion in the project settings panel. Custom domain configuration requires an existing project — it is disabled during initial project creation.
## Hostname
* **Label:** Hostname
* **Placeholder:** `feedback.acme.com`
* **Validation:** Must be a valid FQDN with at least three labels (subdomain required). No protocol or trailing dot.
Examples: `feedback.acme.com` (valid), `acme.com` (invalid — needs a subdomain).
## DNS configuration
After saving your hostname, Bettter shows a **DNS configuration** section:
> Add a CNAME record pointing to cname.bettter.app.
| Type | Name | Target |
| ----- | -------------------------------------------- | ------------------- |
| CNAME | First label of your domain (e.g. `feedback`) | `cname.bettter.app` |
**Important!** This can take up to 3 minutes to connect your domain. DNS changes can take up to 48 hours to propagate globally.
## Verification status
Bettter polls DNS automatically and shows a status badge:
| Badge | Meaning |
| ----------------------- | -------------------------- |
| connection successful | Domain verified and active |
| connection unsuccessful | DNS not yet correct |
While unverified, you may see: *Checking again automatically in s...*
Common connection issues:
* **No CNAME record detected** — Add a CNAME at your DNS provider pointing to `cname.bettter.app`
* **Wrong target** — Update the CNAME to point to `cname.bettter.app`
* **Propagating** — DNS changes can take up to 48 hours
## Remove custom domain
Click remove to open the **Remove custom domain** dialog. Confirm with **Yes** (shows **Removing…** while in progress).
Changing the hostname may cause the previous domain to return 404 until DNS is updated.
## Next
Continue to [Widget](/3.configure/3.7-widget) to embed your portal on your own website (paid plans).
# Widget
Source: https://docs.bettter.app/3.configure/3.7-widget
Embed an interactive widget on your website with a trigger button and configurable sections.
The embeddable widget lets visitors access your feature board, roadmap, changelog, and support form directly from your website — without navigating to your portal URL.
The embeddable widget is available on paid plans (Basic, Pro, or Max). Free users see: *"The embeddable widget is available on paid plans (basic, pro, or max)."* Widget configuration requires an existing project.
Open the **Widget** accordion in the project settings panel.
## Trigger
The button visitors click on your website to open the widget.
* **Description:** The button visitors click on your website to open the widget
* **Position:** Left | Right (default: Right)
* **Text:** Default `"What's new"` (max 40 characters)
* **Colors:** Uses your project brand color with automatic contrast for readable text
## Sidebar position
Choose where the widget panel slides in from:
* **Left** or **Right** (default: Right)
## Sections
Choose which sections appear in the widget sidebar. All default to ON:
* **Features**
* **Roadmap**
* **Changelog**
* **Support**
At least one section must be enabled before you can publish the widget.
## Install script
Copy the embed script from the **Install script** section:
```html theme={null}
```
Add the script to your website or app HTML.
Click **Test connection**, then reload your website. Bettter shows **Connected** or **Not connected**.
**Important!** Reload your website where you've installed the widget code. This step is required to activate the widget.
## Publish and branding
| Switch | Description |
| ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Publish widget** | Makes the widget visible to visitors after install is verified. Unpublish to hide instantly while keeping the script in place. Disabled until connected — helper: *Install and test the script first* |
| **Hide Bettter branding** | Hides the Powered by Bettter footer from visitors. The Bettter homepage link remains in the page for SEO. |
Pending features are hidden from the widget Features section, same as the public portal.
## Next
Continue to [Email notifications](/3.configure/3.8-email-notifications) to get alerted about new features, comments, and status changes.
# Email notifications
Source: https://docs.bettter.app/3.configure/3.8-email-notifications
Configure notification email and toggles for new features, comments, and voter status updates.
Email notifications keep you and your users informed about activity on your portal. Open the **Email notifications** accordion in the project settings panel.
Email notification configuration requires an existing project. During creation, the notification email field is disabled with: *"You need to create a project first to configure email notifications."*
## Notifications for you
| Switch | Description | Default |
| --------------------------- | --------------------------------------------------------- | ------- |
| **New feature suggestions** | Email me when someone submits a new feature on my board. | OFF |
| **New comments** | Email me when someone leaves a comment on a feature card. | OFF |
When either toggle is ON, a **Notification email** is required:
* **Label:** Notification email
* **Placeholder:** `you@example.com`
* **Validation:** Please enter a valid email address
* **Server error if missing:** Notification email is required when email notifications are enabled
If unset, Bettter defaults to your account email.
## Notifications for your users
Under the subheading **Notifications for your users**:
| Switch | Description | Default |
| -------------------------- | -------------------------------------------------------------------------------------------------- | ------- |
| **Roadmap status updates** | Email users who voted on a feature when its status changes to Planned, In development, or Shipped. | OFF |
Voter notifications do not require a notification email address — they are sent to users who voted on the feature.
## Tips
* Enable **New feature suggestions** if you use **Open for voting** OFF and want to know when pending items arrive
* Enable **Roadmap status updates** to automatically notify voters when you move features through your pipeline
* Pair **New comments** with the [Comments](/2.manage-content/2.6-comments) toggle to stay on top of discussions
## Next
Continue to [How the public portal works](/4.public-portal/4.1-how-the-public-portal-works) to see what your configured portal looks like to visitors.
# How the public portal works
Source: https://docs.bettter.app/4.public-portal/4.1-how-the-public-portal-works
Your portal at slug.bettter.app or a custom domain — branded chrome, tabs, search, and disabled sections.
The public portal is what your customers see when they visit your feedback board. Everything you configure in the dashboard — branding, tabs, controls — shapes this experience.
## Portal address
Your portal lives at one of these URLs:
| Type | Example |
| ------------------------ | --------------------------------- |
| Default subdomain | `https://{slug}.bettter.app` |
| Custom domain (verified) | `https://feedback.yourdomain.com` |
Public routes (no slug prefix on subdomain or custom domain):
| Tab | Route |
| -------------- | ------------- |
| Features | `/` |
| Roadmap | `/roadmap` |
| Changelog | `/changelog` |
| Support | `/support` |
| Feature detail | `/{cardSlug}` |
Card slugs are 16-character hex strings assigned automatically when a feature is created.
Explore a live example of the branded portal with all four tabs.
## Branded chrome
The portal applies your project branding automatically:
| Element | Source |
| ------------------- | ------------------------------------------------------------ |
| Light/dark theme | [Branding → Theme](/3.configure/3.3-branding) |
| Brand color | [Branding → Brand color](/3.configure/3.3-branding) |
| Font style | [Branding → Font style](/3.configure/3.3-branding) |
| UI language | [Branding → UI language](/3.configure/3.3-branding) |
| Logo + project name | Header left |
| Website link badge | Shown when website URL is set in [SEO](/3.configure/3.2-seo) |
## Tab navigation
When [Show shared tabs](/3.configure/3.5-controls) is enabled, visitors see a navigation strip with your enabled tabs:
* **Features** · **Roadmap** · **Changelog** · **Support**
On mobile, tabs show icons only. On larger screens, they show text labels. The active tab is highlighted.
Feature detail pages show the brand header but no tab navigation or search — only a **Back** link to the Features board.
## Search
Search is available on Features, Roadmap, and Changelog — not on Support or feature detail pages.
* Open/close via the search icon (**Open search** / **Close search**)
* Placeholder: **Search...**
* Filters title and description on Features and Roadmap; filters changelog entries on Changelog
* Closes automatically when navigating to another page
## Disabled tabs
When you turn off a tab in [Controls](/3.configure/3.5-controls):
* The tab disappears from navigation
* Direct URLs still load but show: **The page is disabled by app owner ()**
When **Show shared tabs** is off, the entire navigation strip is hidden. Pages remain reachable by direct URL.
## Owner preview
Open your portal from the dashboard using **Open public portal** in the project header, or the external-link icon on the project card at `/dashboard`. Both open `{slug}.bettter.app` in a new tab.
## Next
Continue to [What visitors can do](/4.public-portal/4.2-what-visitors-can-do) for a breakdown of visitor capabilities and sign-in requirements.
# What visitors can do
Source: https://docs.bettter.app/4.public-portal/4.2-what-visitors-can-do
Browse features, roadmap, and changelog; submit support tickets; suggest, vote, and comment when enabled.
Visitors interact with your portal without needing an account for most actions. Signing in unlocks suggesting features, voting, and commenting.
## Browse without signing in
| Tab | What visitors can do |
| --------------- | ----------------------------------------------------------------------------------- |
| **Features** | View the board (no pending cards), filter by status, sort, search, open card detail |
| **Roadmap** | View Planned / In Development / Shipped columns, search, use mobile section tabs |
| **Changelog** | Read entries, filter by search |
| **Support** | Submit a contact form with optional bug report and screenshots |
| **Card detail** | Read feature description, vote counts, and existing comments |
**Pending features** are never visible on the public portal — not on the board, roadmap, search, or direct URLs.
## Features board
**Page title:** Features
**Status filters:** All, Open for voting, Planned, In development, Shipped (no Pending option)
**Sort options:** Most voted, Least votes, Newest, Oldest
**Empty states:**
* No cards: *"Be the first to suggest a new feature for this project"*
* Filter empty: *"Try selecting a different status filter."*
* Search empty: *"Try a different search term."*
Vote buttons are visible on all non-pending cards. Clicking without signing in opens an auth dialog.
## Actions that require sign-in
| Action | Sign-in | Additional requirement |
| ----------------------------------- | ------- | ----------------------------------------------- |
| Browse features, roadmap, changelog | No | Pending hidden |
| Search | No | — |
| Open card detail | No | Pending → 404 |
| Read comments | No | — |
| Submit support ticket | No | Support email configured |
| Suggest feature | **Yes** | — |
| Vote | **Yes** | — |
| Post comment | **Yes** | [Comments](/3.configure/3.5-controls) toggle ON |
| Like / delete own comment | **Yes** | — |
## Suggest a feature
Click **Suggest new feature**:
* **Unsigned:** dialog titled **Please sign up** — *"Sign in or create an account to suggest features and vote."*
* **Signed in:** **Suggest new feature** dialog with Title and Description
After submitting:
* **Open for voting ON:** *"Your idea is live on the board — others can vote on it now."*
* **Open for voting OFF:** *"Your idea has been received. We'll review it shortly..."*
See [Creating a feature](/2.manage-content/2.1-creating-a-feature) for field requirements.
## Vote and comment
* **Vote:** Upvote button on board and detail page. Unsigned users see **Sign in to continue** on detail pages.
* **Comment:** Available on card detail pages when Comments is enabled. Compose box hidden when disabled; existing comments remain visible.
## Roadmap and changelog
The public **Roadmap** is read-only — no drag-and-drop. Vote buttons are hidden; vote counts still display.
The public **Changelog** is read-only. Entry type badges: **New**, **Fix**, **Improvement**.
## Support
No sign-in required. Form fields: Your Name, Your Email, Subject, Message, optional Screenshots, and **Reporting a bug?** toggle.
If support email is not configured, visitors see a warning that tickets cannot be sent until the owner adds one.
See [Receiving support tickets](/2.manage-content/2.11-receiving-support-tickets) for delivery details.
## Next
Continue to [Signing in on the portal](/4.public-portal/4.3-signing-in-on-the-portal) to understand the authentication flow.
# Signing in on the portal
Source: https://docs.bettter.app/4.public-portal/4.3-signing-in-on-the-portal
How portal sign-in works for voting, suggesting, and commenting — and how it differs from the owner session.
Portal sign-in uses the same Google authentication as the owner dashboard, but the session is scoped to visitor actions — not admin capabilities.
## When sign-in is prompted
Visitors are prompted to sign in when they try to:
* Suggest a feature
* Vote on a feature
* Post, like, or delete a comment
Browsing the board, roadmap, changelog, and support form does not require sign-in.
## Auth flow
```mermaid theme={null}
flowchart LR
action[Visitor action] --> dialog[Sign in dialog]
dialog --> apex["bettter.app/sign-in"]
apex --> bridge["Auth bridge"]
bridge --> portal["Return to portal"]
```
Visitor clicks Suggest, Vote, or Comment without being signed in. A dialog appears with **Sign in** and **Sign up** buttons.
Bettter redirects to `bettter.app/sign-in` with a return URL pointing back to the portal page they were on.
After authentication, an auth bridge sets the session cookie on the portal host and redirects the visitor back to their original page.
The visitor can now suggest, vote, or comment. **Sign Out** appears in the top-right corner of tab pages.
Sign-in works on both `{slug}.bettter.app` and verified custom domains.
## Sign-in dialogs
| Context | Dialog title | Body |
| ------------------------ | ------------------- | --------------------------------------------------------------------- |
| Suggest / vote on board | Please sign up | Sign in or create an account to suggest features and vote. |
| Vote / comment on detail | Sign in to continue | Create an account or sign in to vote and comment on feature requests. |
Buttons: **Sign in**, **Sign up**, or dismiss.
## Sign out
When signed in, visitors see **Sign Out** in the top-right of portal tab pages (Features, Roadmap, Changelog, Support). Feature detail pages do not show Sign Out in the header.
* Click **Sign Out** → shows **Signing out…** while processing
* After sign-out, the visitor stays on the same portal page as a guest
## Portal session vs owner session
| Aspect | Public portal | Owner dashboard |
| -------------------- | --------------------------- | ---------------------------------- |
| Browse without login | Yes | No — `/dashboard` requires session |
| Auth provider | Google (NextAuth) | Same |
| Sign-in page | Apex via auth bridge | Apex with redirect to dashboard |
| Sign-out behavior | Stay on current portal page | Redirect to sign-in |
| Permissions | Vote, suggest, comment | Full CRUD, settings, moderation |
Signing in on the portal does **not** grant dashboard access. Only the project owner can manage content and settings from `/dashboard`.
The same Google account can be both a portal visitor and a project owner, but each context has separate permissions. Owner actions always require signing in at `bettter.app/dashboard`.
## Next
You have completed the documentation. Return to the [documentation home](/) or explore the [Bettter demo portal](https://bettter.bettter.app) to see everything in action.
# Documentation
Source: https://docs.bettter.app/index
Learn how to set up and manage your Bettter feedback portal.
Bettter is a one-time-payment customer feedback platform. Use these docs to create projects, manage features, configure your portal, and share updates with your users.
What Bettter is, how projects work, and how to open your dashboard.
Feature cards, roadmap, changelog, and support tickets.
Branding, SEO, custom domain, widget, and notifications.
What visitors see and how they interact with your portal.
All four documentation sections are available: Getting started, Manage content, Configure, and Public portal.