Feature Requests
How to ask for something the app does not do yet, and what makes a request easy to act on.
1. Where a request goes
Send it by email
Write to support@earthunited.eco and put Feature request in the subject line. There is no form, no voting board and no public roadmap — a request is an email read by the people who build the app.
That is deliberate rather than temporary. The app is built by a small team, and a described problem in someone's own words is more use to us than a vote count.
2. What to write
The most useful requests describe a situation, not a control. "Add a button here" tells us what you tried; the paragraph before it tells us what you were trying to do, and that is the part we can design against.
- What you were doing when you wanted this — which part of the app, at which point in a project.
- What you are trying to achieve. The outcome on your land or in your work, not the interface you imagined.
- What you do instead today — a spreadsheet, a notebook, another tool, or giving up.
- How often it comes up. Once a season and once a day are different problems.
- Anything you have seen elsewhere that does it well, if there is something to point at.
Include your account email address and, if the request is about one project, its name. A request that we can look at against your actual data is much easier to judge.
3. What happens to it
Requests are read and kept. Beyond that we do not promise a schedule, a status page or a notification when something ships — we would rather say nothing than post a date we cannot hold.
- Some arrive already possible. If the app can do it and the path is not obvious, that is a help-center problem and we fix it here.
- Some become work. They are weighed against everything else in front of us; the ones that recur across different people tend to move first.
- Some do not fit. If it pulls the app away from what it is for, we will say so plainly rather than leave it hanging.
When something does ship it is written up on What's new. That page is the honest answer to "did my request happen" — check it rather than waiting for a message.
4. Requests we hear often
- Plants missing from the library. Crop planning has its own way to request a plant, from inside the tool, where it arrives with the crop and the site attached. Use that rather than email.
- Something behaving oddly. That is a bug, not a feature request, and it is worth sending separately with the detail listed on Contact support — bugs are dealt with faster.
- A different price or plan. Send it, but describe the constraint rather than the number: what the app would have to be worth to you, and for what.
5. Where to go next
Contact support
The same address, and what to include when something is broken rather than missing.
What's new
What has actually shipped, in date order.