SysFlow

Inspiration

We’re building SysFlow because people we care about—friends living with DID and OSDD—need tools that actually support how plural systems function in everyday life. One of us has spent a long time closely watching friends navigate this: trying to track who’s fronting, keep track of system members, and reconstruct timelines—not out of curiosity, but as a way to reduce confusion, support internal communication, and stay grounded when memory and continuity become difficult. The other came in after hearing these experiences firsthand and wanted to help build something that genuinely addresses those needs.

Recently, the landscape around plural-focused apps has felt increasingly unstable. The shutdown or disruption of platforms like Simply Plural and Octocon hasn’t just meant “find another app.” For many people, it has meant losing routines that took months or years to build, dealing with data that doesn’t transfer cleanly, and losing trust that the next tool will still be there in the near future. For something as personal as system records, that instability has a real and lasting impact.

What remains on the market often doesn’t line up with what people actually need. Many tools struggle with large systems—dozens or even hundreds of headmates aren’t edge cases, but apps frequently treat them that way, leading to slow performance, awkward navigation, or hard limits that force users to simplify their reality to fit the software. Others introduce friction at the worst times, with interfaces that require too many steps or aren’t designed for quick, low-effort logging during everyday life. And too often, core features—reliable front tracking, clear history, journaling, and basic privacy—are incomplete, buggy, or no longer actively maintained.

SysFlow is our attempt to address that gap. It isn’t meant to replace community or professional support, but to provide a stable, privacy-conscious foundation people can rely on day to day. We’re focusing on supporting large systems without compromise, reducing friction through clear and calm design, and treating front history, member profiles, and journaling as essential features rather than afterthoughts.

This is the beginning, not a finished solution. We’re building SysFlow with the intention to grow it over time, guided by what plural users consistently say they need—so people don’t have to choose between tools that only partially work and having no tool at all.

What it does

SysFlow is a web app for plural systems (often in the context of DID/OSDD). It gives a system a single place to:

• See who is fronting and track front sessions over time (including co-fronting as separate per-headmate segments where that applies).
• Manage headmate profiles (names, details, custom fields).
• Keep a private journal and tag who wrote an entry.
• Review front history (timeline, edits) and open analytics (switches, durations, per-headmate stats, time-of-day patterns) computed from their own data—no generative AI; it’s their logs turned into summaries they can opt into.
• Stores a journal entry hash on Solana if the headmate desires it It’s built as a practical daily tool, not therapy or diagnosis: users choose what they log and how they name their experience.

How we built it

We used TypeScript end-to-end. The main product is a Next.js (App Router) app with React, Tailwind CSS, and next-themes for theming. MongoDB is the datastore, accessed with Mongoose (and the mongodb driver where needed). NextAuth.js handles sign-in (email/password and optional Google). Most behavior lives in Next.js API routes (/api/...) plus server-side helpers for front state, journal CRUD, and analytics. A small Express service in the repo acts as an extra Node scaffold (e.g. health checks), while the plural-specific features are centered in the Next app. Solana was added for a narrow, optional purpose: committing a fingerprint of each journal entry on chain—specifically, a SHA-256 hash of a canonical version of the entry, written as a small memo transaction. That provides an independent, verifiable record that a particular version of an entry existed at a given time: anyone with the same content can recompute the hash and check it against what’s on chain. It is not a backup (the chain does not store your journal text), not a replacement for your database, and not required for normal use—it’s an extra layer of tamper-evident timestamping for people who want a public, auditable anchor alongside their private notes.

Challenges we ran into

• Modeling fronting accurately—especially co-fronting and “who ended when” without losing nuance or double-counting time in confusing ways.
• Time zones and ranges for analytics: making charts and buckets match the user’s local calendar using Intl and consistent clipping of intervals to the selected window.
• Performance and fairness for larger systems—lists, filters, and analytics need to stay usable when a system has many headmates and a long history (e.g. bounding query size, sensible caps, clear UX when data is truncated).
• Polished UX under constraints—modals, multi-selects, and long lists on small viewports (scroll, focus, click-outside) took iteration so the app feels reliable, not fragile.
• Auth + data isolation—keeping everything scoped to the right system workspace while still making local/dev workflows workable.

Accomplishments that we're proud of

• Shipping a coherent vertical slice: accounts → dashboard → headmates → front history + analytics → journal, all backed by real persistence instead of only mocks.
• Analytics that stay on our stack—aggregations run from Mongo + our own code, so insights aren’t tied to a paid black-box AI API.
• A UI direction that aims for clarity and calm on sensitive data: readable structure, theming, and copy that respects user agency.
• Building something motivated by people we know—friends with DID/OSDD who need tools that don’t disappear or break the workflows they depend on.

What we learned

• How much domain nuance matters for plural tooling: small product decisions (e.g. how a “switch” is recorded) affect trust and daily usability.
• Next.js API routes + Mongoose are a strong combo for rapid full-stack features, but data modeling and migration/edge cases need attention early.
• Accessibility and layout details (scrolling regions, portals, viewport sizing) are where “it works on my machine” often falls apart—and fixing them is worth it.
• Clear disclaimers (“tool, not treatment”) aren’t legal fluff—they align expectations with what software can safely promise.

What's next for SysFlow

• Social / “friending” — a future way to connect with other systems (with clear privacy controls), so trusted friends can optionally see sanitized or shared views—not a dump of private medical data by default.
• Imports from tools people already use — support for bringing data in from PluralKit, Simply Plural, Octocon, and similar apps so migration isn’t “start from zero” when someone switches platforms.
• Scale for large systems—pagination, search, and performance paths for 100+ headmates and heavy history without degrading UX.
• Export / import and backup flows so users aren’t locked in if they migrate or a host changes.
• Mobile-first polish (PWA or native shell) for quick front logging on the go.
• Deeper privacy controls (per-entry or per-field rules, sharing boundaries) as the data model grows.
• More quality-of-life features driven by real users: reminders, richer journal tools, notifications (opt-in), and continued hardening of analytics edge cases.

Built With

• bcryptjs
• eslint
• express.js
• javascript
• mongodb
• mongoose
• next-themes
• next.js
• nextauth.js
• node.js
• react
• solana
• tailwind-css
• tsx
• typescript
• vercel