Got a project?

Get in touch
All work

SignalTrace (signaltrace.wiki)

Fourteen research wikis out of one repository.

A multi-wiki research site where every claim links back to the primary document, built by running one static-site generator fourteen times from a single repo.

Client
SignalTrace (signaltrace.wiki)
Year
2026
Role
Sole developer — architecture, build orchestration, design, editorial
14
Independent research wikis
43
Lines in the orchestrator that does it
1
Array entry to add the next one

Context

SignalTrace publishes long-form research on subjects where the useful output is a better-formed question rather than a tidy answer — a takeover structure, an oil chokepoint, a state-capture network, a clinical evidence base. Each investigation is an entity graph: people, organisations, events, concepts, linked with wikilinks so the graph does real navigational work instead of decorating the sidebar.

The rule that makes it worth reading is that every claim links to the primary document. The filing, the registry entry, the court record. A reader should not have to trust the author.

The problem

Quartz builds one site from one content/ directory. SignalTrace needed fourteen, each with its own taxonomy, its own graph, and its own URL subpath, all published from one repository under one brand.

The obvious routes are both bad. Fourteen repositories means fourteen copies of the theme, the config and the layout, and a palette change becomes fourteen commits. One giant vault means one graph in which a South African corruption network and an Alfa Romeo racing history are neighbours, which destroys the thing that makes the graph useful.

What I did

I kept upstream Quartz as a fork and running as-is — all 14,165 lines of it — and put the entire custom delta into a 43-line orchestrator. scripts/build-all.mjs iterates an array of case slugs, invokes npx quartz build once per case with a subpath QUARTZ_BASE_URL, and copies a hand-authored landing page into public/.

Adding a wiki is one entry in that array and one card on the landing page. That is the whole extension point, and it is deliberately the only one.

The rest of the customisation stayed surgical on purpose: a 23-line title component for the logo, 128 lines of SCSS for a locked palette and typography, a 98-line Quartz config. Everything I did not override stays on upstream, which means upstream updates remain a merge rather than an archaeology project.

The editorial structure is the part that actually took the time. Each vault repeats the same entity-folder taxonomy and the same open-questions convention, so a reader who has navigated one wiki already knows how to navigate the next, and a researcher picking up a vault six months later knows where an unresolved thread was left.

The result

Fourteen research wikis — the RMH Holdings takeover, the Strait of Hormuz crisis, PayPal’s checkout decline, SA state capture, and ten more — published from one repo, one theme, one deploy.

The pattern has since been reused for other sites, which is the real test of it: the cost of the fifteenth wiki is a line in an array, and the cost of a brand change is one SCSS file.

Got something like this that needs building?

A few lines about what you’re trying to build or fix is enough. It lands in my inbox and I reply within the business hour — honestly, including whether I’m the right person. If I’m not, I’ll say so and point you at someone who is.

I reply to every enquiry within one business hour.

Prefer email? support@yourdesign.co.za· (+27) 079 177 1970

Next case study — SA Wills Database — estate-readiness platform →