Build it together
Help build NomadSpots as a community project
The useful way to help is simple: request a feature, report a bug, add a place, or correct a detail that has gone stale. Code contributions can come later.
By Tim & Thomas 3 min read Updated 13 Jul 2026
The short answer
How can you help build NomadBadge?
NomadBadge should grow with the people who use it. Feature requests, bug reports, venue submissions, reviews, and future code contributions all point at the same goal: a guide that saves enough time to justify the small contributions that keep it maintained.
The invitation
What should people ask for?
The best requests are grounded in real use: a city, a route, a problem, and the workaround that feels too slow.
A feature request is strongest when it comes from friction. Maybe you could not tell whether a place works for calls. Maybe the city page missed a pattern locals know. Maybe the review form asked the right question in the wrong moment.
Those reports are product work. They help the guide stay close to the actual day of a remote worker instead of drifting into nice-to-have features.
The same goes for bugs. If something breaks while someone is trying to find a place to work, the report matters.
Ways to help
How can the community make the guide better?
Not everyone needs to write code. Most useful contributions start with a place, a bug, or a sharper question.
Request the useful thing
Good feature requests describe a repeated pain, not a vague preference. The best ones make the product easier to trust or faster to use.
Report what breaks
Bugs are easier to fix when the report includes the route, device, city, and what happened right before the issue showed up.
Join later when code opens
Open code only helps when the project is ready for outside work. The goal is useful contribution, not performative openness.
Fund the upkeep
Small future contributions should cover the boring work: hosting, moderation, fresh data, and keeping the guide from going stale.
Future model
Why should small contributions pay for themselves?
Because the value is not access for its own sake. The value is the time you no longer waste.
If a guide saves you 40 minutes of searching, one bad walk across town, or the stress of picking the wrong place before a call, a small contribution can pay for itself quickly.
That is the future promise to protect: very small contributions that fund the maintenance work and stay cheaper than the frustration they remove.
Until that exists, the public copy should stay honest. Today the best way to help is to use the product, add places, report issues, and ask for the features that would make it more useful.
community quality
Why a small paid community works
How tiny contributions can protect signal without turning the guide into a status product.
Open pagefield notes
Why field reports matter
How practical reports from the community keep the guide useful.
Open pagecontribute now
Add a NomadSpot
The simplest way to help today is still to add a NomadSpot that actually works.
Open pageFAQ
Questions about feature requests, bugs, and opening the code
Can users request NomadBadge features?
Yes. The product is still young enough that practical requests matter. The best feature request explains the situation, the city, the current workaround, and how often the problem comes up.
Will NomadBadge become open source?
That is the direction, but not a current promise. The intent is to open the code once the product is live enough, stable enough, and documented enough that outside contributors can help without adding confusion.
How should people report bugs?
A useful bug report includes the page, city, device, what happened, what you expected, and whether you can repeat it. Screenshots help, but a clear description already saves time.
Why would a community project charge small contributions later?
Because hosting, moderation, curation, and data maintenance cost time and money. The contribution should stay small and pay for itself by saving members far more time than it costs.
What does community-built mean for NomadBadge?
It means users help shape the guide by adding places, reviewing work conditions, reporting stale data, requesting useful features, and holding the project to a practical standard.
Send the sharp request
The best roadmap comes from real use.
Bugs, missing places, and repeated frustrations are the raw material.