The Modern Shrine: running a production AI product as a one-person company

The Modern Shrine is a consumer AI product with a production web app and paying customers, run as a one-person company. 365 people outside the company have taken its assessment, and its live workshops have run in four countries. With one person running everything, nothing stands between a wrong report, a broken sign-up or a failed AI provider and the customer, so the checks have to be built into the system.

The business: The Modern Shrine

The Modern Shrine turns human pattern intelligence, a traditional Chinese framework for reading personality and timing, into practical reports on career direction, money habits and relationships. People start with a free assessment, receive a written report, and can go on to paid reports, a guided decision workbook and a chat companion. It is Tony's own company, not a client deployment, and it is the test bed for the practices Flareworks recommends to clients. It is live at themodernshrine.com.

Distribution ran through live workshops. Most were hosted by Network School, the coliving and coworking community founded by Balaji Srinivasan, which approved each event and supplied the venue and the people. Other sessions ran in Singapore and Da Nang, and the first workshop in Japan was held at Zō Village, a 30-day live-in program in a mountain lodge in Japan's Alps run by 369meteor.

The constraint: one operator, paying customers, nobody to catch mistakes

Three pressures set the design.

• Long AI reports fail quietly. A single model writing a long personal report sounds confident and still gets details wrong. A customer reading their own report notices an invented detail immediately, and there is no reviewer between the model and the customer.
• AI providers fail. Slow responses and outages from a model provider become failed reports unless something routes around them.
• Workshops run back to back. A bug found in the evening has to be fixed before the next morning's room arrives, by the same person who ran the session.

Early workshops added a fourth problem: attendees were sent to a custom ChatGPT, where they copied prompts by hand on their phones. It worked, but the experience was fragmented and every customer relationship lived on someone else's platform.

The model: a mirror, not a crystal ball

Where the method came from

The method started as a data problem. About ten years ago, Tony took the same birth chart to three established practitioners in Singapore, Germany and Malaysia. Their readings overlapped by roughly 70% and differed on the rest, and on one major life question two of them gave opposite answers. Credible experts, the same input, conflicting outputs: for a data-minded engineer, that was a reason to study the system directly rather than pick a side.

Independent research has since found the same disagreement at scale. In a 2024 Clearer Thinking study, 152 astrologers tried to match 12 people to their charts. They scored at chance (2.4 out of 12) and barely agreed with one another. Some practitioners now argue from inside the field for the same discipline: Vedic astrologer Deepanshu Giri reports testing traditional longevity rules against 125,000 charts, finding they held in under 8% of cases, and dropping rules that fail. Builders at scale have reached the same conclusion. Vitaliy Urban, founder of Moonly, an AI astrology companion with more than 10 million downloads, argues that most astrology apps stop at description, and that "astrology is just the interface. The real product is self-knowledge that turns into a practice you keep, a decision you were stuck on".

Three conclusions followed, and each became a design rule:

1. Treat the framework as a pattern model, not a predictor. There are about 12.96 million possible charts (60⁴), far more than any fixed rulebook covers, and Tony's working notes describe the framework as "a weather-like phase model of life patterns, not a linear equation solver". The product interprets tendencies a person can test against their own decisions, and makes no predictions about events. In the workshops this became "a mirror, not a crystal ball". The classical precedent is Liao Fan's Four Lessons, the argument that a person can change the course a reading describes.
2. Write the knowledge down. Experts disagree partly because their rules live in their heads. The product's analysis runs on a curated, written knowledge base, so every claim in a report can be traced to a source, and a disagreement becomes something visible and fixable.
3. Keep every reading revisable. The design notes call for a confidence level on each interpretation and for changing it when the evidence disagrees, instead of issuing fixed verdicts.

How the method became the system

The "mirror" framing became the main engineering requirement, because it rules out the most common way an AI report fails. A report that invents a claim, a date or a trait has stopped being a mirror. So the pipeline is built to catch invention, and every other choice follows from that.

One narrow job per stage. Each report goes through three separate stages, and no stage is asked to do two things at once:

1. Analyst

   Works out what the chart and the person's own answers actually say, grounded in a curated knowledge base retrieved with hybrid search (keyword plus vector, PostgreSQL with pgvector).

2. Editor

   Rewrites the analysis into clear, warm, specific language, without adding claims the analyst didn't make.

3. Vetter

   Checks the final report against the analysis and a structure checklist, and sends it back if anything is invented, missing or malformed.

The writer never grades its own work. The vetter is a separate stage with a separate prompt and a narrower question: does every claim in this report trace back to the analysis? A model checking its own output tends to agree with itself. An independent check with a narrow question does not. The same principle is written up in Chatbots that check their answers.

Grounding beats a better prompt. The analyst works from retrieved passages in a curated knowledge base, not from what a general model happens to remember about the subject. When a report goes wrong, the trace shows whether retrieval returned the wrong passage or the model ignored the right one, which are different fixes.

Bad input is fixed before generation. Thin or vague answers produce thin reports however good the pipeline is, so the assessment now coaches people to give fuller answers before they submit.

A provider failure is an expected event. Requests fall back automatically across several model providers, so a slow or failing provider costs latency, not a report.

Every failure has to be visible. Each run is traced stage by stage, with retrieval results, validation outcomes, latency and cost per report on an internal admin page. A problem shows up on a dashboard before it shows up in a customer complaint, and the trace says which stage to fix.

The structure: how it runs day to day

An owned app instead of a borrowed one. In July 2026, workshop attendees moved from the custom ChatGPT onto The Modern Shrine's own app: account, profile, guided flow and chat in one place. On the first day, some new sign-ups were sent to the wrong page after registering. The cause was two bugs working together: the "where to go next" instruction was dropped during sign-up, and a race condition meant the profile sometimes hadn't saved when the next page checked for it. With workshops running back to back, it was fixed and deployed overnight, before the next morning's session.

Tests and traces carry the load a team would. The pipeline is covered by 357 automated tests, and 2,114 model-stage attempts have been traced end to end. The workshops fed the backlog directly: after the first Japan session, Japanese users could not reliably get answers in Japanese, so a persisted language setting became a priority fix.

Agents handle the repetitive work. A supervised team of six AI agents handles research, first drafts, social replies and reporting, with independent quality checks before anything is published and human escalation when an agent is unsure. Anything published under Tony's name is approved by him first. That system has its own case study: an AI team that earns attention one reply at a time.

Paid acquisition runs through code. Google Ads runs through its API: nine search campaigns across four products, with search terms analysed and broken conversion tracking found that the web interface was hiding. The write-up: Google Ads has a terrible interface, so I stopped using it.

Time is capped. Once the product was producing signal, it was capped at about 20% of working time, with two experiments run separately rather than merged so each result would mean something.

The result

• 341 finished reports from 365 external assessments, a 93.4% generation rate, across production traces.
• 2,114 model-stage attempts traced and 357 automated tests maintained by one person.
• 13 live workshops in five months across Malaysia, Singapore, Vietnam and Japan, with more than 100 participants, most of them hosted at Network School.
• Before the owned app, the custom GPT the workshops used was rated 4.5–4.6 out of 5 across 20+ reviews, with more than 1,000 conversations.
• The sign-up failure on the owned app's first day was fixed overnight, before the next morning's workshop.

What clients and workshop participants said, from the testimonials page: