Production Readiness Plan

Tasks and Phased Plan to Take the Platform Live as a Public-Facing Site

v1.0 · May 13, 2026 · Created as part of v3.7.58

1. Overview

Acronyms referenced in this document: Bureau of Labor Statistics (BLS); Occupational Employment and Wage Statistics (OEWS).

The We The People Platform has matured as a documentation package across 121 iterations of refinement. To take it live as a public-facing website that can support the engagement service-level commitments implied by the platform's Contact and Reader Engagement materials, a defined set of production-readiness tasks must be completed. This document catalogs those tasks and proposes a phased plan to accomplish them.

The tasks are organized into seven categories: site reliability, accessibility and compliance, search engine and discoverability, content management workflow, user engagement support, performance and resource optimization, and operational monitoring. Each task includes a priority level, an estimated effort, and dependencies on other tasks where relevant.

The plan is structured in four phases: minimum viable launch readiness, public-facing launch, engagement-active operation, and continuous improvement. Each phase establishes a coherent baseline of capability before adding additional features.

2. Task List

2.1 Site Reliability and Correctness

P0 — Validate all internal links resolve. Walk every HTML page and verify every href either resolves to a real file in the package or to a documented external URL. Catch broken links before the public sees them.

P0 — Verify all calculators render and compute correctly on Safari, Chrome, Firefox, and Edge across desktop and mobile. Test with javascript disabled to confirm graceful fallback.

P0 — Resolve known regression: alignment difference between Home page and Documents page headers. Verify both pages use the templated header without per-page CSS overrides causing subpixel offsets.

P0 — Add a custom 404 page that uses the canonical header and footer and guides visitors back to the platform index.

P1 — Cross-browser regression tests for every page with the calculators (the most complex interactive elements). Document the test matrix and required passing criteria.

P1 — Audit script extensions: codify a check that every linked tool, document, and external URL in the catalog resolves at audit time. Catch broken links automatically.

2.2 Accessibility and Compliance

P0 — WCAG 2.1 AA conformance audit. Test all pages with an automated tool (axe DevTools, WAVE) and manually verify keyboard navigation, screen-reader support, focus indicators, and color contrast meet the AA threshold.

P0 — Add aria-labels and landmark roles where missing. The current site has skip-link anchors but may lack consistent aria-labels on filter pills, navigation, and form inputs.

P1 — Privacy policy review by counsel for federal and state law compliance, particularly regarding visitor data and contact form submissions.

P1 — Cookie and consent banner if the deployed site uses any analytics or tracking that requires consent under GDPR, CCPA, or state-level equivalents.

P2 — Add structured data (Schema.org) for the platform as an organization and for each policy document as an article or report.

2.3 Search Engine Optimization and Discoverability

P0 — Per-page meta description and Open Graph tags. Each public page needs a unique title, description, and og:image so search results and social media previews are meaningful.

P0 — sitemap.xml generated from the catalog and updated automatically on each iteration. Include every public-facing HTML page and document landing page.

P0 — robots.txt with appropriate crawl directives. Allow indexing of public content; disallow indexing of build infrastructure and internal artifacts (data archive, templates).

P1 — Submit sitemap to Google Search Console and Bing Webmaster Tools. Verify indexing.

P1 — Canonical URL tags on every page to prevent duplicate-content issues if the platform is mirrored or accessed via multiple subdomains.

P2 — Internal search functionality across the catalog. Free-text search across document titles, descriptions, and HTML rendering would significantly improve research utility.

2.4 Content Management Workflow

P0 — Document the publication workflow: how a new iteration moves from the local build directory to the deployed Cloudflare Pages site. Include the version bump checklist, the audit pass requirement, and the deployment trigger.

P0 — Establish a rollback procedure. If a deployed iteration introduces a regression, what is the procedure to revert to the previous version without losing the new iteration's intent?

P1 — Automate the deployment pipeline. Currently iterations are built locally and shipped as ZIP packages. A GitHub-Pages or Cloudflare-Pages deployment workflow triggered by a branch push would eliminate manual deployment steps.

P1 — Establish a content review process. Major changes to platform substantiation should have a documented review step before deployment (subject-matter expert sign-off, fact-check pass).

