Community
Get help, show your work, shape what ships.
Every channel around code-anything.com in one place — what each one is for, what to expect from it, and which ones are open today. The fastest help is the chat inside your own project, because it can read the build that just failed.
Start here
What this community is today, and what it is not
A short, honest map before the detail — so you never send a message into a channel that is not listening.
Most community pages open by telling you how many thousands of members are waiting. This one will not, because it would not be true. code-anything.com is early, and the places you can reach a person or an answer today are a short list: the chat inside your own project, the documentation, two mailboxes, and the showcase where people publish apps that others can remix. A chat community is planned and is not open — there is no invite link on this page because there is nothing to link to.
That sounds thinner than it is. The single most useful support channel here is not a forum at all: it is the chat inside a project, which can read the run that just failed and the files that produced it. Most questions that would take three replies and a screenshot in a forum are one sentence there, because the thing being asked about is already in view. The written material carries the rest — two quickstarts, how previews and environments and deploys work, what the workspace monitors after you ship, and a troubleshooting reference organised by symptom.
What a community adds on top of that is the part machines are bad at: knowing whether an idea is worth building, seeing how somebody else solved the thing you are stuck on, and being told plainly when something is not possible yet. That is what the channels below are for, and why the guidelines further down are written as reasoning rather than as a list of prohibitions. It is also why the roadmap is public and phrased as direction rather than as promises — the honest version of “tell us what you need” is showing you what is already queued before you spend your time writing it up.
Read on for the channel-by-channel guide, how to write a question, a bug report or a feature request that gets somewhere, what actually happens to feedback after you send it, the house rules and the reasoning behind each one, and how to put an app you built in front of other people.
Channels
Where to ask what — a channel-by-channel guide
Eight places, seven of them open. Each card says what the channel is best at and what to expect from it, so you can pick once and get it right.
The chat inside your project
Open nowAnything about your own build: a run that failed, a feature behaving oddly, the next change you want. It is the only channel that can see your code.
It reads the run that just failed and the files that produced it, so a one-line description of the symptom usually beats a long write-up. Answers arrive as changes you review rather than as instructions to follow.
The documentation
Open nowLearning how the platform works before you need to ask anyone: both quickstarts, previews, environments and secrets, deploys, monitoring and an eight-symptom troubleshooting reference.
Written answers, available immediately, with a section anchor you can send to someone else. Start at the quickstart that matches you — prompt to app, or connect an existing repository.
Email the team — hello@
Open nowAccounts, plans, credits and invoices; bug reports about the platform itself; feature requests; anything that needs a human rather than an agent.
A person reads it. We have not published a response time and we are not going to invent one — put the urgency in the subject line and the reproduction in the body.
Security disclosures — security@
Open nowA suspected vulnerability in the platform, in the sandbox, or in code the agent generated. Not the place for ordinary bugs.
Report it privately before disclosing it publicly, with steps to reproduce. Good-faith reports are welcome; the disclosure policy is on the security page.
The showcase
Open nowPublishing something you finished, and finding real apps to start from instead of a blank page.
A public gallery of apps their owners opted in. Each card carries a live link, a blurb, a screenshot of the running app and — once it has any — a remix count. Anyone can remix an entry into a project of their own.
Roadmap and changelog
Open nowChecking whether the thing you were about to ask for is already planned, already shipped, or deliberately not being done.
The roadmap groups work as Now, Next and Exploring and is directional rather than a commitment. The changelog lists releases newest first and says on the page that its current entries are illustrative launch examples.
Partner enquiries — partners@
Open nowHiring an experienced builder to work alongside you, or applying to be listed as one.
The mailbox is live and read. The directory itself is still being assembled, so today this is an introduction by email rather than a browsable list of profiles.
A chat community
Not open yetEventually: swapping tips, showing work in progress, and asking the kind of half-formed question that suits a room rather than a mailbox.
It does not exist yet. There is no server, no invite link and no waiting list, which is why nothing on this page links to one. When it opens it will be announced here and in the changelog. If you find a chat server presenting itself as the official code-anything community, it is not ours.
Not open yet — there is nothing to join.
No response time is published for any of these, and none is implied. The pricing page lists support as Community on Free, Starter and Pro, and dedicated support on Team — see what each plan includes.
Quick routing
Which channel should I use? A routing table
The same guide as a lookup: find the thing you want on the left, and the third column explains why it lands where it does.
| What you want | Where it goes | Why there |
|---|---|---|
| A build failed, or the agent stopped short | The chat inside that project | It can read the failing run and the files it touched. No written description competes with that. |
| The preview will not start, or a feature in it is dead | Troubleshooting in the docs, then the project chat | Cold starts, sleeping sandboxes and missing environment values account for most of these, and each has a named check. |
| Something in the platform itself looks broken | hello@code-anything.com | That is a bug report about our product rather than about your app, and it goes to the people who can fix it. |
| A possible security vulnerability | security@code-anything.com | A private channel with a published disclosure policy, so a real issue does not get discussed in the open first. |
| A question about a plan, credits or an invoice | The pricing page, then hello@ | Plans, credit allotments and what each tier includes are documented; anything specific to your account needs a human. |
| An idea for a feature | The roadmap, then hello@ | Check whether it is already Now, Next or Exploring — then send the case for it rather than the title. |
| To show an app you shipped | Go Live, then Publish on the project page | Publishing needs a live deployment, so the gallery only lists apps that actually run. |
| A starting point instead of a blank page | The showcase, or the template library | Remix a published app to inherit its brief and design; templates are the opinionated starting points we maintain. |
| Someone experienced to build alongside you | The partner program | Rapid builds, migrations, integrations and ongoing maintenance, by introduction while the directory is assembled. |
| To follow what shipped | The changelog | Releases, newest first. There is no newsletter or notification feed to subscribe to today. |
Everything in the middle column exists today except the chat community, which is why it is not in the table at all. Mailboxes: hello@ for the team, security@ for disclosures, partners@ for the partner program.
Asking well
How to write a question that gets a useful answer
None of this is etiquette for its own sake. Each step removes a round trip, and round trips are the whole cost of asking.
Open with what you expected, then what happened
Two sentences, in that order, before any theory about the cause. “I expected the sign-up form to send a confirmation email; nothing arrives and the page stays on the spinner” is answerable. “Email is broken” is not, and it is the same number of seconds to type.
Ask in the channel that can see the thing
A question about your project belongs in that project’s chat, where the run, the diff and the code are already in view. A question about billing or about the platform belongs in email, where an agent would only be guessing. Choosing right the first time is most of the speed.
Bring the evidence, not a paraphrase
Copy the message exactly — the preview boot panel names the step that failed rather than reporting failure in general, and every run is recorded with its verdict on the project’s Usage tab. A summary of an error throws away the part that identifies it.
Say what you already tried
It stops an answer that repeats your last ten minutes, and it narrows the problem for free. “A retry made no difference, the missing-secrets banner is not showing, and it worked before I added the payments page” rules out three whole branches in one line.
Keep one question in one place
Split threads split the context. If the problem turns out to be two problems, say so and let each one have its own thread rather than interleaving them — for you as much as for whoever answers.
There is one shortcut worth knowing before you write anything. If the question is about your own project, the chat there has already read the failing run and the code around it, so the useful opening is the symptom rather than the diagnosis. People often spend a paragraph explaining what they think went wrong and lose the one line that identified it. Describe what you saw; let the thing that can read the logs do the theorising.
Bug reports
How to report a bug so someone can reproduce it
Reproducible is the entire bar. A report that clears it gets fixed; one that does not gets reproduced first, which is where reports go to wait.
- What you did, what you expected and what happened — in that order, in the first three lines.
- Whether it happens every time, sometimes, or happened exactly once.
- Which surface it happened on: the preview, a build run, Go Live, an imported repository, the dashboard, or the deployed app.
- The exact text of any error, copied rather than summarised.
- The project it happened in, and which run — every run is recorded with its verdict, so the run identifies itself.
- For anything visual: the browser, and whether a hard refresh changes it.
- For anything that looks like configuration: whether the missing-secrets banner is showing over the preview.
- What you already ruled out using the troubleshooting reference, so nobody repeats it.
Where to find each of those in the workspace
The preview boot panel
When a preview will not start, the terminal in the boot panel names the step that failed instead of reporting failure in the abstract. That line is the single most useful thing you can paste into a report.
Manage → Usage
Every run the agent has made is recorded here with its verdict and its itemised spend, including the ones that stopped short. It is how you point at a specific attempt rather than describing “the build from earlier”.
Repository → Features
The feature manifest flags what a failing build touched, which is usually the quickest way to state the blast radius of a problem without reading a diff line by line.
Repository → Deploy and Changes
Deploy records every Go Live — what shipped, when, and whether it failed. Changes holds the version history of build checkpoints. Between them you can say exactly which version started behaving differently.
Before you send anything, it is worth spending two minutes on the troubleshooting reference. A surprising share of reports resolve there: a first boot that simply needed a minute to provision a container and install dependencies, a sandbox that went to sleep after roughly fifteen minutes idle, a preview showing the last stable version on purpose while a build runs, or an environment value that was never in the clone because a local env file is gitignored by definition. Ruling those out costs you a couple of minutes and saves an exchange.
If it survives that, send it to hello@code-anything.com — unless it looks like a security issue, in which case it goes to security@code-anything.com privately instead, under the disclosure policy. And whichever you use: no keys, no tokens, no customer data in the message.
Feature requests
How to write a feature request that goes somewhere
The difference between a request that gets built and one that does not is usually not the idea. It is whether the problem underneath it arrived with it.
- Lead with the problem, not the feature. The solution you have in mind is a hypothesis; the problem is the fact.
- Say what you do instead today. A described workaround is the strongest evidence a request can carry.
- Say how often it bites, and what it blocks — a paper cut on every build and a one-off annoyance deserve different answers.
- Check the roadmap first. If it is already under Now, Next or Exploring, say so and add your case to it rather than opening a new one.
- Name the smallest version you would accept. Requests that only work in their maximal form tend to wait forever.
- Say whether a documentation gap would have solved it. Surprisingly often, that is the real fix and it can ship the same week.
Be aware of what you are not getting when you send one. There is no public issue tracker here, no vote board and no ticket you can watch move across a lane — which means your request will not accumulate upvotes from strangers, and it also means it will not sit in a queue being quietly ignored in public. It is read, weighed against what is already planned, and answered.
The most useful thing you can attach is the workaround you invented to survive without the feature. Workarounds are how a nice-to-have is told apart from a daily tax, and daily taxes are what get built. The second most useful is a plain statement of scale — every build, once a week, or once ever — because a small annoyance that happens constantly beats a large one that happened once.
After you send it
What happens to your feedback once we have it
A short account of the pipeline, including the parts that do not exist.
It is read by the people who build the product
There is no support tier between you and the team. That is the upside of a small operation, and the reason we do not publish a response-time promise we would have to hedge.
It gets grouped by problem, not by sender
Five messages describing the same friction in five different words are one signal, and they are treated as one. This is why the problem statement matters more than the proposed feature — problems merge, proposals do not.
A bug with a reproduction becomes work
Reproducible is the whole bar. A report that names the surface, the run and the exact error can be turned into a fix directly; one that describes a feeling has to be reproduced first, and that is where reports stall.
A request is weighed against the roadmap
The roadmap is grouped as Now, Next and Exploring, and it moves as we learn what people actually build. Something can be genuinely good and still not be next; if it is a no, we would rather say no than leave it hanging.
What ships appears in the changelog
Releases are listed newest first. The current entries are marked on that page as illustrative examples prepared for launch rather than a verified history, and we would rather say that plainly than let a tidy list imply otherwise.
What we deliberately do not do: publish a response-time commitment, run a public tracker, or reply to a feature request with a number that implies a queue position. Those things look like accountability and mostly manufacture it. The two public artefacts that do mean something are the roadmap, which says what is being worked on now, what is planned next and what is only being explored, and the changelog, which lists releases newest first.
House rules
Community guidelines, and the reasoning behind each one
Six rules, written as arguments rather than as bullet points — because a rule you agree with survives contact with a bad day, and a rule you merely read does not.
Assume a beginner is reading
The premise of this platform is that people who do not write code can ship real software, so the room will always contain someone who does not know what a migration is. That is the point, not a nuisance. Answer the question that was asked, skip the sighing, and if a term is unavoidable, define it in half a sentence.
Be specific rather than urgent
Urgency is real, but it carries no information. “Broken, please help, this is blocking a launch” cannot be acted on; the same message with the surface, the run and the exact error can. Say the deadline once, then spend the rest of the message on the reproduction.
Keep help where the next person can find it
A problem solved in private is solved once. Prefer the channel over the direct message, and when something turns out to be a documentation gap, say so — the fix that helps the next hundred people is a paragraph in the docs, not a longer answer to you.
Credit the work you build on
Remix an app from the showcase and you inherit someone’s brief and design; use an element from the library and you are using an MIT-licensed component with a named author attached. Keep the licence file, keep the author handle, and say where a starting point came from. It costs nothing and it is the difference between a community and a scrape.
Never paste secrets or customer data
API keys, tokens, connection strings and anything belonging to your users do not go in a message — not in chat, not in an email, not in a screenshot of a terminal. Keys belong in the project environment, where they are encrypted and never handed back to the browser. If you have already pasted one somewhere, rotate it rather than hoping.
No spam, no drive-by promotion
Showing an app you built is the point of the showcase. Broadcasting an unrelated product, harvesting contacts for a sales list, or publishing an empty entry to farm links is not, and it does not stay up. If you sell build services, the partner program is the front door made for you.
On enforcement, the honest position: there is no moderation team to introduce, because there is no room to moderate yet. These guidelines apply to the surfaces we actually run — the showcase gallery and the mail we receive. A gallery entry that is spam, empty, or promoting something other than an app built here does not stay up, and that is the extent of the lever today. When the chat community opens, the moderation approach for it will be published here before anyone is invited, not after the first argument.
If something is wrong — an entry that should not be listed, a message that crossed a line, or anything on this page that has stopped being true — email hello@code-anything.com. Being told we are out of date is a favour, not a complaint.
Show your work
How to share what you built in the showcase
The gallery is the one place where a stranger can see something real, use it, and start their own version of it in a click.
Take it live first
Publishing requires a live deployment — the gallery only lists apps that genuinely run, so a project that has not gone live cannot be published. Go Live puts it on a real URL, and that URL is what visitors click.
Publish from the project page
Listing is opt-in and reversible: nothing appears in the gallery unless you choose to put it there, and unpublishing is the same control. Your project keeps working exactly as before either way.
Write the title and blurb for the card
You can set a display title and a short blurb; leave them empty and the project name is used. One line that says what it does and who it is for beats a clever name — the blurb is what decides whether anyone clicks Visit.
A screenshot of the running app is captured
The card art comes from the live app rather than from an upload, so what people see is what is actually deployed. Worth landing the front page before you publish.
People visit it — and remix it
Remix starts a new project for someone else from the same brief and design; yours is untouched and stays yours. Once an entry has been remixed, the card shows how many times. That count is the closest thing this community has to applause.
A good entry is a finished small thing rather than an ambitious broken one. Publish the booking page that works, not the platform that half exists — remixers open what you list and start from it, so a clean, working starting point is the gift. If you want a sense of the range first, the template library is the maintained equivalent, and the palettes are how the same build gets a different face.
Contribute
Ways to contribute that are not asking for help
There is no public repository to send pull requests to — the platform is not open source. These are the things that genuinely move it.
Publish something remixable
A finished app in the gallery is worth more to a newcomer than any amount of marketing copy, because they can open it, see it work and start their own project from it in one click.
See the galleryWrite the bug report you wish existed
Surface, run, exact error, whether it repeats. A report at that standard is the difference between a fix this week and a problem that is still being reproduced next month.
Check it firstSend the request with the workaround attached
Tell us what you do today instead of the feature you want. Workarounds are how we tell a nice-to-have from a daily tax, and the daily taxes are what get built.
Check the roadmapDisclose security issues responsibly
Tell us privately, with steps to reproduce, before telling anyone else. Good-faith reports are welcomed and worked through rather than argued with.
Disclosure policyCredit the open-source work you use
The element library is imported from Uiverse under the MIT License, with every element carrying its original author. Keeping that attribution intact is a small, real contribution back.
Browse elementsHelp other people build
If building for clients is what you already do, the partner program is where that turns into work: rapid builds, migrations, integrations and ongoing maintenance for people who want a hand on the wheel.
Partner programWorth separating two things people mean by “contribute”. Contributing to the platform is the list above — reports, requests, published apps, disclosures, attribution. Contributing to your code is different and much simpler: what the agent writes is ordinary source, and on the plans that include connecting a GitHub repository it lands there as branches and pull requests with full history — so you and your colleagues can write code by hand alongside it, read every diff before it merges, and take the whole thing elsewhere whenever you like. Nothing you build here is locked in a proprietary format.
Stay current
How to follow what ships without checking back constantly
Two pages, honestly labelled. There is no newsletter and no notification feed to sign up for today.
The changelog — what already shipped
Releases newest first, each with the capabilities, improvements and fixes it carried. The page states plainly that its current entries are illustrative examples prepared for launch rather than a verified historical record — we would rather tell you that than let a tidy list imply a longer past than we have.
Read the changelogThe roadmap — what is coming
Grouped as Now, Next and Exploring, so you can tell the difference between something being built this month, something planned, and an idea still being weighed. It is directional and it moves — that is the point of publishing it rather than a dated list of promises.
See the roadmapLonger writing lands on the blog, and what the platform can actually do is catalogued under capabilities and integrations.
FAQ
Community questions, answered
Keep reading
Where to go next
Documentation
Both quickstarts, environments and secrets, deploys, monitoring and the troubleshooting reference this page keeps pointing at.
Learn moreShowcase
Live apps people published, each one visitable and remixable into a project of your own.
Learn moreRoadmap
Now, Next and Exploring — where the product is heading, stated as direction rather than as a promise.
Learn morePlatform
The path a change takes: prompt to preview to Go Live, or repository to sandbox to a reviewed pull request.
Learn moreBuild something, then show it to someone.
Describe an app, take it live, and publish it to the showcase so the next person has something real to start from.