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 static site. No backend, no account system. Every form is a mailto that a human reads and answers.
The Street, Pledge, Standard, Cargo City, Handbook
The festival core and the operating philosophy. This never changes shape.
Party Builder, Paper Terminal, Become a 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. None of that exists yet. Here is what is stuck behind it, and the plan to build it safely.
Live Pledge Race voting (one neighbor, one vote)
Today's ballot is local to your browser and doesn't aggregate. A real one needs authenticated users and a votes table with a unique constraint per user per proposal.
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.