Mirembe Muse
The studio that sells the work
The other half of the split this whole wing is built around. Every outcome, case study and price lives there; every process, failure and half-finished idea lives here.
- 327 commits
- 2026-06-18 → 2026-08-11
- TypeScript 97.2%
- private repository
One person, several products, and two audiences who want incompatible things. A client evaluating a build wants outcomes, references and a price. A reader of this site wants the making — the wrong turns, the night something broke, the reasoning under a trade-off. Serve both from one site and it becomes a portfolio that is boasting and confessing at the same time, and neither audience believes it.
So there are two buildings and one rule for which is which: if a page starts arguing for her, it belongs on Mirembe Muse. That rule is also why this dossier is short. The interesting thing about Mirembe is what it sells, and this is the wrong site to sell it on.
4 decisions
What the constraint forced.
Each of these is a choice with a reason attached. The reason is the part worth reading — a stack list tells you what was used, and nothing at all about the judgment that put it there.
- 01
Two sites, one rule, no overlap.
Not two audiences on one site behind a filter, and not one site with a business section. Separate domains, separate deployments, separate databases. The cost is real — two of everything to maintain — and it buys the thing that matters: neither site has to hedge. A services page can make a claim without a poem beside it undercutting the register, and a postmortem can admit a month of blind monitoring without a prospective client reading it as a warning.
- 02
The business routes redirect rather than duplicate.
When a page moved to the studio site it became a permanent redirect here, not a copy. Two live copies of the same claim diverge — one gets a price update and the other does not — and the stale one is invariably the one a search engine has already indexed.
- 03
Scope the database client to its own schema.
The admin client is scoped to the studio schema and carries a correspondingly scoped token rather than a general-purpose one. Same instinct as the multi-tenant work in AdminOS: the blast radius of a mistake should be bounded by something structural, not by the care of whoever writes the next query.
- 04
Publish a price only where it can be kept current.
A recurring class of commit in this repository corrects a published price that had drifted from the tier that actually exists — a range gone stale, a tier removed but still listed. A number repeated across a site is a promise repeated across a site, and only one copy ever gets updated.
The part that survives the build.
Two sites is a positioning decision that happens to have a hosting bill.
The temptation with limited time is one site with a "work" tab. It is cheaper and it is worse, because the register cannot change between tabs — the whole site ends up in the tone of whichever audience is more commercially urgent, which is always the client. Splitting is what lets this side be honest.
A redirect is a maintenance decision before it is an SEO one.
The reason to redirect rather than duplicate has very little to do with rankings. It is that one copy cannot go stale relative to another copy if there is only one copy.
Built with
- Next.js
- TypeScript
- Supabase (scoped schema)
- PayFast
- Resend
- Vercel
Measured
- commits
- 327
- last commit
- 2026-08-11
Written from MirembeApp repository — commit history; the split is specified in docs/THE_FORGE.md §0. The dossier is composed from the journal rather than quoted out of it — the raw sections stay behind the review gate described in docs/THE_FORGE.md §4, and every figure above is read from the GitHub API at build time.