Three websites that had just changed hands
The American Institute for Economic Research, AIER, has been publishing economic research since 1933. Today that work reaches readers through three websites: the institute's main site, a daily publication called The Daily Economy, and a magazine called Fusion. Between them, they hold many thousands of articles, papers, books, and podcasts.
When we began working with AIER, the three sites had recently been separated from one shared system, and the people who had done that work were no longer involved. The institute's technology director was responsible for three large websites that nobody on hand had built.
For a research institute, the website is the publication. When it is down, the work is not being read. With an inherited site, there is an added problem: when something goes wrong, there is no one to ask why.
The site kept going down, and it took the others with it
In February 2026, the main site began failing. It happened three times in one week. Each time, all three sites went down together, because they shared a server. A restart brought them back, and then it happened again.
An outage like that lands on one person. The technology director hears about it from every direction at once, and with an inherited site has no history to check it against. There is nothing to tell colleagues except that it is being looked at.
The usual answer is a bigger server. It costs more every month, it often helps for a while, and it explains nothing. With an inherited site, that matters, because a problem nobody understands is a problem that comes back.
We read the logs before anyone bought a bigger server
We looked for the cause first. The server's own records showed something odd: most of the load was coming from the server itself. The main site's news feed, the address that news readers and apps check every few minutes, was built to ask The Daily Economy for its latest articles each time anyone requested it. Both sites lived on the same machine. So every request became two, the second heavier than the first, and on a busy day the sites were wearing each other out.
Nobody had looked there because nothing about it was broken. The feed did exactly what it was written to do.
We taught the feed to remember. It now keeps a recent copy and hands that out, so a request from a news reader costs almost nothing. The calls between the two sites stopped the moment the change went live.
We gave the main site a server of its own. When heavy load came back from a different direction a few weeks later, we moved the main site away from the other two, and it now has a machine to itself. A hard day on the main site now stays there, and the other two keep publishing.
We made one home for each scholar. AIER's researchers write for both the main site and The Daily Economy, and their bios used to be kept separately in each place. We connected the two sites so that a scholar's profile is edited once, on the main site, and appears on both, along with their articles from both publications. An editor updates a bio one time.
We caught up on maintenance carefully. The main site had a long list of pending software updates. We sorted them by whether they could change what a visitor sees, ran the safe ones first, and compared pages before and after for the rest, so nothing a reader sees changed by surprise.
What a bad day looks like now
A site with this much content draws a great deal of automated traffic, and that has not stopped. What has changed is what happens next. Load on the main site stays on the main site. When it climbs, we know where to look first, because each earlier cause was found and written down, not restarted away. The feed that started it all is now handed out as a ready-made file, refreshed every few minutes, and costs the server almost nothing.
For the technology director, the difference is having an answer. When something goes wrong, there is a cause and a fix, and both are on record. The institute's editors keep one profile per scholar. The three sites are looked after by people who now know how they are put together.
We did not build these sites. Most organizations inherit their website at some point, from a vendor or from a colleague who has moved on. The work is to find out why it behaves the way it does, and to leave it better understood than we found it.
What changed
- The cause of the repeated crashes was found in the server's own logs and fixed
- The main site runs on its own server, so trouble there stays there
- A scholar's bio and photo are edited once and appear on both publications
- A long backlog of updates was worked down in stages, with pages compared before and after
Under the hood
For the developer evaluating us
- 10,800+articles on The Daily Economy
- 290features on Fusion
- 10content types on the main site
- 43plugins on the main site
- 2plugins in the scholar system
- 5 minfeed refresh cycle
What We Built
- Three inherited websites taken on and looked after by one team
- The cause of repeated outages found and fixed, with the main site moved to its own server
- A scholar system that keeps one profile per researcher across two publications
- A staged, checked approach to a long update backlog
- Ongoing hosting, maintenance, and development for all three sites
What the logs showed
The main site replaces the standard WordPress feed with a custom handler that builds a combined feed from both publications. On each request it called The Daily Economy's REST API for recent posts, with no caching, and both sites ran on one server. Feed readers poll constantly, so the server spent its day answering itself. A second function, a shortcode that lists recent posts from both sites, made the same kind of uncached call on every page view.
The first fix added transient caching and short timeouts to both functions. When the object cache later evicted those entries under memory pressure, we added a file-based copy that survives eviction, with atomic writes and a stale fallback so a slow upstream never blocks a reader. Today the feed is served as a static file that a scheduled job regenerates every five minutes, validates, and swaps in only when it has changed.
Separating the sites
The main site is the heaviest of the three: ten content types, an events calendar, and the largest plugin stack. It now runs alone on its own server, and the other two sites share a different one. Calls between them cross the network instead of competing for the same memory, and a saturated pool on one machine cannot starve the others.
The scholar system
Two small plugins, one on each site. The main site is the single source for scholar data and exposes it through a REST endpoint. The Daily Economy reads from it, caches the result for fifteen minutes, and falls back to its own stored bio if the main site cannot be reached. Scholars are matched between the two sites by a mapping field on the main site's people taxonomy, and both author archive pages and the bio block on individual articles read from the same source.
Working down an update backlog
Each pending plugin was checked for front-end surface: scripts it loads, shortcodes and blocks it registers, and filters on rendered content or on which posts a query returns. Plugins with none were updated first. The rest were updated in small groups with full-page comparisons before and after. WordPress core was moved to the latest release on its current branch, with the next major version held for its own pass.
Hosting
Managed cloud servers on the East Coast, Cloudflare Enterprise in front, Varnish and Object Cache Pro with Redis behind it, scheduled backups, and uptime monitoring on all three sites.
Figures current as of September 26, 2026