2.5 User Engagement Support

P0 — Working contact form. The Contact page currently displays contact information but lacks a working form with backend handling. Implement a form that delivers messages reliably (Formspree, Netlify Forms, or custom Cloudflare Worker).

P0 — Define the engagement service-level commitments. What response time does the platform promise for inquiries? How are user-reported errors handled? What is the cadence for publishing updates? These commitments should be documented in the Contact page or a dedicated SLA page.

P1 — Newsletter or email-list signup so visitors can subscribe to platform updates. Requires GDPR-compliant signup flow and an email service provider (Buttondown, ConvertKit, or similar).

P1 — Visitor feedback mechanism. A simple feedback widget on each document page (was this helpful, suggest improvement) feeds into the Open Issues Registry workflow.

P2 — Discussion or comment system on substantive documents. Either an integrated comment system or links out to a community forum.

2.6 Performance and Resource Optimization

P0 — Compress all images. The flag-background.jpg is currently full-resolution; web-optimized versions in modern formats (WebP, AVIF) would significantly reduce page weight.

P0 — Minify production HTML, CSS, and JS. The catalog JS alone is 192 KB; minification and gzip compression in transit would reduce bandwidth meaningfully.

P0 — Move the inlined catalog data back to an external file with proper async loading and a fetch fallback. The inline approach in v3.7.58 made the page robust but increased the initial HTML payload to 266 KB. A lazy-loaded catalog would improve time-to-first-paint.

P1 — Lighthouse performance audit on every page. Target a score of 90+ for performance and 100 for accessibility.

P1 — Service worker for offline access to core navigation pages. Visitors with intermittent connectivity can still browse cached content.

2.7 Operational Monitoring

P0 — Uptime monitoring (UptimeRobot, Pingdom, or Cloudflare-native) with alerts to the platform maintainer when the site goes down.

P0 — Error tracking (Sentry, Bugsnag, or similar) for client-side JavaScript errors. The v3.7.58 finding that platform_index.html could silently fail to load its catalog illustrates exactly the kind of issue that error tracking surfaces immediately.

P1 — Privacy-respecting analytics (Plausible, Fathom, or Cloudflare Analytics) to understand traffic patterns and page popularity without tracking individual visitors.

P1 — Logged inquiries pipeline. Contact form submissions should be logged with timestamps and tracked through resolution.

3. Phased Plan

Phase 1 — Minimum Viable Launch Readiness

Goal: ship a public-facing site with no broken functionality and adequate accessibility for general audiences.

Scope: complete all P0 tasks across all seven categories. Critical items include the broken-link audit, the cross-browser calculator validation, the WCAG audit, meta tags and sitemap, the 404 page, the working contact form, image compression, and uptime monitoring. The engagement SLA must be drafted and documented on the Contact page.

Estimated effort: approximately 60 to 80 hours of development plus 10 to 20 hours of review and testing. Phase 1 can be completed in two to three focused weeks of work.

Exit criteria: every page passes the broken-link audit, WCAG audit, and Lighthouse accessibility check. The contact form delivers messages reliably. The 404 page is in place. The sitemap and robots.txt are published. Uptime monitoring is active.

Phase 2 — Public-Facing Launch

Goal: launch the site to a broader audience with confidence in operational stability.

Scope: complete the P1 tasks across all categories. This phase adds error tracking, privacy-respecting analytics, the rollback procedure, the deployment pipeline automation, the newsletter signup, the visitor feedback mechanism, and the cross-browser regression test matrix.

Estimated effort: approximately 40 to 60 hours of development plus ongoing operational review. Phase 2 can be completed in two to three weeks following Phase 1.

Exit criteria: error tracking is logging client-side errors and the maintainer is actively responding to them. Analytics is reporting traffic data. The deployment pipeline is automated and the rollback procedure is documented and tested.

Phase 3 — Engagement-Active Operation

Goal: actively engage with visitors and respond to their feedback and questions, treating the site as a living platform rather than a static document.

