Between the end of May and the end of July 2026, we shipped seven native iOS apps to the App Store: an AI identifier, a mood journal, a coin identifier, a period tracker, an outfit planner, a reminders app and a sound-session app. One operator, working with AI coding and review agents.
We didn't do it to become an app studio. We did it to find out whether the method we sell to operations teams holds up when the business is a product factory. It did, and the lessons transfer almost word for word. The full case study is here. These are the five things we'd tell any operations leader.
1. Kill things before they cost money
The single biggest lever wasn't building faster. It was building less. Every idea went through a scored kill test before it got a build slot: who switches to it, why, how they'd hear about it, and what could kill it. In the second batch, 30 ideas went in, and five of the seven finalists were killed on evidence before anything was designed.
Operations teams rarely have a kill test for automation ideas. So the loudest request gets built, not the most valuable one. A simple scoring step, applied every time, fixes more waste than any tool.
2. Gates beat memory
Early on, releases depended on remembering a long list of steps: build settings, store metadata, privacy declarations, screenshots, review notes. Every miss cost days in review. The fix wasn't trying harder. It was turning the list into gates that a release can't pass without.
Your business has the same lists. Month-end close, customer onboarding, dispatch. If a process only works because an experienced person remembers every step, it isn't a process yet. It's a person.
If a process only works because someone remembers it, it isn't a process. It's a person.
3. Reuse the infrastructure, never the product
Seven apps built from one template would have been faster and worse. We reused everything underneath: release tooling, analytics, security, build automation. Everything the user touches, from brand to navigation to onboarding, was designed for that product alone.
The same rule applies to operations. Standardise the plumbing: how data moves, how approvals work, how exceptions get flagged. Don't force every team into the same screens when their work is genuinely different.
4. Agents need jobs, and people need to approve
AI agents did a lot of the repetitive work: code, reviews, metadata drafts, checks. They were most useful when each one had a narrow, defined job, and least useful when asked to "handle" something vague. And nothing shipped without a person signing it off.
That's the pattern we use in client automation too. The agent drafts the quote, extracts the order, matches the invoice. A person approves anything that touches money or customers. The time saving is still enormous, and nobody wakes up to an AI having emailed a client something wrong.
5. Measure the system, not the effort
We tracked what each app and each agent cost to produce and what it did after launch, from one control view. That made it possible to answer the only question that matters for a portfolio: where is the value actually being created, and what should we stop?
Most operations teams measure effort: tickets closed, hours logged. Measuring the system means asking what each workflow costs end to end and what it returns. It's a less comfortable number. It's also the one that tells you what to fix next.
The honest caveat
These apps are new. This is a story about speed and a repeatable system, not about downloads or revenue, and we'll publish those numbers when they're worth publishing. But the operating lessons are already clear, and they're the same ones we bring to every client engagement.
Run the same method on your operations
Start with one workflow, working in five days.