Rebuild or patch an app used to be a budget argument. In 2026 it is a demo argument. An agent will stand up a fresh repository that looks like the product by Friday, and the fresh repository has none of the edge cases. Your current app is made of edge cases. That is why it is still installed on someone's phone.
The decision is not old code versus modern code. It is: what has to survive the change, and does that thing live in the source, or only in the idea of the product? We do not have a percentage for your app. Nobody does. What we have is three of our own, and a pair of offers that match the two answers.
What our products did when the model showed up
Swiftly Workspace is on version 1.5, and the card says ongoing. The repository measured for the consulting article had 27,197 commits from 2 October 2025 through 26 September 2026, and 20,636 of those commits carry a Claude co-author line. The model joined the history. The product did not get a new name. The Workspace article is careful about what that count is not. This one only needs what it is: evidence that we kept building the same ERP.
FeedbackKit's public Swift repository has tags 1.0.0, 1.1.0, 1.1.1, 2.0.0 and 3.0.0. The README for 3.0.0 points at a migration document for the older tags. Major versions moved. The package name did not. That is a patch path with breaking changes written down, which is a different object from a rewrite you ask people to adopt as a new SDK. The "how we built it" article has the shape. This one only needs the tags.
The smallest example is the most ordinary. The admin app already existed. We added on-device translation to it, with Apple's Translation framework, because the feedback arrives in more than one language. That is a patch: a capability in the app the team already opens, not a second admin with a cleaner folder structure.
On-device translation with Apple's Translation framework
When a rebuild is the honest answer
Rebuild when the thing you would keep is the product idea, the store listing and the accounts, and the code's boundaries cannot take the change you actually need. A shared-UI experiment that has become two platforms of special cases is a common version. So is an app whose data model cannot express the business anymore, so every feature starts by fighting the schema.
Even then, the agent does not make it cheap. It makes the first week look cheap. The cost that remains is the behaviour you already shipped: the bugs you fixed, the review notes you already survived, the customers who learned the old gestures. Someone has to check the new app against that behaviour. If the quote for the rebuild has no line for that check, it is a quote for a demo.
Ownership does not reset because the folder is new. The bundle id, the Apple account and the Play account should be the ones the company already holds, unless you are deliberately abandoning the listing. A rewrite that starts in the agency's organisation is how you lose the app you were trying to save. The ownership article is the checklist. The Android verification article is what happens on Play when the wrong account created the package.
When a patch is the honest answer
Patch when you can name the behaviour, point at the module, and put a person on the review of an agent's diff. Workspace staying at 1.5 is that answer at product scale. The translation work is that answer at feature scale. A patch is not a refusal to modernise. It is a refusal to throw away the edge cases in exchange for a repository an agent finds easier.
The staff-augmentation article's evidence, which this post will not re-quote, is that writing got cheap and review did not. That lands harder on a patch than on a green field. The green field is where the model looks brilliant. The patch is where "almost right" meets a customer who already has the old build. You want the reviewer who knows the old build.
Staff augmentation when AI writes the code
Questions before you fund either
- What behaviour must survive, and where is it tested today?
- Do the bundle id, the package name and the store accounts stay?
- Are you keeping the code's boundaries, or only the idea?
- Who reviews the agent's work against production, and is that person named in the quote?
- What is explicitly dropped? A rebuild with no drop list is a rewrite of everything, including the bugs.
Two ways of working match the two answers, and both are already on the home page. A direct native iOS build, mostly written with AI and reviewed before it ships, is how a rebuild or a hard patch of an Apple app gets done with my name on the review. A dedicated developer from Davao, managed from Antwerp, joining the repository you already have, is how a patch stays inside your codebase instead of becoming a second product. Neither is a reason to rebuild. They are who does the work once you have answered the list.
Comments
Loading comments…