Innovation Intent & Future Features¶
The standing commitment¶
Shimmy is not building a fixed feature set and then maintaining it — the Modularity Ladder in Pillar II, Part 1.3 is explicitly designed so that new capability can be added as new modules rather than rewrites, and the small-team-plus-AI-leverage thesis in Pillar III exists specifically so that pace of innovation doesn't require proportional headcount growth. This document names the concrete directions that commitment currently points toward.
Member & access features within Shimmies — the near-term priority¶
The single most requested category of near-term product work, and a natural extension of the Modularity Ladder's Stage 2 (configurable modules) described in Pillar II, is giving communities and creators more control over who sees what, and what different members can do within a given Shimmy. Concretely, this points toward:
This sits alongside, not instead of, Shimmy's platform-level access model: Shimmy launches invite-only (see Compounding Growth & User Psychology, Loop 4 for the full growth and trust rationale). The features below are about within-Shimmy membership tiers once someone already has platform access — a second, finer-grained layer of access control, not a replacement for the invite gate at the platform level.
Tiered membership within a Shimmy¶
Rather than a single flat "member/non-member" model, individual Shimmies (particularly community and fundraising feeds) should be able to define their own membership tiers — a free/public tier, a supporter tier, and a closer-community tier — each with different visibility and interaction rights within that specific Shimmy. This is a direct extension of the Source Selector concept in Pillar II, Part 1.1: tier membership becomes another input the Source Selector can condition on, not a separate system bolted alongside the feed architecture.
Creator and organiser access controls¶
For fundraiser-native and community Shimmies specifically, the organiser should be able to grant specific members elevated access — co-organiser rights on a fundraiser, moderation delegation within a community Shimmy, or early/exclusive access to updates. This connects directly to two things already scoped elsewhere in the suite:
- The Ranking Logic swappable per-community principle from Pillar II, Part 1.2, which already anticipates community-level configuration
- The pod-level authority model from Pillar III, Part 1.2, which is the same "decoupled authority within a defined scope" pattern applied internally — worth building the product version of this pattern consistently with how Shimmy already organises itself internally
Supporter recognition and perks¶
Extending the "Meaning and Value" framework from Pillar II, Part 4: access tiers should be designed to reward prosocial behaviour specifically (consistent, verified support for a cause or community) rather than pure spend or pure engagement — directly consistent with Pillar II's existing caution against gamification mechanics that manufacture anxiety-driven return visits rather than genuine value. A supporter tier earned through verified donation history or sustained positive community participation is a fundamentally different mechanic from a paywall, and should be built and marketed as the former.
Extending the post model as tiering matures¶
Today, every post lives inside exactly one Shimmy and carries text plus up to five images or videos (see Pillar II, Part 1.2) — a deliberately simple, consistent unit across the whole platform. As within-Shimmy tiering above matures, the natural next question is whether post capability (not just visibility) should vary by tier — for example, a closer-community tier eventually supporting longer-form posts or a higher media count for verified organisers running an active fundraiser. This is flagged as a direction worth having, not a commitment: the five-image/video ceiling is a sound default for a calm, non-overwhelming feed, and any tier-based exception should be justified against the resonance metrics in Pillar II, Part 4, not granted as a default perk.
Why this is sequenced now, not later¶
Per the Modularity Ladder's own sequencing discipline (do not skip to Stage 3 early), member/access tiering is a Stage 2 capability — it extends the native modules already being built rather than requiring the third-party SDK ecosystem of Stage 3. That makes it realistic to scope within the Horizon 1 window in the Roadmap, rather than something that waits for the platform-ecosystem moment years out.
Broader innovation directions already seeded in the suite¶
The rest of the document suite already contains the seeds of a substantial forward roadmap — this section makes those explicit as directions of travel, not commitments with dates:
| Direction | Where it's rooted in the suite | What it unlocks |
|---|---|---|
| Glanceable / cover-screen mode for foldables | Pillar II, Part 2.1 | A genuinely near-term, low-engineering-cost differentiator — check a fundraiser or a close-friend update without opening the full app |
| Voice-native donation and status-check flows | Pillar II, Part 2.2 | Targeted, not general-purpose voice support — fits the fundraising use case specifically |
| Configurable Shimmy composition (Stage 2 of the Modularity Ladder) | Pillar II, Part 1.3 | Users and community admins build their own feed logic from exposed primitives — member/access tiering (above) is one part of this |
| Third-party/creator modules and SDK (Stage 3) | Pillar II, Part 1.3 | The genuine platform moment — deliberately deferred until Stage 2 proves the abstraction holds |
| Provenance/authenticity badges surfaced in-feed | Pillar II, Part 5; Shimmy Shield, Horizon 3 | Visible trust signal on fundraiser content, converging product and trust/safety design |
| Agentic feed-assembly modules | Pillar II, Part 1.3; Shimmy Shield, Horizon 4 | Long-horizon — an agent curating a personalised fundraiser-discovery feed on a user's behalf, subject to the provenance layer |
| Moderation-as-a-service labeler | Shimmy Shield, Horizon 3 | A possible new product line if the social web decentralises as expected — Shimmy's calm-norms moderation stack licensed to other clients |