Armstrong Educational Services, turning a 30-year teaching career into a productized consulting brand.

Camille Hampton is a Georgia DECAL-Approved Trainer and early-childhood consultant with 30+ years in the field — an M.A. in Educational Psychology from the University of Colorado at Denver, a formation at the Reggio Emilia-inspired Boulder Journey School, and a conference record that includes the Jean Piaget Society Symposium and GAEYC. She specializes in professional development, coaching, and DECAL-approved CEU training for teachers of children ages 2–6, working with private preschools and Reggio-inspired schools across metro Atlanta and, increasingly, online.

None of that expertise had a product wrapped around it. Armstrong Educational Services existed as a business name with no visual identity, no pricing system a director could self-serve, and no digital presence beyond referrals and a LinkedIn profile. Every booking ran through a manual conversation, every price was negotiated from instinct, and there was no way for a director in South Carolina or North Carolina — states with their own training-hour requirements — to even find her.

I was the only designer on this engagement, and the one directing the build. I authored every source document an agent team could execute against: a client profile consolidating Camille's biography and methodologies, a pricing & business-strategy plan, a home-page structure and CRO audit, an SEO/GEO master plan, and the design-system specification itself. I owned the brand identity, the token architecture, the conversion-rate strategy, and the SEO foundation end-to-end.

The agent team executed the Next.js build, ported the component library, and ran the pre-launch audits — inside non-negotiable rules I wrote (below), with every file-ownership boundary and every content source traced back to a doc I authored. Judgment calls — which visual direction to ship, how aggressive the pricing decay should read, what to say about Camille's own past speaking feedback — stayed with me.

The identity had to read as credentialed and warm at once — a business built on 30 years of trust, not a franchise course-mill. The mark pairs an "AE" monogram with a full "Armstrong Educational Services" lockup in a forest-green/sage duotone; the supporting palette runs a warm cream/sand neutral scale against a single accent orange, kept for CTAs and highlights only. Voice guidelines set one explicit rule across every surface: sentence-style capitalization, never Title Case headlines — a small thing that keeps 20 pages of copy from reading like a stock template.

The token architecture is two layers. Primitives are raw, theme-agnostic values — 52 colors across five perceptual 50→900 scales, 14 spacing steps, 7 radii. Semantic tokens are usage roles aliased to those primitives, with separate Light and Dark maps — primary, surface-cream, on-accent-soft, ring. The golden rule I wrote into the spec: components never bind to a primitive directly, only to a semantic token — so re-theming is a one-line alias change, not a find-and-replace.

The token architecture above didn't get typed into a CSS file by hand, and it wasn't generated blind by an agent either. It moved back and forth between Figma and Claude Code at every stage: the parts that need a human eye stayed a craft; the parts that are pure repetition became a pipeline.

The documentation library lives as its own Next.js app (apps/design-system) — an internal site, not public-facing — with six sections and a Cmd-K command palette to jump between any of them:

The component library itself — @armstrong/ui and @armstrong/tokens — lives as versioned workspace packages in the same GitHub monorepo, not copy-pasted between projects. That's the actual point of building it this way: any future agent team, or any human developer, building the next Armstrong surface imports from these packages instead of re-deriving a color, a spacing value, or a button's hover state from scratch. Style unity and scalability aren't a style guide PDF someone forgets to open — they're the only path of least resistance.

Camille isn't just the brand on the homepage — she's the sole daily user of the admin panel behind it. She's in her 50s, not from a technical background, and learned the web through referrals and word of mouth, not through a career of SaaS dashboards. The admin panel had to optimize for her confidence and low cognitive load over feature density, even though the system underneath has eleven distinct admin areas.

Navigation, ordered by how often she actually needs it: Dashboard, Quotes, Contacts, Bookings and Calendar & availability sit at the top of the nav — the four things she checks daily. Trainings catalog, Programs, Pricing, Articles, Admins and Settings sit lower, intentionally lower-frequency, so the first screen she sees never overwhelms her with all eleven areas at once.

Stack: Next.js App Router under /admin, gated by Supabase auth plus a role check (only accounts flagged admin can reach it); Supabase Postgres with row-level security ("owner sees all"); the Google Calendar API syncs her real calendar, so the availability she sees in the app is her actual calendar, not a second one she'd have to keep updating by hand.

