TRANSPARENCY

How FloorRadar gets built.

Most SaaS products tell you what they ship. Few tell you how the decisions get made, what gets deferred, or what review process surrounds a change before it goes live. This page is the inverse — it's the operational map.

Review cadence — every change passes through 4 councils

Every non-trivial change to FloorRadar goes through a structured review before it ships. Each council is a focused pass with a written report, and a verdict of APPROVE / REVISE / REJECT. Reports are committed to the repo at docs/reviews/{date}-{surface}-{council}.md.

• Design Council — pre-implementation. Catches architectural mistakes, data-model misfits, and UX gaps while they're cheap to fix.
• Schema Council — pre-DDL. Catches Postgres syntax bugs, race conditions, missing rollback paths, and stale assumptions about production state.
• Security Council — pre-implementation threat model. Catches authentication gaps, replay vectors, takeover surfaces, PII handling violations.
• Pre-commit Council — final gate before any migration ships. Verifies every prior council's findings are addressed.

For features touching pricing, positioning, or marketing copy, an additional Boardroom Council reviews the work — a 5-seat advisory pass modeled on real-world frameworks for pricing strategy, positioning, retention, and small-business marketing.

None of these councils ship code themselves. They produce reports. The implementer reads the reports, addresses every BLOCKER finding, and only then proceeds. If a finding is deferred, that decision is documented.

Security posture

The security tracker (docs/SECURITY-TRACKER.md) lists every security finding ever surfaced — open and closed — with severity, fix path, and verification notes. Tracked findings range from CRITICAL (e.g., RLS-disabled on main tables before v1.0.0) to informational (e.g., XSS blast-radius implications of caching claim lists in JWT app_metadata).

Open finding count is published on each release via the changelog. We don't ship features that introduce a CRITICAL finding without an in-release fix or an explicit P0 tracker entry. Anything we can't fix today gets a HANDOFF doc with exact steps for when we can.

For vulnerability reporting: see /legal/security. Response SLAs: 2-day acknowledgment, 5-day severity assessment, 7-day patch on critical findings.

What's public, what's private, what's on the roadmap

Three documents drive the product direction. Two are public:

• Public Roadmap — feature-level milestones, generic-language. Anyone can read it.
• Changelog — every release with what shipped, what regressed, what's deferred.

The third — the internal SaaS plan and tactical roadmap — stays private. It contains specific endpoint names, security tracker ID cross-references, and decision rationale that would help competitors more than it would help customers. The public roadmap describes the same work in user-facing terms.

How decisions get made

Three rules govern technical decision-making here:

• Layman terms. If a customer can't understand the explanation, the explanation is wrong. Internal docs use jargon when it's faster; customer-facing surfaces don't.
• Brutal honesty. If something doesn't work, the explanation says so. If a feature was deferred because it was too expensive to build right now, that's stated. We don't dress up regressions as "improvements."
• Facts, not assumptions. Every claim that informs a decision gets verified — schema state via direct query, performance via EXPLAIN ANALYZE, customer behavior via analytics. We don't ship based on what we hope is true.

These rules apply equally to internal review and to anything written for customers.

What gets deferred (and why)

The deferred-handoff list (docs/HANDOFF-DEFERRED.md) tracks every item that can't be done autonomously. Some require external service signups (Stripe, PostHog, domain DNS). Some require founder approval for risk reasons (database migrations, deletions, public communications). All have an explicit "this is deferred because" reason and a "this is what unblocks it" path.

The deferred list is internal — it carries operational detail that doesn't help customers — but the existence of the discipline matters. Nothing falls through the cracks because there's nowhere for it to fall to.

Operational discipline at this stage

FloorRadar is being built the way a small, focused operator should run software:

• One repository, full git history — every change attributable to a commit, every commit reviewed before push
• Migrations require explicit approval — no automated DDL on production. Founder reads the SQL, reviews blast radius, approves explicitly.
• RLS on every user-facing table — Row-Level Security is enforced at the database, not in client code. Application bugs can't bypass authorization rules.
• Idempotent webhooks — every external integration (Stripe, etc.) is built to tolerate retries safely. Replays don't double-charge or double-credit.
• Public sentinel monitoring — Sentry catches client-side errors; Supabase logs catch server-side. We see breakage before customers report it.

What we don't do (and probably won't)

• "Sales calls" or "white-glove onboarding." FloorRadar is self-service. Sign up, claim your venue, see your numbers. If you can't get value in the first session, the product is wrong; we'd rather know quickly than have a salesperson paper over it.
• Custom enterprise contracts at small scale. Enterprise tier exists for legitimate 16+ venue operators with custom needs. Below that, the standard tiers apply uniformly. No special pricing, no exemptions.
• "Move fast and break things." The product handles other people's revenue numbers and acquisition pipelines. We move fast on product surfaces and slow on data integrity. Two different speeds.

Open commitments

These are public commitments that we hold ourselves to:

• 7-day refund on first-time signups. No survey, no exit interview. Email support@floorradar.com with subject line "refund."
• Existing-customer pricing grandfather. If pricing changes, your tier price doesn't.
• No "feature gating" on data you've already paid for. If your subscription provides a dataset, downgrading doesn't lock you out of the data you already accessed.
• Cancellation any time, no retention dance. One-click cancel via Stripe Customer Portal.

These show up in the legal docs (/legal/tos) and the help center (/help/refund-policy). If a future change weakens any of these, we'll publish that change first, give existing customers grace, and not retroactively apply.

Questions about this

Email support@floorradar.com with subject line "Transparency question." We read every one.