I maintain five iOS products in one workspace. Each has its own Vapor backend, and all of them draw on a shared layer of Swift packages: authentication, a design system, a scheduling engine, list and shopping domains, networking. It is forty-three repositories tracked in a single manifest.
One of those products has shipped. Hellopost has been live on the App Store since July 7, 2026. The other four are at various pre-launch stages, and I am going to be specific about that throughout, because the interesting claim here is not how many products exist. It is that a shared foundation underneath several products stayed coherent instead of turning into the thing everyone warns you about.
This is a write-up of how that was done, including the parts that did not work.
The operating problem
The hard part of running several products on one foundation is not writing the code. It is that the foundation is load-bearing in more than one place at once.
A one-line change to a shared avatar component touches two shipped-quality apps. A change to the deployment tooling touches five backends. An abstraction that seems obviously right for the product in front of you is often wrong for the two you are not currently looking at. Every change carries a proof obligation to systems you are not thinking about, and the cost of that obligation is what decides whether shared code is an asset or a liability.
The second problem is discontinuity. The work happens in bounded stretches with gaps between them, and whatever was understood during one stretch has to be available at the start of the next or it gets re-derived. Re-derivation is not just slow. It produces different answers, and the differences accumulate as architectural drift.
None of this is exotic. It is the same problem a five-person team has with a monorepo and three initiatives. It just arrives faster and with less padding when there is one person.
Why chat history and ad hoc coordination failed
The obvious way to handle this is to keep the important things in your head, keep notes in a document, and keep recent context in whatever tool you were last working in. I tried that for a while. It failed in three specific ways.
Context did not survive the boundary. Anything established in a working session was gone by the next one. What survived was code and commit messages, which record what changed and almost never record what was rejected or why. Work would reopen a settled question because nothing on disk said it was settled.
Decisions got made by proximity rather than by authority. When a question comes up mid-task, the cheapest move is to answer it and keep going, and most questions genuinely should be answered that way. Some of them are direction, or product scope, or a tradeoff with consequences past this task. Those were getting resolved silently by whoever was closest to the keyboard, which is a bad way to make them and a worse way to find out later that they were made at all.
Nothing checked the work except me. Self-review is thin at the best of times, and it is thinnest exactly where the risk is highest, on the change you are confident about. “I did not break anything” was an assertion, not a measurement.
The pattern underneath all three: whoever or whatever is doing the work in a given stretch is temporary, and temporary things cannot be the place that truth, authority, or verification lives.
The system that emerged
Five parts, and one rule about what survives.
The owner sets direction and rules the decisions reserved to him. Nothing about the machine requires him to be present for it to keep working, which is the point of separating this box from the others.
Durable knowledge is a documentation repository that records what is true about the ecosystem and holds no plans at all. That restriction is load-bearing: the moment a description of a system also contains an intention about it, you can no longer trust it as a description.
Planning and decisions is a separate queue with three parts: which direction matters right now, what is waiting on the owner, and what to do next. Keeping those apart is what stopped decisions from being made by proximity.
The temporary worker is whatever is doing the work in a given stretch. In practice that is usually a Claude session, and it could equally be a contractor or me on a Tuesday. It starts with no context, takes one task, and ends. Designing for that has a useful side effect: a system a stranger can pick up is also a system your next hire can pick up.
Mechanical safeguards are the rules that have exactly one right answer, moved out of prose and into scripts the tooling runs. Prose rules get forgotten. Enforced rules do not.
Underneath all five: nothing survives a working session except what it wrote down. Everything above is files in git, so it is diffable, reviewable, and portable to any tool that can read text.
Four mechanisms that carry most of the weight
The task file is the brief. Every task is one file written for someone who has never seen the conversation that produced it: the constraints, what was already ruled out, and what “done” means. It is the highest-value habit here and also the least glamorous. A brief that only makes sense to someone who was in the room is not a brief, it is a reminder.
Owner decisions are a queue, not an interruption. A question only the owner can answer gets its own file. Tasks name it as a gate, and work routes around it until it is ruled on. His attention is treated as the scarcest resource in the system: work keeps moving while decisions accumulate for a batch, and a ruling recorded once is citable forever instead of relitigated. Twenty are on file now.
The safeguards refuse rather than remind. A commit to the knowledge repository is checked against a recorded conformance baseline and rejected if it would make the corpus less conformant. A session that tries to end with uncommitted work is blocked. These are not warnings in a document. The tool declines.
Claims carry their evidentiary status. Every documented fact is tagged with how it is known: read from the code, asserted by the owner on a date, or explicitly unverified. The record does not say “RoomAid is not live.” It says that is the owner’s dated assertion, that it was not verified against infrastructure, and which pre-launch state remains unconfirmed. When a fact goes stale you can tell what kind of stale it is, which is the difference between correcting a document and re-auditing a system.
What it produced
One product shipped. Hellopost is live on the App Store, published by RoomAid LLC, free, released July 7, 2026. That is the whole distribution record. RoomAid, the largest of the five and the one that drove most of the architecture, is pre-launch with no users. LiveShopper, ChoreBoard and Mealplanner are proving grounds, built to test architecture rather than to launch. I state it that way because a portfolio claim that dissolves on the first call is worse than a smaller true one, and because this site previously implied more, which I corrected in the same change that published this page.
Five backends on one deployment path. The deployment tooling is not copied into each backend and left to drift. It is vendored from a single repository, with every project-specific value pushed out into per-project config, so the vendored files stay byte-identical everywhere. I re-ran that check while writing this: all five in sync. Standing up a new product’s config, backend, iOS app, database and first migrations is one command, and that command was tested outside this workspace and parameterized to carry a different owner, team and domain.
Products composed rather than rebuilt. ChoreBoard was assembled in a day as six screens over an event-sourced chore domain, drawing on the shared scheduling, design system and calendar packages with zero changes to any of them. The last clause is what makes it meaningful: composition that requires editing the foundation is a fork with extra steps.
Verification that produces evidence. The clearest example is deliberately small. A one-line fix to an avatar component, so initials shrink instead of truncating at large accessibility text sizes, touched a shipped app. The check was not a code review. The screen was captured before and after, the avatar region cropped and hashed, and it came back byte-identical at the default text size and at accessibility-large. The whole screen differed by 425 pixels out of 3,162,132, all confined to one rectangle at the opposite end of the display from the avatar and present in the same extent at both text sizes, which is how it was shown to be an unrelated antialiasing shift rather than a consequence of the change. That is what “I did not break anything” costs when you mean it.
The operating model itself. 180 tasks have gone through this loop. The count is texture rather than a result. What matters is that each one started with no inherited context and finished by leaving its evidence behind.
Limits and tradeoffs
The overhead is real and it has a floor. Writing a brief for someone who was never there costs more than doing a small task yourself. Below a certain size the system is not worth invoking, and pretending otherwise would be ceremony.
Reuse is proven by one person. Every shared package here was composed by the person who wrote it. Whether a second engineer can assemble a product from these foundations at the same speed is untested, which is the weakest link in the composition claim, and I would rather name it than let someone else find it.
Verification is bounded by what you thought to check. Pixel parity proves a screen did not change. It says nothing about whether the feature was right. These mechanisms catch regressions and conformance drift, which is a real category and not the same category as being wrong about the product.
Coverage in the foundations is thin. Bringing the shared authentication and core packages under real test suites is an open workstream, not a solved problem.
It does not replace judgment, and is not an argument that it should. The design routes decisions toward a person rather than around one. What it buys is that judgment gets spent on questions that need it instead of on reconstructing what was already known.
What this means for another product team
I am not suggesting anyone install this. The specific files are shaped by one workspace and one person’s constraints. Four things transfer, and they transfer whether or not any AI is involved.
Separate the three questions and give each one a real home: what is true about this system, what we are doing next and why, and what is blocked on a decision someone owes us. If your team answers all three from the same place, and that place is usually a chat log or one person’s memory, then all three are answered badly and you will not notice until someone leaves.
Write briefs for people who were not in the room. This is the change with the best return and it costs nothing but discipline. It doubles as an onboarding test: if a new engineer cannot act on the brief, the brief was incomplete.
Move objective rules into tooling. Anything with exactly one right answer, branch protection, conformance, formatting, evidence requirements, belongs in something that refuses rather than in a document that reminds. And make verification produce artifacts, so a claim that a change was safe comes with something you can look at afterward.
The outcome worth wanting from all of this is narrow, and worth stating plainly: a codebase that stays coherent while several initiatives run through it, and that does not depend on any one person’s memory to stay that way.
Where to start, if this is your problem
If you have a system and you want a straight read on it, that is a paid architecture review: fixed scope, fixed price. You get a written assessment of the architecture, the boundaries, the deployment path and the verification story, plus a ranked list of what to fix first and what to leave alone. It stands on its own. If it turns into a larger engagement, that is a separate conversation with its own scope.
Book a call and tell me what you are working on.