Administration, guard rails and the demo

Four ways to be a user#

Organization → Users lists everyone, and each row carries one control that answers what they are to you. The email address beneath a person's name, or the key fingerprint beneath an agent's name, shares the name's left edge so the roster scans as one identity column:

Org admin — reaches every project without being granted any.
Standard user — reaches what they are added to, and nothing else.
Viewer — reads what they are added to, and writes nothing. A viewer signs in and works normally in every direction that doesn't change anything: they read boards, roadmaps, tasks, comments and history for each project they have been added to, and nothing else exists for them. They cannot be given a task, cannot comment, and cannot rename a label. They can subscribe to a task (§11) — following one is reading it, not writing to it, and a viewer watching a risk is exactly who the eye is for. The role is a ceiling (§12), so it holds however generous a project role they were given — which is what makes it one setting rather than an audit of every grant.
Two things follow from it, and the app enforces both. A viewer leads nothing: you can't make one a project lead or a team leader, and you can't turn a lead into a viewer — you'll be told what to hand over first ("Anna Fält leads 3 project(s)"). And a viewer can't be handed new work — but switching someone to Viewer takes nothing away: every task already on their name stays exactly where it is, and their project access is untouched, so switching them back restores them completely. A viewer takes a seat like anyone else — being read-only is not the same as being unpaid for.
Inactive — switched off. They reach nothing, and they stop counting toward the next renewal. Everything they ever did stays exactly where it is: tasks they created, comments they wrote and their name throughout the activity feed all still read normally, which is the difference between switching someone off and removing them. Work already assigned to them stays assigned, and tasks they review keep them as reviewer; new work cannot be handed to them until they are switched back on. Removing someone instead clears them as assignee and as reviewer. Reactivating them restores access and makes them count at the next monthly renewal; no purchased-seat limit blocks it.

You can't switch yourself off — it would take effect at once with nobody left signed in to undo it — and you can't switch off the last admin, for the same reason you can't demote them.

Agent users#

