// roadmap
Where this is going, and how far it actually is.
Four directions the product is being built along, and how far each one is. Shipped means a merchant can use it today — a claim you can check by opening the product. Plans change, and nothing here is a delivery date.
// 01
Any seller, not only Shopify
- Shipped
Businesses with no Shopify store run the same product
SaaS, courses and services use the same dashboard on the same URLs. The surfaces that genuinely need a storefront are hidden; everything else — the Brain, ads, organic search, customer service, tracking, performance — is the same engine.
- Shipped
Bring your own backend
A business that does not sell through a storefront serves its own catalogue, orders and customers from its own endpoint against a published contract. No database access, no bespoke pipeline per customer.
- Building now
More than one ad platform on the same rails
Pausing, resuming and re-budgeting are platform-neutral verbs behind one connector contract, so a second ad account inherits the approval model, the spend ceilings and the decision log instead of re-earning them. Reddit is the first one through; Meta is connected and not yet steering spend.
- Next
A catalogue shape for sellers with no storefront
A plan, a course or a service is what Google Shopping serves for a business with no products page, and the feed surfaces already turn on when a tenant genuinely has something to list. Making that catalogue first-class — priced, versioned, editable — is the next piece.
- Exploring
Other storefront platforms through the same connector
WooCommerce, BigCommerce and the headless stacks fit the connector contract on paper. Nothing has been built and no such tenant exists, so this is a question rather than a plan.
// 02
An API before it is a screen
- Shipped
A published contract with a support window
Every operation carries a scope and a risk tier, OpenAPI 3.1 is served from the product itself, and removing an operation or widening a read into a write fails our own build. Deprecations carry a 365-day window and the headers that announce it.
- Shipped
A remote MCP server and scoped API keys
OAuth 2.1 for an application, scoped keys for a script. Both reach the same operations, both are audited call by call, and a revocation is refused at the next request rather than at the next hour.
- Shipped
A typed client generated from the contract
The TypeScript SDK is generated from the OpenAPI document the product serves, so it cannot describe a surface the server does not have.
- Building now
Events out, so nobody has to poll
Signed CloudEvents delivered per subscriber, published once and retried independently, so a partner learns that an order refunded rather than asking again. The machinery is in place and the first producers are being wired.
- Building now
A partner can supply facts the platform does not hold
A merchant allowlists a partner's own MCP server and the Brain reads it as evidence. Read-only by construction — a partner supplies facts, never actions — so there is no second route to anything that acts.
- Exploring
Running the product under somebody else's brand
Agency workspaces already hold client stores with their own access and reporting. Whether that extends to a partner's own domain and their own login is open.
// 03
Agents are users too
- Shipped
An application executes as itself, not as you
A third-party app carries its own identity and the stores its grant names, intersected with what the granting person can reach. An app naming a store its user cannot open gets nothing.
- Shipped
What an agent writes still passes the approval model
A write from an outside client renders the same approval card as a write from the Brain, and money moves carry the same ceilings. An agent gets the reach a person granted it and none of the exemptions.
- Building now
Surfaces an agent can ask rather than scrape
The read side is broad and uneven: some questions are one operation and others need four. Filling the gaps so a merchant's own assistant can answer an ordinary question in one call is ongoing work.
- Next
Saved workflows a merchant can name
A sequence somebody runs every week should be a thing they can save, share inside the workspace and call from their own client, instead of a prompt they retype.
// 04
Every number carries its measurement
- Shipped
Every decision keeps the evidence it was made on
A proposal records what it read, what it expected, what the policy layer allowed and what actually happened, so a verdict can be re-read months later rather than taken on trust.
- Shipped
Work that runs reports what it did and what it skipped
A sweep books its own row with its counters, including the rows it deliberately passed over — an exclusion nobody counts is indistinguishable from a quiet day.
- Building now
Scoring the platform's own forecasts
A proposal states what it expects to move. Comparing that against what happened — including for proposals that were never dispatched — is what turns confidence into something earned rather than declared. It works well for paid search and reaches far less of the rest.
- Exploring
History that a late refund cannot rewrite
Storing events rather than derived metrics, so a refund that lands in March cannot silently change what February reported, and a redefinition can be replayed instead of re-pulled. The design is written; none of it is built.
// the record
And what already landed.
// tell us
Something here matters to you?
What gets built next is decided partly by what merchants ask for, and every shipped change names the reports it closed. Say what you need and it goes on the list.
No delivery dates · Plans change · Shipped means you can use it today