Roadmap
What's coming next
A forward-looking view of where code-anything is headed — what we are building now, what is planned next, and the ideas we are still exploring. Everything here is directional, dateless on purpose, and subject to change.
// now · next · exploring — plans, not promises
How to read this
Three stages, no dates
A roadmap is only useful if you know exactly how much weight each item can carry. Here is the honest calibration.
Everything below is grouped by how close it is to being real, not by how much we like it. That distinction is the whole point of the page: an item in Now is being worked on, an item in Next is intended and prioritised but not started, and an item in Exploring is an idea we are still arguing with ourselves about. Reading a stage as a delivery date is the one mistake this page is designed to prevent.
There are no dates anywhere on this roadmap, and that is deliberate rather than evasive. A date on unstarted work is either padded until it is meaningless or optimistic until it is wrong, and neither helps you plan. The stages carry the information a date would try to: ordering and confidence. Real dates appear exactly once — on the changelog, after something has actually shipped, where a date is a fact instead of a forecast.
If you want the current state of the platform rather than its future, the platform overview is the fastest orientation and the capabilities pages go into detail feature by feature. For what is available on which plan, the pricing page has the split — noting that payments, connected repositories, monitoring, and custom domains sit on the paid tiers rather than the free one.
Now = in flight
Someone is working on it. It has passed the point where we are still deciding whether to do it, and the remaining uncertainty is about how long and how well — not whether. Items here usually land in an upcoming release, and when they do they move to the changelog.
Next = intended, not scheduled
We mean to build it and it is prioritised ahead of everything not on this page. What it is not is a date, a guarantee, or a feature you can plan a launch around. Items can be reshaped, delayed, or dropped as we learn more — that is a normal outcome, not a failure.
Exploring = genuinely undecided
An idea we find interesting and have not committed to. Listing it is a way of thinking in public and inviting argument. Expect some of these to move up, and expect others to quietly disappear once we understand the problem better.
These are plans, not commitments
Nothing on this page is a promise, a contract, or a delivery guarantee. Items can be reprioritised, reshaped, delayed, or dropped entirely as we learn more — including items listed under Now. Please do not treat a roadmap entry as a dependency for your own launch plan; treat a changelog entry that way instead. Where this roadmap and any other page on the site disagree about whether something is available today, this page is the one to trust.
The plan
Now, next, and exploring
Grouped by how close each item is. These are plans, not promises — priorities shift as we learn from how the platform gets used.
Now
In progress — actively being built.
Work is underway. Expect it in an upcoming release, not on a named date.
One status view across a project
Health checks already run on a cadence you set and already say what failed — an unreachable preview, an HTTP status, or the actual error line a deployed page is serving. What is missing is one place to read it: builds, deploys, previews and alerts currently each live on their own tab, so "is my project still up?" is four answers rather than one.
More starter templates
The library is already close to a hundred designs, and it keeps growing. The value is in the first ten minutes: starting from a template shaped like your idea means the agent spends its early passes on your problem instead of on scaffolding.
Faster preview builds
A pool of pre-warmed sandboxes and provisioning that starts before planning finishes are already in — the remaining work is the rest of the path from change to live preview. Short loops change how you work: they make small, checkable changes the natural unit, instead of one large prompt you have to unpick when it goes sideways.
Quieter, sharper alerting
An alert already arrives by email carrying the failing check, the status or error line, and a link straight to the project. The open work is the other half of the problem — noise. An alert you ignore is worse than no alert, so the target is fewer of them, each one worth acting on.
More integrations
Around thirty services connect today for data, auth, payments and notifications — either managed for you or with your own account and keys. This is ongoing rather than planned: the catalogue grows as projects keep reaching for something that is not in it yet.
Next
Planned — on the near-term roadmap.
Intended, prioritised, and not yet started. Planned is a direction, not a commitment.
Team workspaces
Shared workspaces with roles so teammates can build, review, and ship together. This is planned, not available today: every project belongs to exactly one account all the way down to the database rules, so collaboration currently means sharing what you deploy rather than the workspace itself.
Your own code on a schedule
An agent can already run on an interval you choose, and it can run a prompt rather than only a health probe. What it cannot do is run your code: a digest email every Monday, a nightly sync, a weekly cleanup. That is a different primitive from a prompt on a timer, and it is the one that is not built.
Exploring
Ideas we are weighing — not yet committed.
Under consideration only. Some of these will never ship, and that is the point of the stage.
A template marketplace
Publishing and remixing already work for whole projects, on the showcase. A marketplace would extend that to the starting points themselves, which every template today is written and maintained here. The open questions are quality and trust rather than mechanics — a marketplace is only worth having if what you pull from it is safe to build on.
Analytics for your deployed app
Each project already reports its own build and spend history down to the individual run. What does not exist is the other side: traffic, latency and errors for the app you deployed. The bar we would have to clear is doing it without turning every generated app into a tracking surface, which is why it is still an open question.
Multi-region deploys
Serve projects closer to users by deploying across more regions. Today a deploy goes to one managed account with no region to choose. It matters for latency and for data residency, and it is exactly the kind of change that is easy to demo and hard to operate well — hence exploring rather than planned.
Suggestions you did not ask for
Reading the whole workspace is already how a build works — code is indexed and searched across the project, not skimmed one file at a time. The undecided part is the agent volunteering: proposing fixes nobody prompted for. More context usually means better changes; it also means more ways to be confidently wrong, which is what we are weighing.
Prioritisation
How priorities are decided
Four inputs, weighted roughly in this order — and one of them outranks the rest more often than product roadmaps usually admit.
The ordering on this page is not a vote count and it is not whichever idea sounded best in the last conversation. It comes from watching what happens when people actually build things: which projects get further, which stall, and where the same wall keeps appearing for unrelated users. When a pattern shows up often enough to be a category rather than an anecdote, it becomes a candidate — and the candidates then get ordered by how many projects they unblock and how honestly we can operate the result.
What people actually build
The strongest input is the shape of real projects. When the same kind of app keeps getting built and keeps hitting the same wall at the same point, that wall becomes a roadmap item. Stated preferences are useful; observed patterns are more useful.
Where things break
Failed builds, unreachable previews, and the questions that keep coming back are the least ambiguous signal we get. Work that removes a recurring failure tends to outrank work that adds a new capability, because reliability compounds and features do not.
What unblocks the most projects
Between two good ideas, the one that unblocks more people first usually wins. That is why loop speed and monitoring keep appearing near the top: they make every project better rather than making one category of project possible.
What we can support honestly
Shipping a capability means operating it. If we cannot run something reliably and explain it clearly, it stays in Exploring until we can — which is a slower roadmap and a smaller gap between what is promised and what works.
The last card is the one that slows the roadmap down most, and we keep it anyway. Shipping something means monitoring it, documenting it in the docs, and answering for it when it misbehaves. Work that we cannot support at that standard stays in Exploring, which is why this page is shorter than it could be.
Your input
How to influence what gets built
The roadmap is steered by what people actually build — which means the most useful thing you can send is a problem, not a feature.
Tell us what you are building
The most useful message is not a feature request but a description of the thing you are trying to make and where it got stuck. That framing lets us solve the actual problem, which is sometimes a different feature than the one being asked for.
Argue with an Exploring item
Ideas in Exploring are listed precisely so they can be pushed on. Saying an idea would be useless to you is as valuable as saying it would be essential — both move an item, and only one of them is comfortable to receive.
Report what keeps breaking
Recurring friction is prioritisation input, not just a support ticket. A clear reproduction of something that fails repeatedly is one of the more direct routes onto this page, because it produces evidence rather than an opinion.
A feature request encodes a solution you have already picked. A problem description encodes the constraint — and the constraint is what generalises across everyone else hitting the same thing. "I need scheduled jobs" is useful; "my app has to email a digest every Monday and I have nowhere to run that" is more useful, because it tells us what success looks like and leaves the shape of the answer open.
The community is the right place for open discussion, including disagreeing with something in Exploring. For anything tied to your account, a private project, or a specific reproduction, use the contact route on the about page. If you have not built anything yet, the honest advice is to build the smallest version of your idea first — a real project produces far better roadmap input than a hypothetical one.
Boundaries
What is deliberately not planned
An absent item is information, not an oversight. Here is what we are choosing not to do, and why.
The first and broadest answer is simply this: if it is not on this page, it is not planned. We would rather keep a short roadmap that means something than a long one that quietly absorbs every request. Beyond that, there are commitments we hold ourselves to about how the platform evolves, and they rule out whole categories of work.
We will not ship changes that make you migrate
Platform capability arrives without you doing anything — no version to pin, no upgrade step, no migration guide attached to a release. A change that would force every existing project to be reworked is a change we would rather redesign than announce. That constraint costs us some options, and it is the reason reading the changelog never feels like reading a warning.
We will not add configuration for its own sake
The premise of a managed platform is that there is nothing to assemble before your first prompt does something useful. Every new setting is a decision handed back to you, so a good default beats an option, and an option beats a setting you must choose before anything works. Roadmap items that would only add surface area do not make it onto this page.
We will not list something as available before it is
This is why shared workspaces and roles sit under Next rather than in any feature list. To be explicit about a case we know is wrong today: our pricing page currently overstates team collaboration by presenting it as something you can use now. It is planned, not shipped. Where the two pages disagree, this one is correct, and the pricing page is the one that needs fixing.
We will not put dates on unstarted work
Covered above, but worth stating as a boundary rather than only as an explanation: no item here will ever carry a target date while it is in Next or Exploring. Dates come from the changelog, after the fact. If you need a commitment for a specific capability on a specific timeline, that is a conversation to have directly via the about page rather than an inference to draw from this page.
FAQ
Questions about the roadmap
What the stages promise, what they do not, and how things move between them.
Want to shape what comes next?
Tell us what you are building and where it got stuck. The roadmap is steered by real projects — and what already shipped is on the changelog.