Human Design
for Black Women

Human Design tools already existed. Every one of them was built for a general audience, priced as a one-time report, and written in a register that lost people in the first thirty seconds.

The audience I was building for — Black women using Human Design as a framework for self-discovery, business, relationships, motherhood, and healing — was not underserved by a lack of calculators. They were underserved by a lack of interpretation, and by a market that treated the chart as the product.

This is the part that gets undersold when a build like this is described as "a site." It is a working ecosystem with four businesses inside it — editorial, e-commerce, membership, and an AI reading engine — sharing one identity, one entitlement model, and one admin surface.

The free layer is real, not a teaser. A full bodygraph calculator, an entire foundations library, six downloadable guides, and an editorial archive across articles, podcast, business, and life. People can get value and leave. Most of them come back.

• Free entry — chart calculator, foundations library, resource hub, editorial
• Chart Hub — three progressive paid tiers on one scroll
• Reports — 13 AI-generated products from quick reads to bundles
• Guided Rooms — 10 modality experiences behind a subscription
• Membership — two tiers, a stackable daily add-on, mentorship, academy
• Apothecary — a nine-shelf catalog where every product lives
• The Journal — a digital workbook with a gated AI reflection layer

Chart Hub is the flagship. Rather than three separate products with three separate checkouts, it is one continuous scroll that deepens as you pay — you can see the shape of what you do not have yet, in context, right where it would sit.

Underneath, two external APIs are normalized behind a single provider layer, cached server-side with different lifetimes for different kinds of data — six hours for static reference, thirty minutes for transits, a day for images. A secret picks the active source, and a diff helper validates one provider against the other.

Thirteen AI report products could have been thirteen prompt files and a prayer. Instead there is one engine with one entry point. A product declares which data endpoints it needs; the engine fans out, caches the raw payloads, and hands them to an interpretation layer.

That layer hashes the product and the input summary, checks the cache, and only calls a model if nothing is there. Repeat reads never re-hit the model. For time-sensitive products the hash carries a daily bucket, so a daily reading is generated once per day rather than once per visitor.

• Schema-constrained output — every product has a Zod schema the model must satisfy
• Model tiered to task — the fast model for quick reads, the deep model for long-form
• One generator per product — the prompt lives next to the schema, not in a shared blob
• One renderer per product — structured JSON becomes a branded page, never raw text

Fifty-five migrations, row-level security on every public table, and explicit grants after every table creation — because the data API does not hand those out by default and a missing grant is a silent outage.

The invariant I care most about: roles never live on the profile record. They live in their own table behind a security-definer function, and every privilege check routes through it. The service-role client is imported dynamically inside handlers that have already confirmed the caller is an admin — it is never used to establish that fact.

• Chart entitlements — per chart, per product, with expiry
• Lesson entitlements — cascading across course, module, and lesson
• Membership status — tier checks as composable functions
• Member credits — monthly report redemption, consumed atomically

Ten modality experiences, each one built to feel native to its own tradition rather than like a tab in a dashboard. Tarot shuffles. I Ching casts coins. The Moon room reads void-of-course. Every room carries a "where this meets Human Design" callout so the ecosystem stays coherent instead of turning into a bundle of unrelated widgets.

Over a hundred pages of copy, and no CMS worth the integration cost. So I built one into the site.

An admin toggles edit mode and every heading, paragraph, list item, quote, link, and button on the page becomes clickable. Changes autosave as a draft, scoped to that page. Publish flips draft to live. Visitors only ever see live.

The design decision that made it useful: it is opt-out, not opt-in. A global component auto-wraps every text node rather than requiring someone to mark up each one by hand. Images and section backgrounds get the same treatment — swap the media, set a gradient, add an overlay, all inline.

This is the piece that makes the rest of it survivable. A private MCP server exposing around fifty-five tools, bearer-authenticated and CORS-locked, that lets me run the entire business from a chat window.

• Daily pulse — today's business, pending actions, revenue summary, digest
• Intelligence — member journeys, churn signals, content performance, cohort analysis
• Members — lookup, subscriptions, tier changes, entitlement grants
• Fulfillment — snapshot requests, reports, support messages, applications
• Audience — contacts, segments, broadcasts, campaign stats
• Content — article drafts, with publishing behind an explicit confirmation
• System health — payment sync checks, email delivery, failed-send retry

Spiritual software has a default look — purple gradients, star fields, gold foil — and it reads cheap to the exact audience I was building for. I went the opposite direction: cream and ivory grounds, plum text, a single gold accent, editorial serifs for display.

Motion is used where arrival matters. Hero reveals, the tarot shuffle, the coin cast, staged reveals as a reading assembles. A component layer of primitives is wrapped in composites specific to this product, so a new product page is composed rather than designed.

One motif ties the whole thing together: a single animated marquee under the hero that carries every modality across the screen. One visual thread instead of ten disconnected room cards.

The calls that are not obvious from the outside, and that I would make again:

• Two kinds of server code, two locations. Internal reads and writes go through typed RPC scoped to the caller's permissions. Webhooks, cron, and MCP live in file routes. Different guarantees deserve different homes.
• Never run a protected function in a public loader. Server rendering has no session. Protected loaders live behind the auth gate; public routes fetch them client-side.
• Cache before you generate. No model call happens without a cache lookup first.
• The city string is load-bearing. The chart API silently ignores coordinates and timezone and only reads the city name — so front-end validation forces a dropdown pick. A quiet failure in someone else's API becomes a hard requirement in mine.
• The email queue self-idles. The scheduled job unschedules itself when both queues are empty and re-arms on the next enqueue. No worker sits burning money waiting for nothing.
• Roles never leave their table. Every privilege check routes through one function. The admin client acts, it never authorizes.