The Roadmap
What's live, what's next, and what we've deliberately not built yet, with the real reason, not a vague "coming soon."
Live today
Everything below is a real, working site, mostly static. There is no general account system. A few features use Supabase where they need to keep something: studio sign-in, the Oath, the Pledge Race ballot and a kept Brokedex, each described in the Trust Center. Most forms are still a mailto that a human reads and answers.
The Street, Pledge, Standard, Loophole, Handbook
The festival core and the operating philosophy. This never changes shape.
Party Builder, Paper Terminal, Broke DJ
Real client-side tools. Planning math, paper trading, and a full browser DAW.
The Hub. Grants, Learn, Civic, Pipeline, Network
The resource layer. See below for exactly how far each one goes today.
Privacy, Terms, Community Guidelines, this page
Draft legal docs matched to what actually exists, pending attorney review.
What needs a backend before it's real
A backend means three things. A real database. Real logins. And a server that can check who owns what. Supabase now provides the first two for a few named features, and the one-person-one-vote ballot was the first thing built on it. Here is what is still stuck behind the rest, and the plan to build it safely.
Live Pledge Race voting (one neighbor, one vote)
This used to say the ballot was local to your browser. It is not any more: the vote needs a sign-in, keeps one ballot per person per proposal on the server, and publishes the count. How a ballot is stored, and why nobody can reconstruct yours, is in the Trust Center.
Copper Reservoir payment rails
Giving opens an email right now. Real payments need Stripe or similar. They also need PCI-compliant handling, which means card details never touch our server. Plus a public ledger that matches the split we showed you when you gave.
Verified Submissions ("how bad the world is" reports) with ID
Today, "verified" means a human confirms you're reachable by email and phone, see Community Guidelines. Adding government ID verification is a deliberate v2, not an oversight.
Crime & safety map, lawsuit / class-action tracker
These need licensed or public-API data feeds (FBI NIBRS, state open-data portals, ClassAction.org-style aggregators), not fabricated placeholder data. Building the UI before the data pipeline exists would mean showing people numbers we made up.
What we're deliberately not building at all (yet)
Politician profiles with religion, family members, and donor data
A "lie tracker" that labels a real, named public official as having broken a promise is a factual claim about a real person. Getting it wrong, or publishing it without rigorous, disclosed sourcing. Is real legal exposure, and it needs an editorial policy and legal review before a single profile goes up, not after.
Medical tourism / "insurance replacement" routing
Florida's Patient Brokering Act (F.S. 817.505) makes it a felony to take anything of value for sending patients to a specific treatment provider. So a tool that ranks clinics and points people at them needs a healthcare lawyer to sign off first. Not a disclaimer bolted onto a page later.
Live multi-model "AI Council" (GPT + Claude + Grok + DeepSeek consensus)
This calls four paid APIs. That needs a server to hold the keys. Keys can never sit in the page itself, because anyone who opens dev tools can copy them. It also needs a real budget, since every question costs money four times over. It is genuinely buildable once there is a backend. It is not something we will fake with placeholder text pretending to be four models.
Security, for real
Two specific things were asked for that only make sense once a backend exists. Documenting the right answer now, so it gets built correctly the first time.
A static site has no server of its own to log requests. Netlify's access logs are the IP log today, or Cloudflare's if you put it in front. That is genuinely enough to chase abuse, and we store nothing extra. Once real accounts exist, we log authentication events. Logins, password resets, ID checks. Each with IP and timestamp, kept on a stated schedule and disclosed in the Privacy Policy. What we will not do is log every page view. That is more surveillance than security, and it is not needed to catch abuse.
This is called an Insecure Direct Object Reference.
Picture an address like /api/report/742.
It hands back whatever record number you ask for.
It never checks whether you are allowed to see it.
Here is the fix. It is non-negotiable on every endpoint we build:
- · Use non-guessable IDs (UUIDs), never sequential integers, for anything referenced in a URL
- · On every read and every write, the server asks one question. Does this logged-in user actually own this record? Never trust the client to send only IDs it is allowed to see
- · Use database-level Row Level Security (Supabase RLS policies) as the enforced floor, not just an application-layer check that a future refactor could accidentally skip
- · Rate-limit every endpoint so sequential ID-guessing gets throttled and logged as a probable attack, not silently answered
Everything above lives here so the plan is as visible as the product. If something on this page should move faster, or you disagree with a call, say so.