Starchart — a practitioner-facing tool for professional astrology.

The core challenge was not "how do we make astrology software." It was: how do we design a writing environment where the data, the maps, the reference library, and the practitioner's own voice all coexist in a single space?

Starchart has an unusual actor structure for an internal tool: the practitioner is the primary user, but the client is the downstream recipient of the service artifact — the report. The practitioner's experience is almost entirely backstage. The client never sees the tool; they receive the output.

This two-sided dynamic shaped every design decision. The interface had to serve deep professional work; the output had to communicate clearly to someone with no astrological training.

The product produces two report types today: Natal reports, which interpret a person's birth chart, and Relocation reports, which use astrocartography to map where different planetary energies manifest geographically. Synastry and event reports are on the roadmap.

The tool is in active daily use with real clients. A closed beta with additional practitioners is underway by invitation.

A full astrocartography map shows every planetary line for every planet simultaneously, across the entire globe. It's comprehensive and overwhelming. Starchart's map works differently.

Each map block in a report is a single focused snapshot — one line, one region — configured by the practitioner before the report is written, and captioned in their voice. The map style is a dark Mapbox theme: deep charcoal land, muted borders, subdued city labels. Not for atmosphere — to suppress visual noise. The planetary line is the focus.

A single dashed colored line runs through the frame. A labeled chip identifies it directly on the map. Below, a caption in the practitioner's words frames what the reader is looking at. The client doesn't need to navigate, compare, or interpret a legend. They read the paragraph, see the place, see the line, read what it means.

A link beneath each map opens a full interactive version for clients who want to zoom, pan, or explore neighboring lines. Static by default keeps the report fast and readable; interactive on demand respects the client's curiosity without imposing it.

The chart wheel visualizes planetary positions across the twelve zodiac signs and twelve houses at the moment of birth. In the writing context, it functions as an embedded artifact: clean, black-and-white, labeled with the client's name. It orients the reader to the practitioner's source material without becoming the subject of the document. The chart is context; the prose is content.

The most important visualization principle in Starchart is what it doesn't do. The report the client receives is not a chart dump or a data table. It is written interpretation. Data visualizations serve the writing; the writing doesn't serve the data.

Zen Editor was designed not just to serve Starchart, but to define a reusable design language for a category of tool that doesn't have one yet: contemplative research and writing environments that work with specialized symbolic systems.

The astrology implementation is the first. The architecture is designed for future ontologies — somatics, depth psychology, ritual design. Documenting future ontologies in advance of building them is itself a design act: it defines the shape of the system before the system exists.

The visual language draws from neobrutalist design: bold accent colors applied with confidence, hard-edged black borders, offset shadows without gradients, and an 8px spacing grid with generous whitespace. The system explicitly rejects the visual tropes common in astrology software — no neon cosmic gradients, no crystal imagery, no mystical clichés. The goal is an interface that feels like a professional research instrument, not a consumer wellness app.

Most internal tools have one actor. Starchart has two. The practitioner uses the tool; the client receives the output. Making this two-sided structure explicit through service design methods created a shared reference for evaluating every design decision.

The core flow: The practitioner begins by adding a client with birth data. The system generates chart positions and populates planetary data. The practitioner opens the report editor — a writing environment with chart data and client context alongside the long-form interpretation document, with an interpretation library available for reference. For relocation reports, the editor surfaces a configured map view as an embedded block. Interpretations are written in freeform prose, with structured data blocks — map snapshots, chart wheels, planetary reference chips — woven into the document as the practitioner writes.

The service design work on Starchart began as a structured way to surface and articulate decisions that had already been made intuitively — and to identify where the practitioner experience and client experience diverged in ways that had design implications.

The service blueprint maps the client journey (minimal: intake, wait, receive, read), the practitioner's frontstage actions (intake, scoping, delivery), the backstage production work (chart generation, map configuration, interpretation writing, report assembly), and the supporting systems. The most revealing finding was the asymmetry: the client's journey is short and simple; the practitioner's backstage is where all the complexity lives.

Starchart's entire value proposition is backstage optimization — reducing friction in the production process so the practitioner can spend more time on interpretation and voice, which is what clients are actually paying for.