Every quote passes through an email system that has to satisfy two people who never share a screen: the client filling out the quiz, and Camille checking her inbox from her phone. Both get an HTML email built by one shared renderEmail() function — table-based layout, inline styles, a 600px max width, and a web-safe font stack, because custom fonts and modern CSS don't survive most email clients. Every email also ships a plain-text fallback for inboxes that block HTML entirely. Only the content changes per email; the branded shell (logo, green accent bar, mint recap card, forest footer) is identical everywhere, so nothing about the emails looks improvised.

Before writing new copy, I audited the built homepage against three explicit conversion goals: (1) a director requests a custom quote in about 60 seconds via the calculator, (2) an individual educator self-enrolls in an online CEU course with no contact form, (3) teachers and schools form their own groups to unlock lower per-head pricing. The audit surfaced both layout bugs and missing trust structure.

The brief behind this flow was a real tension: raise conversion without burying the visitor in a configuration screen that has 9 real variables (state, program, delivery, hours, team size, add-ons, trainings, scheduling, confirmation). Splitting that into one guided question at a time isn't just friendlier — it measurably keeps people moving, and it makes people feel like the quote at the end was built for them, not pulled from a price list. That isn't a hunch; it's a small set of well-documented behavioral-UX findings. (Drawn from established UX/behavioral-research literature in my working knowledge — I didn't have live web access in this session to pull fresh sources, so treat these as the well-known, textbook version of each effect.)

Mapped end to end below — including the one branch that matters most for conversion: whether the visitor is already logged in when they reach the confirmation step.

Camille's asking price of $35 per teacher per in-person hour sits exactly in the market's comfort zone for mid-tier facilitators in metro Atlanta. Her instinct that a school won't pay 3× that rate for a 3-hour session is also correct — market benchmarks across comparable providers converge on roughly a 2.3× multiplier for 3 hours, not 3×. The decay curve below isn't a discount Camille is forced to give: it's the fairness curve buyers already expect, and pricing to it signals professionalism rather than negotiation.

The public site and its internal design-system app were shipped by an agent team executing a build workflow I wrote, not by hand-coding every route. The workflow encodes phases, ownership, and non-negotiable rules so a large fan-out of work stays coherent and doesn't collide.

Non-negotiable rules written into every agent's brief: Next.js App Router, React 19, TypeScript strict — no any; Tailwind v4 mapped 1:1 to the semantic tokens, never a hardcoded hex; copy sourced verbatim from named sections of the docs I wrote — no invented facts about Camille, her credentials, or her pricing; image placeholders only until real assets land, each with descriptive alt text; WCAG 2.2 AA as a hard bar; and strict per-agent file ownership (nobody but the Foundation agent touches the root layout, nav, footer, or token files) so parallel work can't silently collide.

I ran the Verify phase as an adversarial pass, not a rubber stamp — re-checking the agent team's own work line by line rather than trusting its self-report.

The judgment call that stayed human: agents are excellent at exhaustive, structural verification — replay every pricing formula, grep every hex, check every route's title length. They're weak at the perceptual call between two visual directions, or at deciding whether a critique from a past speaking engagement should become public copy. That decision-making stayed with me.

Every page's JSON-LD resolves back to two stable entities — a ProfessionalService and a Person node for Camille — so schema never dangles across 24 indexable URLs. robots.txt and a published llms.txt explicitly allow-list GPTBot, ClaudeBot, PerplexityBot and ChatGPT-User alongside Googlebot and Bingbot: a deliberate GEO (generative-engine optimization) bet that directors increasingly ask an AI assistant, not just Google, before they ask Camille.

The content architecture centers on a certification hub with three state-specific subpages, each using the correct local terminology and hour requirements — Georgia's DECAL/BFTS (10 hrs/yr), South Carolina's SC Endeavors/ABC Quality (15 hrs/yr), and North Carolina's DCDEE (5–20 hrs/yr by credential) — plus a blog cluster timed to each state's annual renewal season.

GA4 and Microsoft Clarity are already wired at the layout level — GA4 behind an environment variable so it only fires post-launch, Clarity for session recordings on the calculator and FAQ. The site isn't live traffic yet, so the roadmap below is deliberately a plan, not a results claim.