Most apps have a suggestion box, and it is usually /dev/null with a friendlier font. Ours now has a monthly quota, a review that reads the actual code, and, which is the unusual part, a reply. Every account gets four ideas a month, and every idea comes back with a verdict.

Macropoiesis has grown past a hundred pages, and very few of them started in a meeting. They started as an itch: a number someone kept looking up by hand, a chart that should have existed, a comparison that took four browser tabs. The people who feel those itches most often use the site every day. That means you, not us.

So we are handing over part of the roadmap. Call it the do-it-yourself app: you describe the Macropoiesis you want, and the good ideas get built into the one everybody uses.

How it works

• Open the Feedback popup. Press Ctrl+Shift+F anywhere on the site, click the speech-bubble icon in the header, or tap Feedback in the mobile menu.
• Pick the Feature tab. A badge shows how many of this month's four requests you have left.
• Describe the idea. Add a short title if you like, then describe the idea in 50 to 1,000 characters: what it should do, where you would use it, and what problem it solves.
• The page comes along for free. The popup attaches the page you filed from, so "this chart needs a log scale" arrives knowing which chart.
• Bugs are unlimited. The Bug tab in the same popup has no quota. A bug is not a wish. It is a debt, and we don't ration the paperwork for our own debts.

What happens to your idea

Requests are reviewed in batches, and they are checked against the code rather than against a vibe. An AI coding assistant reads the real codebase (the page registry, the data providers, the scheduled jobs) and scores every request from 1 to 10 on three questions:

1. Is it useful? How many people would use it, how often, and whether it already exists somewhere. With a hundred-odd pages the honest answer is sometimes "yes, it is on this page, and here is how to find it". That answer is worth having too.
2. Can it be built here? Which parts of the app it would touch, whether the data already flows in through the providers we use, and whether it needs new storage or a new scheduled job.
3. Does the usage justify the running cost? Every feature comes with a bill that never stops arriving: AI tokens per use, paid data calls, rate limits on the market-data feeds, scheduler minutes, and maintenance forever. A feature that costs a lot and gets opened twice a month is not a feature. It is a subscription we pay to nobody.

Then a human reads the scores, signs off and records the verdicts. The machine reads the code, and a human signs the verdict.

Each request lands in one of three states:

• Accepted: worth building now, because the value is clear, it is feasible and the usage outweighs the cost.
• Later: a good idea whose time has not come. It depends on something else, or the effort is out of proportion right now.
• Declined: it duplicates something that exists, is too narrow, or costs more than it returns.

Accepted ideas move to Implemented when they ship. Whatever the verdict, you get an in-app message with the status, a score out of ten and a short note explaining why in plain language. The full history of your requests and their answers lives on your Feature Requests page.

When several people ask for the same thing, their requests are grouped and judged together. Five people independently asking for the same idea is data, and we treat it that way.

Why four?

Because scarcity improves wishes. An unlimited suggestion box fills up with one-liners. A box that takes four a month gets the idea you have actually been turning over in the shower.

The quota runs per calendar month and resets on the 1st (UTC). Declined requests count toward it, so pick your battles. Unused requests do not roll over, so there is no carry trade.

Why we bothered

Because the hard part of building software is not writing the code. It is knowing which code is worth writing. We can build fast. What we cannot do is sit where you sit, on the pages you open every morning, and notice the thing that is always one click too far away.

And because it is cheap to do properly. Nothing runs when you press submit: no bot pre-screens your idea, and the review happens in batches, well off the request path. What you get back is a real answer, such as "this needs data we do not have" or "this is two days of work and most of you would use it". A polite thank-you followed by silence teaches people to stop suggesting. We would rather tell you no, with a reason, than tell you nothing.

How to write a request that gets accepted

• Be concrete. "Make the portfolio page better" is a mood. "On my portfolio page, show which holdings report earnings this week, because I keep checking the calendar separately" is a feature.
• One idea per request. Three ideas in one request get one verdict, and it will be the verdict of the weakest one.
• Say why. The problem you are solving is more useful to us than the solution you picture. Sometimes there is a better way to solve it.
• File it from the page it is about. The popup does the rest.

A note on access: filing requests needs an account with write access. Read-only accounts, including the Stringer supporter tier, can read everything, this post included, but cannot file requests.

Press Ctrl+Shift+F and tell us what to build next. That's four wishes a month, no genie, and every one gets an answer.