Test document

publicv1review complete
2h ago
1 views2 comments1/1 reviews6 min readdeadline: 5/1/2026

Sample Document — Acme Corp Website Rebuild

A sample document exercising the usual suspects in Markdown rendering: headings, lists, tables, code, math, diagrams, footnotes, images, blockquotes, task lists, and a few edge cases. Drop it into any Markdown renderer to see what survives.

Acme Corp wants to rebuild their public website to modernise the brand, improve mobile performance, and add a customer self-service portal. This document describes the scope, deliverables, and acceptance criteria for the engagement.

The work is scheduled across three phases running from May through November. See Timeline for details.

"Move fast on the public site rebuild — we want it live before the Q3 product launch." — Sarah Chen, Head of Marketing


Acme has operated their existing website1 since 2018. The current platform has accumulated significant technical debt:

  • Page load times average 3.8 seconds on mobile (target: <1.5s)
  • Bounce rate is 62% on mobile devices
  • Content updates require a developer in the loop
  • The customer portal is a third-party iframe with no SSO

A previous rebuild attempt in 2023 was abandoned due to scope creep. This engagement scopes the work tightly to avoid that outcome.

For more context, see the original brief and the 2023 retrospective.

#Footnotes

  1. Currently running WordPress 5.x on a managed Bluehost instance.

#In scope

  • New responsive marketing site (5 core pages + blog + careers)
  • Customer self-service portal with SSO via Okta
  • CMS migration from WordPress to a headless solution
  • Performance optimisation to meet the <1.5s mobile load time target
  • Analytics instrumentation (events, conversions, funnels)
    • Conversion events on every CTA
    • Funnel tracking from landing → portal signup
    • Heatmaps on the top 10 landing pages

#Out of scope

  1. Mobile app development (separate engagement)
  2. Email template redesign (handled by marketing internal)
  3. Backend API changes outside the customer portal
  4. Translation/localisation (English only)
  5. Migration of historical blog content older than 2024

#Optional add-ons

  • Multi-region CDN configuration
  • A/B testing framework integration
  • Live chat widget (Intercom or Drift)
  • Advanced personalisation rules
  • Initial accessibility audit (committed)
PhaseDeliverableOwnerDue
1Information architecture + wireframesDesign lead2026-06-15
1Component library (Figma + code)UI engineer2026-07-01
2Marketing site implementationFrontend team2026-08-15
2CMS migration + content loadPlatform team2026-09-01
3Customer portalFull-stack team2026-10-15
3Performance + accessibility auditQA lead2026-11-01
3Production cutoverDevOps2026-11-15
May ──┬─── Discovery & IA
      │
Jun ──┼─── Wireframes & components
      │
Jul ──┼─── Marketing site build
      │
Aug ──┼─── CMS migration
      │
Sep ──┼─── Portal build
      │
Oct ──┼─── QA & audit
      │
Nov ──┴─── Cutover & launch

The new site uses a Jamstack approach with a headless CMS, static-site generator, and serverless functions for dynamic features. Contact at [email protected] for design questions.

#Stack

frontend:
  framework: Next.js 15
  styling: Tailwind CSS
  components: shadcn/ui
cms:
  headless: Sanity
  content_lake: real-time
backend:
  api: Next.js API routes
  auth: Okta (OIDC)
  database: PostgreSQL (Supabase)
deployment:
  edge: Vercel
  cdn: Cloudflare in front

#Component example

// app/components/Hero.tsx
export function Hero({ title, subtitle, cta }: HeroProps) {
  return (
    <section className="hero">
      <h1 className="text-4xl font-bold">{title}</h1>
      <p className="text-lg text-gray-600">{subtitle}</p>
      <Button variant="primary" href={cta.href}>
        {cta.label}
      </Button>
    </section>
  );
}

#Data flow

Risk: CMS migration loses content metadata or breaks URLs. Mitigation: Full content audit before migration; 301 redirect map for every changed URL; staging environment validation with stakeholder sign-off.

Risk: Performance target (<1.5s mobile) not met after build. Mitigation: Performance budget enforced in CI; Lighthouse scores tracked per PR; final audit before cutover with go/no-go gate.

Risk: Okta integration delays. Mitigation: Mock SSO in dev environment from week 2; integration testing in week 8 to surface issues early.

PhaseEffortCost (USD)
Phase 1 — Discovery & design320 hours$48,000
Phase 2 — Marketing site & CMS480 hours$72,000
Phase 3 — Portal & launch600 hours$90,000
Total1,400 hours$210,000

Payment terms: 30% on signature, 30% at end of Phase 1, 30% at end of Phase 2, 10% at production cutover.

  • All marketing pages live and matching approved designs
  • Customer portal accessible via Okta SSO
  • Mobile Lighthouse score ≥ 90 across all categories
  • Page load time < 1.5s on 4G mobile (median)
  • WCAG 2.1 AA compliance verified by audit
  • All redirects from old URLs functional
  • CMS editor onboarding completed for marketing team
  • Analytics events firing for all key conversions

#Glossary

CMS : Content Management System. The headless CMS in this project is Sanity.

Jamstack : Architecture pattern combining JavaScript, APIs, and prebuilt Markup.

OIDC : OpenID Connect — the auth protocol layered on OAuth 2.0 used by Okta.

SSO : Single Sign-On. Users authenticate once and access multiple apps.

#References

#Mathematical formulas

The page load budget is calculated as:

$$ T_{load} = T_{ttfb} + T_{render} + T_{interactive} $$

Where each component is bounded such that $T_{load} \leq 1.5s$ on a 4G connection. Inline: page weight $\leq 200KB$ above the fold.

#Image example

Sample architecture diagram

#Code in multiple languages

Python:

def calculate_budget(phases: list[Phase]) -> int:
    return sum(phase.hours * phase.rate for phase in phases)

Bash:

#!/usr/bin/env bash
npm run build && vercel --prod

SQL:

SELECT user_id, COUNT(*) AS sessions
FROM events
WHERE event_type = 'page_view'
  AND created_at >= NOW() - INTERVAL '7 days'
GROUP BY user_id
ORDER BY sessions DESC
LIMIT 10;

#Inline HTML

A small inline HTML element: <kbd>Ctrl</kbd> + <kbd>S</kbd> to save. <mark>Highlighted text</mark> via the mark element.

#Hard line break

Line one of a stanza Line two of the same stanza (the trailing two spaces above force a hard break) Line three.

#Emoji and miscellany

Status indicators in plain text: ✅ done, ⚠️ in progress, ❌ blocked, 🚧 work in progress.

Strikethrough: old approach abandoned. Bold-italic: critical.

Horizontal rule above and below this paragraph.


<!-- This is an HTML comment. It should be invisible in the rendered output. Markflame uses comments like this for embedded annotations. -->

End of sample document.

comments (0)

reviews (0)