Skip to content

Pillar II — Product

Part 1 — Shimmies: From Feature to Platform

1.0 Current product baseline (as built)

Shimmy's product surfaces are currently delivered through:

  • Mobile app: Flutter/Dart client for core social and community usage.
  • Web and internal surfaces: Vue 3 + TypeScript stack for public marketing and internal operations tooling.
  • Core application API: Laravel 11/PHP 8.3+ backend with Sanctum bearer tokens plus API key middleware.
  • Content model in production: posts, comments, reactions, and Shimmy group workflows over versioned API routes.

1.1 What "modular social feed" actually needs to mean architecturally

The risk with "Shimmies" as currently scoped is that it stays a configuration feature (users toggle feed types) rather than becoming a genuine composition system (feeds are built from interoperable primitives that compound in value as more exist). The difference matters enormously for defensibility: a configuration feature can be cloned by a competitor in a sprint; a composition system with an ecosystem around it cannot.

Concretely, a Shimmy should be modelled as a triple:

Shimmy = (Source Selector, Ranking Logic, Presentation Shell)

  • Source Selector — where content comes from (a community, a topic graph traversal, a fundraiser category, a followed-account list, a hybrid).
  • Ranking Logic — how it's ordered (recency, curated, "calm" algorithmic dampening, trust-weighted per the moderation stack).
  • Presentation Shell — how it's rendered (card feed, story-strip, map-based for location-tied fundraisers, digest/summary mode).

Decoupling these three from day one — even while only shipping a handful of native combinations — is what allows later composability (Part 1.3) without a rewrite. This is the single highest-leverage near-term architecture decision, because retrofitting composability onto a monolithic feed implementation 18 months from now is materially more expensive than building the seam now while the surface area is still small.

1.2 Data model implications

Every post is created inside a specific Shimmy — there is no global, contextless compose action, and posting is always an act of posting in a Shimmy, not into the platform generically. A post carries text plus up to five images or videos. This is a deliberate constraint, not a current-scope limitation to relax later: it keeps every piece of content anchored to the community norms, ranking logic, and moderation configuration of the Shimmy it was authored in, which is the foundation the rest of this section's data model depends on.

