From scattered Slack pings to one Inbox: how ElMundi runs Ship on itself

ElMundi's engineering team had been using AI coding agents for months before adopting Ship. Capability was never the question. The question was governance: a roomful of people pasting prompts into chats produces working code and a tail of unanswered questions — which agent wrote this, against which spec, under which approval, and what proves it works in the browser? The pain was felt most by the people who do not write code: founders preparing for due diligence, the ops lead who has to explain a production incident, the new hire who joins on Monday and finds three undocumented "ways we do tickets".

On the engineering side the cost was subtler but real: operator overhead. Each morning consumed twenty to forty minutes of context-switching across Linear, the chat, the IDE, and Actions just to get the day's work moving. Agents were fast at the typing, but a human still had to be the orchestrator.

The off-the-shelf options all came with the same trade: store your code or your secrets in someone else's SaaS, accept a proprietary opinion about how tickets, branches, and reviews should look, and replace one chat-driven blob of folklore with another. For a public-by-default e-commerce business that wanted to move faster without ballooning its third-party risk surface, that math did not work.

The ask was specific: keep code, secrets, and audit trails inside the systems the team already owns; let engineers compose the loop from named, diffable parts; and make the whole thing readable by a non-engineer on the buying committee.

ElMundi adopted Ship as an owner workspace on top of Linear and GitHub. The fix is not another dashboard — it is policy-first documentation plus automation that matches the words. Ship names the rules, owners, and evidence so security can inspect instead of guess.

• Linear became the spine. SDLC projects, states, and labels were standardised so an agent and a human can both reason about "what is in flight, what is blocked, what is done" without translation.
• GitHub Actions became the nervous system. Scheduled and on-demand workflows own agent launch, docs sync, and release hygiene. Secrets stay in GitHub, not in prompts.
• Cursor Cloud Agent became the execution layer. Branch-per-ticket runs, PRs as the review surface, no long-running "pet" agents.
• Playwright became the proof layer. Hosted browser runs attach traces and screenshots directly to the ticket narrative.
• The docs became the contract. Every workflow file, label, and state has a page under /use-cases/elmundi; the page anyone reads ships the same words the automation enforces.

The implementation was deliberately small. The team started with one workspace, connected Linear and GitHub, named the first policies they wanted to enforce (intake, planning, agent launch, release readiness), and pointed existing GitHub Actions at the new workflows. The first end-to-end run — a ticket in Linear, a branch cut by an agent, a PR with a Playwright trace, a merge — happened on day one. The follow-up week was spent tightening labels, naming conventions, and the owner rota for failed runs.

What did not happen is also worth naming. There was no migration project, no "adoption committee", no parallel staging org, no rewriting of existing code to suit a vendor schema. The workspace is additive; the existing CI, branch protection rules, and Linear automations stayed exactly as they were.