Case study · ElMundi UA
Live in production5,000 years of history. 608 commits in 30 days. One operator.
ElMundi UA is a catalog of human civilization — Sumer, Akkad, Egypt, the Indus Valley, and the long quiet centuries between them — at elmundi.com. A seven-person team built it by running every ticket through Ship. This is what that looked like, in the order it happened.
The receipts
Three numbers, then the dashboard they came from.
236k+
Production lines, AI-authored
608
Commits in 30 days
99%
Live system uptime

This dashboard is live. The metrics below are the same dashboard, today.
Movement one
The catalog before Ship.
ElMundi started as a stubborn question: could a small team actually publish a coherent history of the world — civilizations, characters, episodes, dates, the lines between them — without outsourcing the whole thing to a textbook publisher? Five thousand years. Hundreds of cultures. A schema that has to hold up whether a reader lands on Sumerian tax records or a single year in late-stage Rome.
The content was the easy part. The web around the content was not. Each civilization needed its own landing surface, with the same shape but different texture. Each character needed a page that knew which civilization owned it. Each episode needed to know which character it belonged to and which civilization the character belonged to. The graph was small; the page count was not. By hand, this is a content management system you bolt together over a year and then maintain forever.
We are seven people. We do not maintain forever. So the question wasn't can we hire enough writers; it was can we put the schema, the brand voice, and the editorial rules somewhere a machine can read them, and then run a delivery loop tight enough to ship the next page tonight. That is what Ship had to be.

elmundi.com today — the civilization index, served from the same loop this page describes.
Movement two
First ticket through the loop.
The first ticket that walked the full pipeline was small on purpose. A civilization detail page — Akkad, in our memory of it — needed a sibling navigation strip across the top: previous civilization, parent region, next civilization, by chronological order. The planning bundle wrote the spec. The implementation specialist opened the branch. Twelve minutes later there was a pull request, four files changed, with a passing test that compared the rendered HTML to a fixture.
The test was wrong. Not catastrophically wrong — it asserted on an alphabetic sort instead of a chronological one. The validation bundle caught it inside the same pipeline run: the fixture said Akkad came before Sumer, and somebody, somewhere, had once decided Sumer came first because it did. The pipeline paused at the reviewing stage with a clarification request, not a failure, and the operator on duty that morning answered it the way you would answer a junior teammate: yes, sort by start year, not by name; the slug list in civilizations.yml is in the right order — use that as the canon.
The agent re-cut the test, re-opened the PR, and merged. The whole event took less than an hour. We mention it here because this is the shape every ticket has had since: agent acts, specialist catches, human decides, evidence lands in the trail. We were not faster than a senior engineer on day one. We were just auditable in a way a senior engineer rarely has time to be.
Movement three
The day a chart said Elite out loud.
DORA‑4 is the four metrics SRE‑literate buyers actually read: deployment frequency, lead time for changes, change failure rate, mean time to recovery. They are not a vanity dashboard. They are how a senior platform engineer decides whether you are telling the truth.
We did not look at them for the first two weeks. We were too busy watching tickets land. Then on a Tuesday we opened the Analytics tab and the deployment frequency chart was at 7.3 deploys per day, labeled Elite. Lead time — the time from first commit to production — was 5 minutes, also Elite. Change failure rate sat at 13%, which is High not Elite, and we were honestly relieved; a 13% failure rate that we caught and rolled back is a better story than a 0% rate that we manufactured by hiding incidents. Mean time to recovery: an hour and a half. Also High.
Two Elite, two High, on a stack where every commit was authored by an agent. We did not celebrate. We screenshotted the dashboard and put it in the inbox, because that was the moment the cadence became visible — not as a vibe, but as a number a CFO could read. Some of those screenshots ended up on this site. The rest stayed in the workspace, as evidence for the next time someone asks whether the loop actually runs.
Movement four
Memory took over.
For the first couple of weeks the operator on duty re-explained the same things to the same agents in slightly different words. The civilization schema. The brand voice — declarative, sourced, never breathless. The rule that dates before the common era are negative integers, not strings with the letters BCE tacked on. The convention that an episode title sentence-cases everything except proper nouns. Small rules. Real rules. Rules that, if you forget them in one PR, you ship a page that breaks the schema for the next twenty.
Then we wired persistent memory into the workspace. Not a vendor; an operating property of the loop itself — the agents now had a place to write what they had learned, and a place to read what previous agents had decided, and that place persisted across runs. The operator stopped re-typing the brand voice. The next ticket about a civilization page already knew the schema. A planning artifact from three weeks ago turned up, by itself, in a relevant clarification thread.
The shift was not loud. We noticed it in the negative space: fewer clarifications per ticket, fewer reviewer comments that read this is the third time we've said this, fewer PRs that had to be re-opened because someone forgot the convention. Memory is what makes a loop sustainable at the size of a team that does not have a permanent staff meeting. Without it, the loop is fast and forgetful. With it, the loop is fast and getting smarter.
Movement five
Today.
Open the workspace right now and the footer reads merged · #262 · ElMundiUA/ship · 11:40 AM. That is a real pull request, on a real branch, in a real repository, merged this morning by an agent that walked the full eight-state pipeline and waited for the operator to say yes at the only point a human still needs to. Tomorrow it will be #263, or #265, or whatever the loop produces overnight. The number does not matter; the cadence does.
The output of the loop is the catalog itself. The civilizations index, the character pages, the episode timelines — all of it served from the same monorepo this workspace points at. The site is at elmundi.com. Click any civilization. Click any character. The page you land on was written, reviewed, and merged through the loop you just read about.

The ElMundi workspace, this morning. Footer: merged · #262 · ElMundiUA/ship · 11:40 AM.
A note on this case study
We built this. We use it. Here is the receipt.
ElMundi UA is not a customer logo. ElMundi UA is the reference deployment of Ship, run by the same small team that builds Ship. We are too small to pretend to be a vendor watching from outside. Every number on this page came out of the workspace we open in the morning. Every screenshot is a place you can navigate to yourself, if you have a seat. If you do not, the dashboard above is the closest thing we have to a passport stamp.
Next
Read the long version. Or talk to the founder directly.
The book is the same story at chapter length — forty short essays on the operating model, the scars, and the rules we learned to write down. The mailbox is exactly what it sounds like: a person, at a desk, reading.
