SYS.01 Objective
The brief was to reposition economist Dr Rebecca Harding as a public intellectual and rebuild rebeccanomics.com around that: a homepage, a research hub organised into six themes, a re-skinned article template, and a body of existing writing, held as PDFs and legacy posts, resurfaced as proper readable web pages.
Then a hard constraint reshaped everything. Direct writing into the WordPress admin through a browser was blocked, so hand-building pages in the page builder at any scale was simply not available. The obvious route was closed.
It turned out to be the best thing about the job. It forced the build into a model strictly better than the one it replaced.
SYS.02 Creative response
Repositioning, full site build, the publishing system on top of it, and ongoing paper production, a live engagement, still running.
The architecture
- The site is generated, not assembled. A small set of WordPress plugins construct and skin it on the server, each triggered by a token-protected endpoint, then verified by driving the live site in a browser and reading the result back
- Deterministic and idempotent. It rebuilds from scratch, every change is a code change, and the design is version-controlled and diff-able in a way a page-builder site never is
- Render-takeover for articles. Posts keep clean original HTML in the database and the skin is applied at display time, so the source is never corrupted and the content stays portable
- Publishing without a developer. Category-driven theme listings plus the post template mean the client writes an ordinary WordPress post and it appears fully styled on the right theme page. The deliverable was independence, not a dependency
Thirty papers, each with a designed PDF
The second phase was a publishing programme: roughly thirty theme papers, every one given a designed download rather than a browser print of the web page.
The PDFs are generated, a navy and gold template, a cover, the byline, the full body and every footnote, and wired to their article automatically by matching the slug. Add a paper, and its download appears. A check across all twenty-nine live papers found seven with no working link; those were rebuilt until it was twenty-nine of twenty-nine.
The same slug-matching runs the link previews, and that came from a real complaint. Sharing any paper produced the author's headshot, every time: “every link comes with a picture of me which is a bit spooky.”
So thirty unique share cards were generated, one per paper: house-style navy and gold line-art, seeded from the slug so each is different, carrying the paper's own title, and the social metadata was overridden to serve the card whose filename matches the post. Then all thirty were checked in a browser. Thirty cards, no headshots.
A working paper through peer review
One paper, a defence-finance study co-authored with a research affiliate at MIT Sloan, came back with rounds of corrections that the PDF generator could not satisfy. Endnotes needed to be real footnotes at the foot of the page they refer to. Tables were splitting across pages. References and appendix needed to start fresh.
Those are typesetting requirements, not layout preferences, so the build was moved to LaTeX, where page-bottom footnotes are native. Tables were made unbreakable, the cover title broken across three lines so the country name never hyphenates, author affiliations numbered as superscripts, footnotes prevented from splitting across pages, and a figure caption restored where the image and its caption had been sharing a paragraph.
Five rounds, each verified page by page before it went back. The point is not the LaTeX. It is that a co-author at a research institution applied academic publishing standards to it and the document met them.
And a tool, served from its own plugin
The assessment prototype for the sustainability return-on-investment work needed to be shareable before it was finished. Rather than paste it into a page, it got a small plugin of its own that serves the self-contained file at a clean, unlisted, no-index URL.
It is a five-minute answer to a question that usually costs a fortnight: how do I put this in front of one person without publishing it. The tool itself is documented separately at <a href=”sroi-s3rti.html”>ITFA S3RTI.
SYS.03 The architecture
- The site is generated, not assembled. A small set of WordPress plugins construct and skin it on the server, each triggered by a token-protected endpoint, then verified by driving the live site in a browser and reading the result back
- Deterministic and idempotent. It rebuilds from scratch, every change is a code change, and the design is version-controlled and diff-able in a way a page-builder site never is
- Render-takeover for articles, the strongest decision on the project. Posts keep clean original HTML in the database and the skin is applied at display time, so the source is never corrupted and the content stays portable
- Publishing without a developer. Category-driven theme listings plus the post template mean the client writes an ordinary WordPress post and it appears fully styled on the right theme page. The deliverable was independence, not a dependency
SYS.04 Thirty papers, each with a designed PDF
SYS.05 A working paper through peer review
SYS.06 And a tool, served from its own plugin
SYS.07 Results
29/29, papers with a verified download link
Live, client-operable and reproducible from code. Twenty-nine of twenty-nine papers carry a working designed download, thirty carry their own share card, and the client publishes without a developer.
The same relationship runs through the wargame at <a href=”primacy.html”>Primacy and the research at <a href=”itfa.html”>ITFA.
SYS.08 The work
Let the constraint pick the architecture
Being locked out of the admin interface produced a better site than being let in would have.
If this looks close to something you are dealing with, the quickest route is to say so in a sentence. You will get a real reply from a person, usually with a first read on the problem rather than a calendar link.