An agent is a user that is not a person: no email address, no password. It is given a name and an API key, and that key is its login. Create one from the same Users page — choose Agent instead of Person, type a name, and the key appears once. Copy it then; only its hash and a safe fingerprint like qva_d9e...58b76 are stored, so the full key can never be shown again. That fingerprint appears under the agent's name where a person's email would be. (Mint a second key any time from the agent's row to rotate: move the client over, then revoke the old one.)

An agent is a user in every other respect, and that is the point:

It reaches only the projects you add it to — the same Viewer / User / Lead roles you give a person, on each project's own page. It can never be an org admin, so a leaked key is never more than the work it was trusted with.
It can be read-only. Set an agent to Viewer and its key reads and changes nothing, anywhere — which is what a reporting job, a dashboard or a status bot actually wants, and it is one setting rather than a per-project audit you have to keep right.
It has no plannable week. A person has a number of hours available each week and Qivo plans against it (§10); an agent doesn't, and pretending otherwise made the planning worse — an agent given the default week showed as over capacity and had its work spread across calendar weeks it didn't need. So its row reads "no weekly limit" instead of an h/wk field, its work is never stretched to fit, and it is never shown as overloaded. On the Team strip its row writes the hours it is committed to each week rather than a percentage of nothing. This is a simplification, deliberately: a real agent does have limits — a rate limit, a budget, a queue — but none of them is a number of hours in a week, so Qivo doesn't claim to know one.
It signs its own work. Tasks it creates and changes it makes name the agent in the activity feed, and comments it posts are authored by it — not an anonymous "Someone".
It takes a seat, and switching it to Inactive stops every key it holds at once, without your having to revoke them one by one.

The key opens both machine surfaces: the REST API and the MCP server, so one credential serves a script and an AI assistant alike. See docs/rest-api.md and docs/mcp.md.

The Northstar Labs demo employs one, so you can see all of the above without creating anything: Atlas sits in the Users list beside the seven people, with the agent chip, "no weekly limit" where they have hours, and a place on both teams. It ships without a key — mint one from the agent's row to actually use it.

The Northstar Labs demo uses Luma Sensor, Luma Cloud and Pilot & Launch to show a connected product from development to customer rollout. Its seven fictional teammates and Atlas have reusable profile images; Nora is the organization admin. Northstar Hardware is led by Leo; Northstar Cloud & Launch is led by Daniel. Some people belong to one team, while Nora, Sofia and Atlas belong to both. The product projects span both teams, and explicit team shares give each team the intended view. Task reporters follow the project leads. Every profile starts with Inbox notifications, and each main project contains two archived tasks. Eight of the nine In Review tasks name a reviewer, so they sit in the reviewers' board lanes and count toward their workload, and each of those reviewers starts with a Ready for your review message. Every task, including parents and archived tasks, has one to five sample comments about its work. Teams, human weekly capacity and read-message retention use Qivo's normal defaults on reset. The seed schedules dependent tasks after their blockers and keeps planned ends within due dates. An operator can rebuild this dedicated dataset with fresh dates while retaining its logins and portraits. This is an operator script, not an Organization Settings action; the setup and reset scope are in docs/marketing-demo.md.

Users & billing counts: Organization → Users is the only door into the org. You cannot remove yourself, demote or switch off the last admin, or delete the last team. Adding, promoting or reactivating a user is not blocked by a purchased-seat cap. The page also lists Guests separately, with their projects and roles. An active guest counts toward billing only while they have no active home membership (§12).
Projects: Settings → Projects → All projects lists every project you can open as the sidebar's tree, grouped by organization: click a project to reveal its sub-projects, click a sub-project to open its page, and open a project's page from its "…" menu. Eligible organization staff can open New project, which asks for a name, lead and optional team/user shares. Project settings starts with Name, then the product description and lead. Sub-project settings also expose the sub-project lead and project access. The description accepts up to 500 characters, and its field grows and shrinks to fit the content. Click outside to save; an empty field clears the description. In Delay tracking, the yellow and red explanations appear on separate lines. Review time, below Delay tracking on project and sub-project pages, sets the remaining hours a task gets when it moves into In Review (§7); only Lead access can change it, and a sub-project's empty box follows its project.
Signing up: choose Create an account on the pricing page or the sign-in screen. Qivo confirms the address before that account can do anything with it. It mails a link that expires after an hour; a login that has not followed one waits on a Confirm your email address screen, which sends another on request. (Signing in with Google skips the step — Google has already confirmed the address. Microsoft has not, so it does not.) Confirming is what proves the address, and therefore what claims whatever is waiting on it: if a colleague or a client has already invited that address, the seat is theirs as soon as they confirm; if nobody is expecting them, Qivo offers to create an organization with them as its first admin. When billing is enabled, a new unpaid organization opens Billing so its admin can subscribe. Nobody can award themselves a seat in an organization that did not invite them.
Destructive actions don't use popup dialogs: dangerous buttons use a two-click arm-then-confirm. Compact trash buttons expand to Delete? on the first click while keeping their danger color; larger controls spell out the consequence (for example, "Click again — deletes N tasks"). Timed confirmations disarm themselves after a moment.
Team and project settings render read-only for those who don't run them, with explanatory hints instead of vanished controls; the Organization pages (Users, Billing, Labels, General) appear for org admins only. Teams is the one exception, and it is the same rule in a different place: anyone who leads a team reaches it, and it lists exactly the teams they can manage — creating and deleting a team stays an org admin's.
Billing is available to organization admins and shows the assigned plan, billable accounts, renewal date and usage. Subscribe opens Polar card checkout; Manage billing opens the customer portal for payment details, invoices and cancellation. Payment confirmation activates access automatically.
Demo: the Northstar Labs demo ships a cast of logins (nora@demo.qivo.io and six more; private passwords on a development deployment, qivo-demo on a Vercel preview) spanning org admin, team leaders, project leads and users — grant someone Viewer yourself to try that seat — ideally in two browsers side by side to watch the realtime sync. Rebuilding the pristine dataset is a job for whoever runs the deployment, done with the deployment's own CLI (npx convex run …) — Qivo itself has no wipe-and-restore button. Deleting is always something you aim at a named project or a named team, always confirmed, and always checked against the rights you hold over that project or team. Be aware that deleting a parent project takes its sub-projects and their tasks with it, while deleting a team removes memberships and sharing grants but preserves project work.

Billing and free access#

Billing is enabled per deployment. When it is disabled, the Billing page says so and the organization remains usable. An unconfigured deployment does not accept payments. Once enabled, an organization needs a paid subscription or complimentary access to edit its work; personal account settings and existing readable work remain available when organization editing is paused.

Each organization keeps an immutable named plan version. Changing the plan offered to new customers leaves existing organizations' prices and allowances unchanged. The published monthly plan is $1 per active billable user, with a five-user minimum. People, viewers and agents count as soon as added, including pending invitations. Admins can add or deactivate users without purchasing capacity first; the current count at renewal sets the next month's user charge, with no mid-month proration or credit.

The Billing page lists billable and non-billable accounts by name. The active and inactive counters use the same style and wording, such as 7 active users and 1 inactive user. Inactive users is shown even at zero; Invited users with their own billing appears only when an active invited guest has an active home membership. Inactive guests count only in the inactive total. Above the active-user counter, a short note reads: "People, viewers and agents count, unless they are inactive." Invitation timing and guest eligibility follow the rules documented here; the account lists show names without repeating a reason beside each name.

The page also shows shared storage and API allowances, API usage by account and key or OAuth connection, and storage by project. Refresh reads current usage. API calls accumulate across the subscription period. Storage is sampled at the start of the period; its recorded extra charge, together with the period's API overages, is collected on the following renewal invoice. The current stored bytes can therefore differ from the sample that produced that period's charge. Polar handles checkout taxes and recurring payments.

An operator can grant six calendar months free, including user charges and storage/API overages, without a card. The paid plan stays assigned. Organization admins receive reminders before expiry; Subscribe becomes available when free access ends. Without a subscription, editing pauses while existing work stays readable. Free-period usage is not charged retroactively.

Polar retries failed payments, and an admin can update payment details in its portal. Qivo allows seven days from the recorded past-due state before pausing editing. An otherwise active paid period has a 24-hour grace for delayed renewal confirmation. Cancellation at period end preserves access through the paid period; restoring payment restores editing without operator intervention.

Qivo Admin at /admin has its own sign-in session. You can keep the app open as your regular account while signing into Admin with your operator account. Signing in, changing accounts or signing out in one area does not change the other area's login. Each area remembers its own session across reloads.

The accounts and passwords are the same as before, and Admin still requires platform-operator access. When this separation is introduced, Admin asks you to sign in again; the app keeps its existing session.

Billing plans in Qivo Admin creates named, immutable monthly plan versions. A draft can be connected once to its matching Polar product and usage meters; Use for new customers changes the default without changing existing organizations. Open an organization to assign its plan before checkout or grant six calendar months free. Repeating a free-access grant extends its existing end date. Plan changes and grants appear in the operator audit log.

The Dashboard also includes the Demo workspaces created graph at the end of its report, using the same period selector, comparisons and data table as the Demos page when reporting is connected.

Demo usage — platform operators#

Open Qivo Admin → Demos on the regular Qivo site to see activity from the separate 24-hour demo service. Reporting must first be connected by whoever manages the deployment. The demo site itself has no operator console. On phones, the admin sections appear in a horizontally scrolling navigation bar at the top. Swipe across a graph to inspect more dates, or open its data table.

The page shows Total recorded, Last 7 days, Last 12 months, the previous calendar year's total and active demos, plus how many provisioned workspaces are being cleaned up. Expired and deleted demos remain in recorded totals. Opening the welcome page or abandoning sign-in does not count as a created workspace; repeating creation for the same workspace counts once.

Choose seven days, 30 days or 12 months for the creation graph. Blue bars show the selected period and amber bars show the preceding seven days, 30 days or 12 calendar months. The legend names both date ranges; hover, focus or open the data table to compare individual values. The current day and month are still in progress. All periods use UTC. Daily history lasts 800 days, while the recorded lifetime total remains. The page states when recording began: earlier demos already deleted cannot be recovered, and incomplete periods show recorded values.

Demo visitors breaks down created workspaces by browser, operating system and country for the selected period, with counts and percentages. One person creating two workspaces counts twice. Browser/OS details can be misreported; country is approximate and can be affected by VPNs. Missing details appear as Unknown. These analytics retain broad categories, not IP addresses, raw browser identification strings or precise locations.

Demo storage shows the latest approximate app-database size, uploaded-file size and a graph of daily averages. Samples arrive hourly, while usage reports reach Admin every 15 minutes. Refresh reads the latest received report; old reports and storage samples are labelled. Missing samples appear as gaps. Use graph hover/focus, arrow keys or View data table to inspect values.

Estimated monthly cost prefills Convex Professional's Europe storage rates: USD 0.26 per GB/month for the database and USD 0.039 per GB/month for files, checked on September 15, 2026 against Convex's published rates. Edit the prices, currency and optional other costs as needed. Saved custom prices remain in that browser; Use Convex Professional EU rates restores the preset. A saved non-USD currency with blank prices stays blank until you enter prices or choose the USD preset. Storage units follow Convex's dashboard: 1 GB = 1,073,741,824 bytes. The estimate projects a month at the average storage sampled so far this month and shows how many days were sampled. It is not a bill: database size excludes authentication and index overhead, and bandwidth, compute, provider minimums and other charges are excluded unless entered separately. Included allowances and tiered prices are not calculated automatically. Professional's included 50 GB of database storage and 100 GB of file storage are shared across the team and are not subtracted from this estimate; the developer subscription is also excluded.

Background images — platform operators#

Add images through Upload images. Choose one file, review its Title, optional Location and Creator, then select Save image. Windows/EXIF Title, Subject and Authors metadata prefill these editable fields. Saving confirms the permission statement shown in the form and names the file from the first 20 characters each of Title and Creator, with lowercase words separated by dashes and an underscore between the two parts, such as misty-mountain-peaks_sam-lim.jpg. The image bytes and full entered details are preserved.

You can also select multiple images in the file picker. Suitable files with an embedded title and author upload automatically and enter Pending review. Files missing either field are skipped; the result shows how many were skipped and explains that title or author metadata was missing. It also reports files that could not be uploaded and images already in the library. To enter missing details yourself, choose that image on its own.

Review saved images separately and assign approved images in Calendar. The calendar lists Week 1 through Week 53. Each Monday–Sunday assignment repeats every year until you replace it; there are no year or month filters. Week 53 can always be configured and is used in years that contain it. In Board preview, Approve and next approves the displayed pending image and opens the oldest remaining pending image matching the selected agent-precheck filter, including images on later library pages. The preview stays open and reports when the review queue is empty. If loading the next image stalls, it offers retry and Close after ten seconds; the image remains approved. Approval makes an image available for selection; it does not assign a calendar week. The library has no automatic provider import, scheduled refill, reserve target or refill-settings dialog.

Image cards and preview windows show the Original resolution and file size, plus the compressed Preview resolution and file size when available. The generic uploader-permission label is omitted below saved images; provider-license links remain visible when supplied. When choosing a default or calendar image, the results and selected image show available Title, Location and Creator on separate rows. Long text wraps to fit the window, and Preview in board has its own row below the selected image's details.

Administration instructions for Qivo Admin → Background images are in the background image library guide.