Roadmap
Built in the open — literally.
This page is a snapshot of our real backlog, which lives in a StoryOS workspace and is worked daily by us and our agents. No theater: when priorities change here, they changed there first.
Synced from the backlog on 2026-07-16.
Now 5
In progress or queued next
Starter templates are too simple — rebuild them for real agentic workflows
Problem The templates we ship at signup are too simple — a few near-flat databases with minimal fields and few relations.
Multi-select action bar: fix it rendering off-screen, then make it a real bulk-action surface
As a user who just selected a group of records, I want a visible action bar offering everything I might do to them — set a field, link them, export them, run an agent over them, trash them — so that bulk work takes one action instead of N, and I can see exactly how many records I am about to affect before I do it.
Replace emoji database icons with a custom SVG icon set + background colours
As someone looking at my sidebar, I want database icons that look like one designed system rather than a row of mismatched vendor emoji, so that the product looks like software I'd trust my business to.
Block duplicate field names within a database (display-name uniqueness)
Why Uniqueness is enforced only on apiName (fields_database_api_name_uq, schema.ts:228).
MN-205 part 2 — BlockNote editor @/# pickers + #record in comments (follow-up to #130 part 1)
As someone writing in a record, comment or document, I want to type @ to pull in a teammate and # to pull in a record, so what I write becomes a real, traversable link — completing the mention foundation shipped in part 1.
Next 14
Committed, coming up
Integration: Google Calendar (two-way sync with a date-bearing database)
Connect a Google account via OAuth2 and sync a StoryOS database (that has a date field) with a Google Calendar.
Sign up / sign in with Google on app.storyos.dev
The app already supports Google OAuth via better-auth, env-gated on GOOGLE_CLIENT_ID / GOOGLE_CLIENT_SECRET (MN-007), and the login UI shows a Google button only when those are set.
Chat UI: in-app "Ask StoryOS" (chat-first onboarding, MCP-backed)
We are chat-first via MCP, but that requires the user to set up an external MCP client.
Skills framework: reusable agent skills (author, not from scratch) + portable export
Introduce Skills: named, reusable instruction+workflow bundles for the StoryOS agent (cf.
Billing — Stripe integration (customers, subscriptions, webhooks)
Why To monetize the cloud (per MN-107: hosting, seats, and the StoryOS AI add-on) we need a real billing spine.
Product — in-app billing & checkout section (plans, upgrade, invoices, usage)
Why Cloud users need to see their plan, upgrade/downgrade, manage payment, manage seats, and view usage from inside the product.
Billing — entitlements + usage metering enforcement
Why Plans only mean something if the app enforces them.
Forms v2 — builder sidebar, public sharing, embedding, field config
Goal (founder) "Use forms to give control to create new entities through it" — including by people outside the workspace.
Superadmin panel — operate the hosted StoryOS instance
Why Running a shared multi-workspace cloud instance needs an instance-level admin (distinct from a workspace admin).
OAuth for the hosted MCP (connector one-click) — keep PAT for self-managed
Why Polished connector UIs (claude.ai, ChatGPT, the Customize tab) drive remote MCP servers over OAuth 2.1, not a hand-pasted Authorization: Bearer header.
Run-class metering: separate non-AI runs, your-own-AI runs, and StoryOS AI runs
This is THE billing primitive and nothing currently specifies it.
StoryOS AI: prepaid credit ledger, top-ups, auto-reload, card gate
The StoryOS AI add-on is the only place we ever bill AI, and it has no ticket.
Seats: viewers/guests always free + $12 extra-seat billing with proration
"Viewers and guests are always free" is a public differentiator and nothing implements it.
Workspace-scoped subscriptions (Pro = 1 workspace; Business = $99 per workspace)
Pricing is per WORKSPACE, not per account, and no ticket models this.
Later 12
On the map, not yet scheduled
Referral program — link, tracking, rewards (cloud tier)
A referral program for the managed cloud: each user gets a unique referral link; track referral sign-ups and paying conversions; grant a reward (credit/discount) on qualifying referrals.
Expose skills over MCP (list_skills / run_skill) + serve as portable resources
As an agent connected over MCP (Claude/ChatGPT/etc.), I want to discover and run a workspace's saved skills, so a skill authored in StoryOS is usable from any MCP client, not just the in-app chat.
GitHub integration: link records ↔ PRs/commits + automate state from PR activity
Base GitHub integration (prerequisite for in-app code reviews #43).
Code reviews in-app: review GitHub PRs (Diffs) — GitLab coming soon
Modelled on Linear's Reviews / Diffs (researched: linear.app/docs/pull-request-reviews, linear.app/docs/diffs, linear.app/docs/code-and-reviews).
Integrations directory: in-app gallery + connect flow (+ delegate-to-agent)
A first-class Integrations area (settings gallery) like Linear's: each integration is a card with icon, "built by", short description, screenshots, and an Enable/Connect button, then a per-integration config panel.
Transactional email via Resend — invitations, notifications, auth mail
Problem Email is currently best-effort / SMTP-optional.
Agentic OS — run_agent automations, Agents database, agentic packs
Vision Full design: docs/product/agentic-vision.md.
Branded HTML emails (invites, verification, reset)
Why Transactional emails are currently a single line of plain text (You've been invited… Accept: <url>).
Feed inline actions: status/assignee/checkbox + comment inline (fast-follow to #62)
#62 shipped the color-by half (list dot / feed left-bar / timeline) + list styling.
Change field type → relation (convert an existing field into a relation)
Want change_field_type handles most conversions but cannot convert a field to a `relation` .
Per-workspace cost attribution and margin observability
MN-167 (#58) models COGS on paper; this makes it live.
Fair-use guard for 'unlimited records' that does not break the promise
"No record limits, ever" is a headline promise and a deliberate wedge against Airtable — so we must never ship a record cap.
Want something on this board? Open a GitHub issue — real requests move real priorities.
The backlog runs in StoryOS. Yours could too.
Start free — 30 days of Pro, no card. Issues, sprints and agents working the board: that's just a template away.