The Source Selector / Ranking Logic / Presentation Shell split implies a content and interaction data model where:

  • Content objects carry portable metadata (topic tags, community ID, fundraiser linkage, provenance/trust signals from the moderation stack) independent of which feed(s) surface them — a post's origin Shimmy is fixed at creation, but the post object itself can still be surfaced, differently ranked and shelled, in other Shimmies' Source Selectors without duplication. Posting and surfacing are deliberately different operations: a user posts in exactly one Shimmy; a Source Selector elsewhere may choose to display that post downstream.
  • Ranking Logic should be swappable per-user or per-community, not global — this is both a product differentiator (communities set their own norms, echoing the moderation brief's "community-local norm embeddings") and a technical requirement for the eventual third-party module ecosystem.
  • User-level Shimmy compositions (which combination of selector/ranking/shell a given user has assembled) should be a first-class, storable, shareable object — this is what eventually allows users to share/export their feed configuration, which is a meaningfully viral, low-cost growth mechanic (Part 1.4).

1.3 The Modularity Ladder — sequencing

Reiterating and expanding the ladder from the master architecture:

Stage What ships Rough timing Strategic purpose
1. Native modules In-house-built Shimmies: community feed, fundraiser feed, calm/curated feed, "close friends" feed Now (V1/Beta) Prove the core mechanic and content model works before generalizing
2. Configurable modules Users/community admins compose from exposed primitives — choose source + ranking dampening + shell ~12–24mo Validates the triple-decomposition holds up under real usage patterns before opening to third parties
3. Third-party/creator modules SDK + review process for external developers/creators to publish Source Selectors or Presentation Shells ~Year 3–5 The actual platform moment — analogous to app-store/Shopify-app-style ecosystem value capture
4. Agentic modules Modules that actively curate/act (e.g., an agent that assembles a personalised fundraiser-discovery feed based on a user's stated causes, subject to the cognitive-defence/provenance layer from the moderation brief) Year 7+ Converges with Horizon 4 of the moderation brief — feed composition becomes agent-mediated

Do not attempt to skip to Stage 3 early. The temptation with a "modular" pitch is to overpromise an open ecosystem before the primitives are proven — this is the most common platform-strategy failure mode (shipping an SDK against an unstable core abstraction, forcing a breaking migration on early third-party developers, which poisons ecosystem trust permanently).

1.4 Growth mechanic embedded in the architecture

Because Shimmy compositions are portable, storable objects (1.2), the natural low-CAC growth loop is shareable feed configurations: a user builds a genuinely good "calm news + local fundraisers" Shimmy and can share it as a link/template others can adopt. This is architecturally cheap once the data model decision above is made correctly, and gives Shimmy a growth mechanic that is native to the product thesis rather than a bolted-on referral programme — worth prioritising in the roadmap specifically because it compounds with the platform strategy rather than competing with it for engineering time.

Part 2 — Platform & Device Roadmap

2.1 Near-term: mobile, web, and the flip/foldable form factor

Foldable and flip-form devices (cover-screen glanceable UI, vertical-fold aspect ratios when open) are a genuinely near-term, non-speculative product surface — not a Horizon-6 bet. Two specific implications for Shimmy:

  • Cover-screen/glanceable mode: Shimmy's calm positioning is unusually well-suited to a glance-then-decide interaction model (check a fundraiser's progress, see if a close-friends post needs a response, without opening the full app) — this is a low-engineering-cost, high-brand-coherence opportunity to differentiate from doomscroll-optimised competitors who have no incentive to build good glanceable summaries (a glance is the opposite of what maximises their session time).
  • Vertical-fold unfolded aspect ratio: card-based Shimmy shells generally adapt well; story-strip or map-based shells need explicit responsive testing — should be a checklist item in the design system, not an afterthought per-release.

2.2 Mid-term: wearable and voice-native surfaces

The realistic near-to-mid-term wearable use case for Shimmy is notification-and-glance parity, not full app parity — fundraiser milestone alerts, community check-ins. Voice-native interaction has a specific, non-generic fit for the fundraising use case (voice-initiated donation/status-check flows), which should be scoped as a targeted feature rather than a general "add voice support" initiative.

2.3 Long-term: agentic/ambient convergence

By the point agents mediate significant user interaction (see moderation brief Horizon 4), the Shimmies architecture decision in Part 1 pays off directly: a well-decoupled Source Selector / Ranking Logic / Presentation Shell system is exactly the shape needed for an agent to assemble a feed on a user's behalf, subject to the same provenance/trust layer. Product and trust/safety architecture should be reviewed jointly at this horizon rather than treated as separate roadmaps — recommend an explicit cross-functional review checkpoint once Stage 3 (third-party modules) is live, since that's the point where the two roadmaps' assumptions first have to hold simultaneously under real third-party pressure.

Part 3 — Feature & Social-Norms Codex

Every feature signals a social norm, whether intentionally designed or not. This should be an explicit, living document (not left implicit), because unexamined norm-signalling is where "calm social network" positioning most commonly erodes in practice. A few concrete examples worth codifying early:

  • Read receipts / "seen" indicators: signal obligation-to-respond, which is in direct tension with "calm." Recommend defaulting off, or making them opt-in per-community rather than platform-wide.
  • Follower/following counts: a core doomscroll-platform status mechanic; even displaying them prominently re-introduces the comparison dynamics Shimmy is positioned against. Worth a deliberate design decision (de-emphasise, or contextualise differently — e.g., "supporters" framing on fundraiser profiles rather than generic follower counts).
  • Streaks/gamification mechanics: powerful for engagement, directly in tension with "less doom, more do" if used to manufacture anxiety-driven return visits rather than genuine value. If used at all, should be scoped only to pro-social behaviours (consistent fundraiser support, community contribution) rather than app-open frequency.
  • Notification design: the single highest-leverage lever for the calm-vs-doomscroll distinction in practice — batched/digest notifications by default, with real-time reserved for genuinely time-sensitive items (a fundraiser you back reaching goal, a close-friend direct interaction).

This codex should be a required review step in the product spec process for any new feature, not a retrospective audit — the cheapest point to catch norm-misalignment is before a feature ships, not after usage data shows it eroded trust metrics.

Part 4 — Meaning, Resonance & Value: Making It Measurable

"Impact and resonance and meaning and value" is only a real product discipline if instrumented. Recommend defining and tracking resonance metrics alongside standard engagement metrics from V1 onward, reviewed with equal seriousness at the leadership level:

Metric What it captures How to measure
Time-well-spent ratio Whether sessions leave users better or worse off Lightweight post-session sentiment sample (occasional, non-intrusive prompt) compared to session-start baseline
Completed-intent rate Did the user achieve what they opened the app to do Instrumented task completion (checked a fundraiser, responded to a close friend, made a donation) vs. aimless scroll sessions
Regret rate Self-reported "wish I hadn't spent that time" Periodic lightweight survey, tracked as a north-star inverse metric
Real-world action rate Donations completed, fundraisers created/shared, offline meetups arranged via the platform Direct product-native tracking — this is Shimmy's most differentiated possible metric given the GoFundMe integration, and should arguably be the headline metric in investor and board reporting, not a footnote

The strategic point: these metrics only earn credibility if they're sometimes allowed to trade off against engagement/DAU in actual product decisions — if resonance metrics are tracked but never override an engagement-maximising decision, they become marketing theatre rather than product discipline, which undermines the brand positioning they're meant to support.

Part 5 — Trust & Moderation Integration Points

This section deliberately doesn't duplicate the existing moderation brief — it flags the specific points where Product and Trust/Safety architecture must be co-designed rather than sequenced:

  • Community-local norm embeddings (moderation brief, Horizon 1) require the Shimmies data model to expose community/context identifiers cleanly — this is a shared dependency, not two separate features.
  • Provenance/authenticity signals (moderation brief, Horizon 3) should surface directly in the Presentation Shell layer (e.g., a trust badge on fundraiser content) — this is a product decision as much as a trust decision, and should be designed jointly.
  • Resonance metrics (Part 4) and moderation's calibrated-abstention design both depend on capturing user sentiment/state without being intrusive — worth sharing instrumentation infrastructure rather than building two parallel lightweight-survey systems.

Summary: What to Build Now vs. Defer

Build now (V1–18mo):

  • The Source Selector / Ranking Logic / Presentation Shell decoupling — even for a small number of native Shimmies, this seam must exist before the surface area grows.
  • Glanceable/cover-screen mode for foldable form factors.
  • Notification-design overhaul as the primary lever for calm positioning.
  • Resonance metrics instrumentation (start collecting even before it drives decisions, so there's a baseline).

Defer deliberately (Year 2–5):

  • Configurable module exposure to end users (Stage 2) — only once native Shimmies prove the abstraction holds.
  • Third-party SDK (Stage 3) — resist pressure to announce this before Stage 2 is validated in production.

Long-term, revisit as context changes (Year 6+):

  • Agentic modules and full agent-mediated feed composition — track alongside the moderation brief's Horizon 4 rather than planning in isolation.