How we decide what to build next

Every week, we get feature requests. Some are great ideas we'd already been thinking about. Some solve a real problem for one team but would create friction for everyone else. Some are things we'll never build — and that's by design.

This is how we actually decide what makes it into ema and what doesn't.

The list is long. That's normal.

We track every feature request. Nothing disappears into a void. But tracking something isn't the same as committing to build it, and we think that distinction matters.

If you've sent us a request and haven't seen it ship yet, it's not because we ignored it. It's because it's being weighed against everything else on the list — and that list is always longer than the time we have.

How we weigh requests

There's no single formula, but there are a few questions we ask every time something comes up.

How many teams are asking for the same thing? If twenty teams independently describe the same pain point, that's a strong signal. If one team wants something very specific to their workflow, it might still be worth doing — but it has to clear a higher bar.

Does it fit where the platform is heading? ema has a direction. We're building a connected, AI-first event management platform. Features that reinforce that direction get prioritised. Features that pull sideways — even clever ones — usually don't.

Does it add complexity that hurts more users than it helps? This is the one people underestimate. Every feature has a cost beyond development time — what engineers call feature creep. It's another thing in the UI. Another option to configure. Another thing that can break, another thing to document, another thing new users have to learn or ignore. A feature that 5% of users want and 95% have to navigate around isn't a net positive. It's a tax on everyone.

Is there a simpler way to solve the underlying problem? Often, the request is for a specific solution, but the real issue is something broader. Someone asks for a custom field type, and the actual problem is that their data model needs restructuring. Someone wants a button that triggers an email, and the real answer is a proper notification workflow. We'd rather solve the root cause than bolt on a workaround.

Fewer things, done well

We're opinionated about what belongs in ema and what doesn't. We think that's a feature, not a bug.

The alternative — saying yes to everything — is how platforms end up bloated and confusing. You've used software like that. Settings pages with 200 options. Menus with 30 items, 25 of which you never touch. Features that were clearly added because one large customer demanded them and now everyone else pays the complexity cost.

We'd rather do fewer things well. A schedule builder that handles conflict detection properly is more valuable than a schedule builder with fifteen bolt-on features that each work halfway. A floor plan tool that connects to your event data is better than one with a hundred drawing options but no context.

This means some requests get a "no" or a "not now." We understand that's frustrating when it's your request. But it's the same discipline that keeps the parts of ema you do use clean, fast, and coherent.

What you can see

We publish a public changelog so you can track what's actually shipping. Not a vague roadmap with quarters and colour-coded bars — a real record of what changed and when.

This is deliberate. If we're going to be opinionated about what we build, we should also be transparent about what we're building. You shouldn't have to guess whether the platform is moving or wonder if your feedback went anywhere.

The short version

We read every request. We track them all. We build the ones that make the platform better for the most teams, fit the direction we're heading, and don't add complexity that outweighs the benefit. Some things take time. Some things won't happen. We'd rather be honest about that than pretend everything is "on the roadmap."

If you've got a request, send it. We want to hear it. Just know that the best thing we can do with your feedback is be thoughtful about it — not just fast.