The roadmap is live, and your vote shapes it

Note for ops: this post is staged for publication shortly after mobile launch — when in-app voting becomes available. The date: field is a placeholder; bump it to the real publish date before pushing the deploy that ships it.

We've launched. The mobile app is in the App Store, Google Play, and the Microsoft Store. Web Hestia is live. The free tier is fully usable. And — most importantly for this post — the roadmap is now driven by you.

Public roadmap: /roadmap.

What's there

Every feature lives in one of four buckets:

• In progress — actively being built. Estimates are public when they exist; vague when they don't.
• Accepted — voted high, agreed by the team, will get scheduled into a sprint. The accepted bucket is where engineering pulls from when capacity opens up.
• Released — shipped within the last quarter. After that they roll into the regular changelog.
• Won't do — features we considered and decided against, with the reason. This bucket is the one that takes the longest to write and is the one we care most about. "We're not doing it" without a reason looks like neglect; with a reason it's a respect for your time.

Drafts (features we're still scoping) aren't shown publicly until they land in Accepted. Ditto for Proposed — we keep those private while triage happens.

Why we built it this way

A public roadmap costs us flexibility. We can't quietly drop a feature that shows up on a list users have looked at. That's the trade we're making on purpose:

• Transparency moat. Other apps in this space don't say what they're building. We do, and so when we announce something, you already know it was coming. The conversation moves from what is this? to how does it work?.
• Community-driven prioritisation. Some features we'd never build on our own get voted into accepted. Some features we were excited about get voted down. That's the system working.
• Pre-empting feature requests. If a feature is won't do, it's there with the reason — so the next person asking gets the answer faster than email could.

The cost is that some quarters we ship less new product because we're shipping the things you wanted instead of the things we wanted. We've decided that's the right trade.

How to vote

You vote inside the app, not on this page. The reason: votes are weighted by usage. A user who's been on the app for six months and uses it daily has a different signal than a brand-new account with no history. The web /roadmap shows the totals; the app is where the input happens.

Three ways to act:

1. Open the app → Settings → Roadmap → vote on what's there. Up-vote what you want. Up-vote what you want a lot, twice (votes-of-strength are a feature; you spend daily allowance on them).
2. Comment on a roadmap card if you have a specific use case the card doesn't cover. Comments are public on the web /roadmap card; they show up under "Member" and we read them.
3. Suggest a new feature via /support. The team reviews suggestions weekly and the ones that get traction land on the roadmap as Proposed, then Accepted once enough people care.

Adult-feature requests

The adult-zone roadmap surface lives in-app behind the same biometric + 18+ self-attest gate as the rest of the Ember zone. We don't surface adult feature requests on the public web /roadmap — partly because the audience for those features hasn't opted into the zone yet, and partly because the moderation footprint of public adult feature discussion is more than it's worth.

The way it works inside the app: same vote-and-comment system, separate visibility scope, two-eye admin review on every shipped item. Adult-feature changes go through the same engineering review as any other ship, plus a second admin sign-off — the audit-log invariant we documented in the security posture applies here too.

What we won't do

The won't-do list is the most honest thing on the roadmap. A few that come up often enough to flag here:

• Public friend graph / discovery. No. The reason is in the first blog post: the moment you can find another user from inside the app, the app is something else.
• Posting from one Cell to another's feed. Trusted Cells (the opt-in cross-Cell relationship for shared rituals + challenges) is the limit. We don't ship a "post to" because we don't have a "feed to post into" and we're not adding one.
• AI-generated content for kids without parent approval. AI can scaffold journals and missions when a user asks. It doesn't push content to a kid surface without a parent in the loop.
• Family-app gamification of real relationships. No "couple compatibility scores", no "best parent leaderboard", no metrics designed to make people compete on intimacy. We use streaks for routines, not for relationships.

The rest of the no-list is on /roadmap, with reasons.

What's next

Post-launch we're focused on three things:

1. Multi-cell tooling deepening. The bones are in (kid-in-two-cells works today). The next round is cross-cell shared rituals, cross-cell reward sharing, and a clearer custody-handoff UX in the calendar.
2. The Pillar work. Sandwich-generation surfaces around aging-parent care. Expanded grandparent companion (more cadences, more question types). Family-narrative writers that turn weeks of journals into a season story you'd actually re-read.
3. Locale polish. 14 locales today; the rough text was AI-assisted with human review. The next round is native polish in the locales we have, plus opening Korean / Japanese / Vietnamese.

If any of those are right for you and you want to vote them up — or if you want something on the roadmap that isn't there — install the app and the polls are open.

— The ConKarma team

Want to share this with someone? Use the buttons at the bottom of the page; the share URLs carry attribution params so we can see which posts and which platforms drive the most installs. Helps us decide where to spend the next round of content time.