Scope: the engagement SLA is in active operation; contact form submissions are tracked through resolution; visitor feedback influences the Open Issues Registry. Periodic content reviews ensure the platform substantiation stays current with new federal data releases (BLS annual OEWS refresh, IRS Statistics of Income, CBO budget projections).

Estimated effort: ongoing. Approximately 10 to 15 hours per week of operational time, scaling with inquiry volume.

Exit criteria: this phase is steady-state, not exit-criteria-driven. The transition to Phase 4 happens as the platform accumulates engagement signals that suggest specific areas for content expansion or architectural refinement.

Phase 4 — Continuous Improvement

Goal: complete the P2 enhancements and continuously refine the platform based on engagement signals.

Scope: structured data tags, internal search functionality, discussion or comment system on substantive documents, service worker for offline access. Each enhancement is justified by engagement signals from Phase 3 (high-traffic pages, repeated questions, specific research patterns).

Estimated effort: ongoing, prioritized against engagement signals. Approximately one enhancement per quarter.

4. Engagement SLA Definition

The platform's contact and reader-engagement materials imply a commitment to respond to visitor inquiries. This section defines the specific service-level commitments the platform makes once it is in Phase 3 operation.

Inquiry acknowledgment: visitors who submit a contact form receive an automated acknowledgment within five minutes confirming receipt of their message.

Inquiry response: substantive responses to visitor inquiries are provided within five business days during Phase 3 steady-state operation. Inquiries flagged as time-sensitive (media inquiries, policy professional consultations, press) are responded to within two business days.

Site reliability: the public-facing site has an uptime target of 99.5 percent. Planned maintenance windows are announced in advance on the Contact page. Unplanned outages are investigated within one hour of detection by the uptime monitoring system.

Content currency: substantiation documents are reviewed quarterly to verify their underlying data remains current. The BLS data archive is refreshed within thirty days of each annual OEWS release. The catalog version log reflects each refresh.

Error response: visitor-reported errors (broken links, calculation errors, content issues) are triaged within two business days. Critical errors (data corruption, calculator miscalculation) are fixed within five business days. Minor errors are batched into the next regular iteration.

5. Open Questions and Decisions Needed

Hosting provider: the platform is currently deployed to Cloudflare Pages. Phase 1 should confirm Cloudflare Pages remains the long-term host or document a migration plan if a different provider is selected (custom infrastructure, GitHub Pages, Netlify).

Custom domain: a custom domain name should be registered and configured before public launch. The current wethepeopleplatform.pages.dev URL is functional but does not project the seriousness of the platform's policy claims.

Email infrastructure: contact form submissions require an email delivery mechanism. Decisions needed on email service provider, sending domain, and DKIM and SPF configuration.

Maintainer identity: the platform is currently attributed to a single individual. Decisions needed on whether to expand to a maintainer team, what governance structure applies to content changes, and how the engagement SLA scales with maintainer capacity.

Funding for sustained operation: Phase 3 steady-state operation requires ongoing maintainer time and email service costs. Decisions needed on whether the platform is funded as a personal project, a sponsored project, a nonprofit, or some other structure that determines sustainability.

6. Tracking and Updates

This document is versioned as a regular platform deliverable. Updates to the task list or the phased plan should be reflected in the version number at the top of the document and in the platform's Open Issues Registry. Specific tasks moving from open to closed should be tracked in Section 47 of the OIR with the standard status flags.

Robertson, J. (2026). Production Readiness Plan. We The People Platform (Version 3.8.46). https://wethepeopleplatform.com/_web_html/05_Analytical_Framing/05_Production_Readiness_Plan.html

Robertson, Jason. 2026. "Production Readiness Plan." We The People Platform v3.8.46. https://wethepeopleplatform.com/_web_html/05_Analytical_Framing/05_Production_Readiness_Plan.html.

@misc{wtpp_2026_114_production_readiness_plan,
  author    = {Robertson, Jason},
  title     = {Production Readiness Plan},
  year      = {2026},
  publisher = {We The People Platform},
  version   = {3.8.46},
  url       = {https://wethepeopleplatform.com/_web_html/05_Analytical_Framing/05_Production_Readiness_Plan.html},
  note      = {Document 114 of 142}
}