SupportSpark: A Lightweight Support Network Without the Noise

The Problem with How We Share Difficult News

When someone is going through a tough time—an illness, a loss, a major life change—there's an immediate coordination problem. Friends and family want to know what's happening. The person at the center doesn't have the energy to send individual updates to thirty different people. So what usually happens?

Someone posts on Facebook. Or starts a group text. Or a well-meaning friend creates a GoFundMe page even when money isn't the issue. Every existing tool for this comes loaded with baggage: ads, algorithms deciding who sees what, notifications designed to maximize engagement rather than minimize stress, and commercial platforms that treat your difficult moment as content to drive their metrics.

It's a reasonable question to ask: could we build something simpler? A clean, focused process where one person posts an update and everyone who needs to see it just... sees it? No ads, no algorithmic feed, no engagement optimization. Just information flowing from one person to the people who care about them.

That's the idea behind SupportSpark. It's the latest in my Spark series of projects, alongside ArtSpark, MuseumSpark, and TeachSpark—each one exploring a focused problem with a lightweight solution.

What SupportSpark Actually Does

The concept is deliberately narrow. A member creates a "journey"—a named context for their situation. They post updates when they have something to share. Supporters who've been invited can read those updates and leave responses in threaded conversations. That's essentially it.

There's no public feed. No follower counts. No sharing buttons. No recommendation engine suggesting you also follow someone else's medical journey. The person at the center controls who's in and who's out through an invitation system.

This constraint is the entire point. Most platforms fail at this use case not because they lack features, but because they have too many features pulling in the wrong direction.

You can try the interface right now on the SupportSpark preview site. It's a GitHub Pages deployment that uses localStorage to simulate the full experience—no server required, no account needed. It's a good way to see whether the approach makes sense before committing to a backend.

Building It: Choosing the Right Weight Class

The project started in February 2026 with a constitution—ten core principles documented before any code was written:

• Type Safety First: TypeScript strict mode and Zod schemas for runtime validation
• Testing as a Non-Negotiable: Every feature needs automated tests
• Accessible UI: shadcn/ui components built on Radix primitives
• Progressive Security: Bcrypt hashing, rate limiting, CSRF protection
• Simplicity Above All: YAGNI (You Aren't Gonna Need It) as the mantra

The tech stack was chosen to keep things lightweight while still being production-capable:

• Frontend: React 19 with functional components, Wouter for routing, TanStack Query for state
• Backend: Express 5 with TypeScript, Passport.js for auth, file-based storage for simplicity
• Styling: Tailwind CSS with Framer Motion animations
• Build: Vite for fast development, CommonJS output for IIS compatibility

Notice what's missing from that list: no database server, no cloud-hosted backend services, no subscription billing integration. File-based storage handles the data layer. The whole thing can run on a single Windows server with IIS. That's a deliberate choice—this isn't a platform that needs to scale to millions of users. It needs to work reliably for small groups of people.

The Development Process

Phase 0: Making Decisions Before Writing Code

Every technical choice was documented with rationale before implementation. Password security: bcrypt with 10 rounds. Rate limiting: express-rate-limit. Testing: Vitest with React Testing Library. This might seem like overhead for a small project, but it prevents the kind of mid-project debates that slow things down.

The architecture followed a contract-first approach—shared TypeScript interfaces between client and server. The client handles UI, the server manages data, and a shared package defines the contracts between them. Clean boundaries make it easier to change one side without breaking the other.

Phase 1: Building the Core

The feature set stayed focused on the core workflow:

• User Authentication: Secure login/signup with session management
• Journey Updates: Members post updates, supporters read and reply in threads
• Invitation System: The member controls who has access—no open registration
• Responsive Layout: Works on phones and desktops without a separate mobile app
• Demo Mode: Try the interface without creating an account

From initial setup to a working application took about three weeks. Not because the team was large (it wasn't), but because a narrow scope means fewer decisions to make.

Where It Got Interesting

A few challenges came up that are worth noting because they apply broadly to small web projects.

Dependency Upgrades

Express 4 to 5, Tailwind 3 to 4—major version bumps in the middle of active development. Phasing the upgrades rather than doing them all at once kept things stable. It's tempting to just upgrade everything, but breaking changes in two dependencies at the same time makes debugging miserable.

Security Without Over-Engineering

The constitution required security measures, but not all of them at once. Alpha: bcrypt and environment variables. Beta: add rate limiting. Production: full CSRF protection. This progressive approach makes sense for a project where the threat surface changes as the audience grows. You don't need production-grade rate limiting when three people are testing locally.

Windows and IIS: An Unusual Choice

Most modern web tutorials assume Linux and Docker. SupportSpark targets Windows Server with IIS—partly because that's the existing infrastructure, partly to see what the developer experience looks like in 2026. CommonJS builds, web.config files, PowerShell deployment scripts. It works, and it's one fewer server to manage if you're already running Windows.

Resisting the Urge to Add Features

File-based storage instead of Postgres. No real-time WebSocket notifications. No image uploads. Every feature request gets filtered through "does this serve the core use case?" Most of the time the answer is not yet. For a small support network, you don't need a notification system—people check when they want to check. That's actually the point.

Current Status

As of February 2026, the beta includes:

• Authentication and session management
• Journey creation and update posting
• Threaded supporter conversations
• Invitation-based access control
• Test coverage across hooks and pages
• IIS deployment with PowerShell automation
• A static demo mode for trying the interface

The UI uses a muted teal/sage palette. It's deliberately calm—not because calm is trendy, but because someone reading a health update from a family member doesn't need bright orange call-to-action buttons competing for their attention.

There's also a live preview on GitHub Pages that uses localStorage in place of the server backend. It gives you the full UI experience—creating journeys, posting updates, managing invitations—without needing to stand up the Express server. It's useful both as a demo and as a way to iterate on the frontend independently.

What's Next

The honest answer is: it depends on whether people actually use it. The next steps are production deployment with the full security stack, then getting it in front of a few real users and seeing what happens. Maybe it needs a mobile app. Maybe file storage needs to become a database. Maybe the invitation system needs a different flow entirely. Those are decisions that should come from actual usage, not speculation.

The broader question—whether a purpose-built, commercial-free tool can serve this need better than existing platforms—is still open. But the technical foundation is in place to find out.

What I Took Away from This

Writing a project constitution before any code sounds like ceremony, but it paid off. When you're deciding whether to add a feature, having documented principles to check against is faster than having a debate.

Starting with file-based storage felt like cutting a corner, but it turned out to be the right call for a beta. You can always migrate to a database later. You can't easily undo the complexity a database adds to deployment, testing, and local development.

Progressive security—adding protections as the attack surface grows—kept the project moving without leaving obvious holes. It's a pattern I'd use again for any project that starts with internal testing and gradually opens up.

And the biggest one: not every problem needs a platform. Sometimes a small, focused application with clear boundaries does the job better than a feature-rich system trying to be everything to everyone. Social media platforms aren't bad at support coordination because they lack features. They're bad at it because their incentives point in the wrong direction.

You can explore the SupportSpark project page for a full overview, try the live preview, browse the repository metrics and activity, or dive into the source code on GitHub to see the codebase and constitution.