Which AppJar should we build next?

[mlopezFC]

Eleven AppJars exist today, and the list came from problems we kept re-solving on client projects. That is a decent way to pick the first eleven and a bad way to pick the next one, so: what should we build?

Some things we have heard, in no particular order and with no commitment attached:

• Document management — upload, version, preview, permissions
• Notifications — in-app, email and push behind one API, with per-user preferences
• Reporting and export — beyond what Data Query covers
• Feature flags — runtime toggles with targeting rules
• Multi-tenancy — tenant isolation as a cross-cutting concern
• Import wizard — CSV and Excel into your own entities, with mapping and validation

What we would rather hear about than any of these is the thing you built last year that you resented building — the piece of plumbing that was not interesting, was not your product, and took three weeks anyway. That is the shape of a good AppJar.

Two things that help a lot when you answer:

1. Describe the problem, not the solution. What were you trying to accomplish, and what made it slow? That lets us solve it in a way that fits the rest of the catalog.
2. Say roughly what your stack and scale look like. A feature that makes sense for a 20-user internal tool and one that makes sense for a public application with 200,000 accounts are often not the same feature.

Ideas that turn into something concrete become feature requests in the tracker, labelled appjars/new-appjar. Anything you post here is covered by the terms in CONTRIBUTING.md.