Storefront and Portal
The storefront is where a Startup sells to people and Agents; the Portal on its own Site is where each Customer receives what they bought.
The storefront is where a Startup sells: its public Site, its checkout, and the routes Agents buy through. The Portal is where each Customer receives what they bought, on the same Site.
The storefront follows the Product
Every storefront renders its Offers from records, and each kind of Product adds the routes its buyers need:
| Product kind | Storefront routes |
|---|---|
| Data | /docs, sample records, and the Dataset schema |
| Software | /docs, /pricing, and a sign-up that issues an API key |
| Agent | /docs, /pricing, and the tasks the Agent is graded on |
| Service | /how-it-works, /book, and a statement of what done means |
A Service states its done criteria on the Site because its Outcome Contract does. A buyer reads the same terms the Startup is held to.
Checkout
Checkout turns an accepted Offer into an Order or a Subscription. Stripe takes the payment and pays out to the bank account of the Startup. The Customer leaves checkout with an Entitlement and a link to the Portal.
Agents buy through the same Offers without a checkout Page. An Agent calls the API or the MCP server, and an unpaid call returns payment required with the Offer to accept. The Agent accepts and retries, and the Startup records a Customer like any other.
Every Page of the storefront lists the same Offers the API sells. A buyer and the buyer's Agent never see two price lists.
The Portal
The Portal lives at /portal on the canonical Domain of the Startup, under its Brand. It is part of the Site, not a separate App, so a Customer never leaves the address they bought from.
A Customer signs in and sees only the records of their own Tenant. Every Portal follows one sequence, and each Product shows the steps it needs:
- What the Customer bought, in one summary.
- Who is buying: the person, and the Organization they buy for.
- An onboarding checklist.
- Intake: the inputs the work needs.
- The budget and the acceptance criteria.
- Payment.
- A status timeline of the work.
- A Thread for questions in both directions.
- Deliverables, with the Evidence behind each.
- Review: accept, refund, or repeat.
- History of every Order and Invoice.
A returning Customer skips the steps already done and starts at intake. A Software Customer sees keys, usage against each Meter, Invoices, and their plan. A Service Customer sees intake, the timeline, deliverables, and the accept button.
Customer Roles
Inside a Tenant, people and Agents hold customer Roles. Every Product Template declares the Roles its Customers need, and the Portal shows each Role its own view of the same records.
Take scorehall.com, a Marketplace where composers license music to video producers. A production studio's Tenant holds a buyer who licenses tracks, an admin who manages seats, and the studio's own Agent, which licenses through the API.
Each composer is a Customer too, under a seller Agreement, with a seller view of tracks, sales, and payouts.
| Role | Sees | Can do |
|---|---|---|
buyer | Orders, licenses, Threads | Order, accept, dispute |
admin | Seats, plan, Invoices | Invite, remove, change plan |
seller | Listings, sales, payouts | List, update, withdraw |
agent | What its Mandate grants | Act by API, within its Limits |
The Components are shared across every Startup, so a Customer who buys from two Startups already knows how both Portals work.
Done is not accepted
For a Service, delivery and acceptance are separate Events. The Startup marks an Order delivered; the Customer then accepts it in the Portal, or disputes it under the Outcome Contract. Billing follows acceptance, not delivery.
A dispute starts the remedy the contract names, such as a redo or a refund. Each step lands in the Thread and the timeline, so the Customer and the Startup read one record of what happened.
View as any Customer
Owners preview the Portal as any Customer and any Role, and the Site as a Visitor or an Agent. The preview uses that reader's visibility exactly, so what an owner sees is what that Customer sees.
Portal ready is a Live entry check. It passes when the Portal shows each Customer their Orders, deliveries, Invoices, and Messages.
Next
- Sites and Pages: how the Pages around the storefront are built.
- SiteBuilder: everything SiteBuilder ships, by Lifecycle state.