You uploaded your world. You submitted it to Community Labs.
A few days later you check and there have been a dozen or so visitors. You're standing alone in an empty instance.
That isn't a failure. For a first world, it's an entirely ordinary result. This article covers the loop from here. Gather reports, fix, ship again. Completing that loop once changes how the next world turns out.
What You'll Learn
- What kind of place Community Labs is
- How to place contact info and a changelog
- What to watch when updating
- How to relate to the numbers
Start from having finished uploading a world.
Labs is a new-arrivals shelf, not a high street
Community Labs is where newly published worlds are lined up. Submitting puts you where people looking will see you.
But it isn't a place many people pass through. In bookstore terms, it's less the front-table display and more the new-arrivals shelf.
| What you'd assume | Actually |
|---|---|
| Submitting brings people | Only people who came looking see it |
| A few days tells you enough | It comes in waves. Watch it a while |
| Nobody comes because it's bad | Usually it just hasn't been found |
Worlds sit in Labs for a period, and those meeting the conditions move to Public. Think of it as the waiting period until then.
So what to do during this time isn't promotion. It's reliably getting information from the few people who did come.
One report from someone who saw the whole thing beats fifty people who left in ten seconds. Concentrate there.
Hands-On: Set up a way for feedback to arrive
Put something in the world that lets visitors say "this part gave me trouble."
1. Place a contact sign
Put one sign near the exit, or on a wall visible right on arrival.
With a World Space Canvas and TextMeshPro, write something like this.
Built by: (name)
If anything is broken or confusing,
please let me know at (contact)
Adding what specifically you want to hear makes reports more likely.
| Wording | How likely reports are |
|---|---|
| "Please share your thoughts" | Unlikely |
| "Tell me about broken mechanisms or places you got lost" | Likely |
Knowing what to report makes it easier to write. Match the font size to the targets in settings panels that work for everyone.
2. Make the changelog editable from outside
You want to tell visitors what you fixed, and uploading each time is a chore.
The mechanism from updating a board from external text applies directly.
- Put one text file on the web
- Put a board in the world that reads that URL
- Rewrite the text when you fix something
2026-09-09 Fixed the second-floor chair you couldn't sit in
2026-09-05 Brightened the entrance, which was too dark
2026-09-01 Released
You update it without building. Whoever reported something sees that it's fixed, which leads to the next report.
3. Walk a lap as a first-time visitor
The bugs you find most are the ones you find by walking it yourself.
But you know where everything is. Left to yourself you can't get fresh eyes. Do a lap under these constraints.
| Constraint | What it surfaces |
|---|---|
| Walk from the spawn without turning around once | Places where guidance is missing |
| Touch everything that looks touchable | Unresponsive decorations, unpressable buttons |
| Deliberately go somewhere strange | Holes you fall through, walls you pass through |
| Do a lap as a small avatar | Unreachable buttons, unreadable signs |
| Enter from a phone | Unreadable text, hard-to-press UI |
What you write down is trouble, not fixes. Work out the fixes later. Noting the moment of trouble as it happened is more useful afterwards.
4. Fix it and re-upload
From what you gathered, fix in order of what troubles visitors.
| Priority | Examples |
|---|---|
| High | Falling, getting stuck, pitch black, can't enter |
| Medium | Can't press it, getting lost, can't read it |
| Low | Small visual awkwardness |
Once fixed, re-upload with the same steps as uploading a world. Keep the Blueprint ID the same. That updates the same world.
The update loop
Three things worry people at each update. Here are the answers up front.
People inside don't get kicked out. Anyone playing continues as they were, and the new version applies from their next entry. Don't agonize over update timing.
Favorites don't get cleared. Updating keeps you on the lists of people who bookmarked you.
The description and thumbnail are worth revisiting too. The contents change while the description stays as it was on day one, often enough.
| What to revisit | Where to look |
|---|---|
| Description | Does the first line say what the world does? |
| Tags | Do they include words people searching would use? |
| Thumbnail | Does it show the best view? Is it too dark? |
Thumbnails matter. It's the first thing people see in a list. Retaking it alone can change how many people enter.
How to relate to the numbers
Visitor counts and favorites are visible, so they get to you.
Don't compare against the wrong thing.
| Who you compare against | Who you should compare against |
|---|---|
| Famous worlds | Yourself before you published |
| People who've built for years | Your own world from last week |
Famous worlds come after building many. They aren't the comparison for a first one.
Keeping a realistic view makes it easier.
- An empty instance is the standard for a first world. Nothing is wrong
- The numbers come in waves. Don't judge from a few days; watch a while
- The result of months of work isn't a visitor count — it's having one world you can publish
When to stop is also yours to decide. Once you've fixed things to where "visitors don't get lost, don't fall, and know what to do," call it a milestone. Refinement beyond that grows you more if you put it into the next world.
Bonus: Good to Know Up Front
- Don't fix a report you can't reproduce: "It's heavy" can't be fixed without knowing the device and where they were. Ask back first
- Don't try to fix everything in one update: Fixing two or three high-priority items and shipping, repeatedly, is more dependable
- Always Build & Test before updating: You can break something else while fixing. Do a lap before uploading
- Take backups: Copying the pre-update project to another folder lets you go back
- A first world is there to get experience: Completing this loop at all is what pays off in the next one
Summary
After release, the work is running a loop.
- Labs isn't where people gather. Reliably receive the few reports you get
- Put contact info and a changelog inside the world
- Fix in order of what troubles visitors
- Compare the numbers against yourself before publishing
The question to ask now is: "Do visitors avoid getting lost, avoid falling, and know what to do?" Pass that and, for a first world, it has landed well enough.
To confirm the re-upload steps, go to uploading a world. For pre-release checks, go to the pre-release checklist.