What Happens When I Need to Modify My Vibe Coded App Later?

A client with a trading card platform spent months trying to raise money on pitch decks and got nowhere. So he built a vibe coded version of the product himself and pushed it as far as he could on his own. Once there was something people could click through, the conversations changed, because he could demo how the thing was meant to work rather than describe it.

The first version takes an afternoon, and then it has to survive every decision you make after that afternoon.

The harder question arrives later. The payment provider changes its terms, a partner retires the API you built against, or the first hundred users all ask for the same missing thing. Now you have to fix a vibe coded app that you didn't write, that nobody documented, and that was generated by a model with no memory of why it made any of its choices.

This piece is about what actually happens at that point. What the first change costs, which kinds of change hurt most, when repair gets more expensive than rebuilding, and how to leave the product in a state where the next change is easier than this one. Most of what follows comes from picking up products other people started, which is a large part of what we do.

Why the First Change Costs More Than the First Build

Writing code and changing code are different jobs. The first version only has to work once, in one shape, for one person who already knows what they meant. The second version has to work without breaking the eleven things built on top of the first one, for people who have never met the person who prompted it.

We worked on a long-running communications product where the debt in the codebase never got dealt with. Every release, the clean-up got pushed back one more cycle. As Simon describes it, "It never got addressed so it just kept accumulating and it wasn't until the actual technical debt became so great that the fragility of the product became an issue." By the time anyone acted, the work had grown into a much bigger and more disruptive job than it needed to be.

That product had human engineers making deliberate trade-offs and writing them down. Teams in that position already spend roughly a quarter of development time dealing with technical debt, according to ScienceDirect. A vibe coded app starts further back, because nobody weighed anything. The model picked a pattern, it worked, and the decision got baked in without ever being a decision.

What You Actually Inherit: Reading a Codebase Nobody Wrote

Opening a vibe coded codebase for the first time is a reading exercise before it's a writing one. The same logic often appears in four screens with small differences in each. There's rarely a test suite. Keys sometimes sit in the front end. The database is shaped by whatever the first prompt happened to ask for, which was almost never the full picture of the business.

Before quoting on any change, we look at a short list of things.

• Where the data lives and what shape it's in
• How login and permissions were handled
• Whether payment logic sits on a server or in the browser
• How many copies of the same function exist
• What breaks silently when something fails

The shape you inherit costs real money. On an alcohol buying and selling platform, we were pushed into embedding web elements rather than building a proper API layer, a constraint set before we arrived. That added about a twenty percent uplift in work across the entire length of the project. The client wanted the budget held flat, so we dropped features towards the end to pay for it. Nobody chose that trade on day one, and everybody paid for it by month six.

The Four Kinds of Change, Ranked by Pain

Not every change is the same size, and the word "small" from a founder and the word "small" from a developer rarely mean the same thing. It helps to sort what you want into four kinds before anyone estimates anything.

Foundational changes are the ones that sink timelines, because they pull on parts of the product nobody thought were related.

A change feels small right up until it touches the data model, and then it touches everything.

We saw the cost of that on a dating app. Huge effort went into onboarding verification and none into messaging, so messaging got built generically and allowed the exact behaviour the onboarding was designed to stop. Rewriting that section from scratch cost around fifteen thousand pounds in extra budget and about two months of extra work.

When the Change Is Structural: Swapping an API or Integration

On a travel product, we integrated with a third-party aggregator at the client's request. Midway through development the client worked out that the aggregator's added costs made the financial model unworkable. In Simon's words, "the client decided that the cost that the aggregator was adding on was just too much... then we had to go back to the drawing board, re-engineer a lot of the flows to now work in the new way of working." The replacement supplier's API worked in a fundamentally different way. Later the client added a third external service to handle specific bookings, so we did another round of integration work on top.

Why the integration layer is the fragile part

That was a careful team doing careful work, and it still cost weeks. A vibe coded app handles a supplier swap worse, because the calls to the old service are usually scattered across screens rather than sitting behind one layer. Every place that talks to the outside world has to be found, rewritten, and checked for security, and the only way to find them all is to read the whole thing.

Before you sign with any third-party supplier, ask what happens to your product if you leave them in six months. The answer tells you how much integration code to put behind a single layer.

When the Change Is Cosmetic: Layering New Design Onto Existing Code

We were brought in on a wellness genetics product to work on its emotional layer. The product was very data heavy, the brand was premium and wellness-focused, and the build had been done in a functional way that didn't match how the brand was meant to feel. Our job was getting people to engage with all that data.

Our designs went to the development team by way of a third-party designer in between, who produced something that looked very luxurious. As Simon put it, "the development team struggled with really understanding how that could work based on what they currently had... there was a few kind of different back and forth that we had to do." The visual target was clear. Building it on top of the existing code was the slow part.

Why a new skin pulls on old code

Cosmetic changes stay cheap when the original build separated how things look from what things do. Vibe coded front ends often hard-code colour, spacing and copy into each screen individually, so a brand refresh turns into forty small edits with forty chances to break something. The design looks like a surface job and behaves like a rebuild.

Where the Foundations Give Way: Auth, Data and Payments

Some changes come from outside the product entirely. We worked on a currency exchange product designed to let people transfer leftover foreign currency to each other at an agreed rate, getting around bank and bureau fees. Partway through, we found that both legal regulation and Apple's App Store policies ruled out direct peer-to-peer transfers of that kind. The product had to become location-based and in person, so users met up and physically exchanged currency. That's a change to the premise, and every screen underneath it moved.

Payments carry a quieter version of the same risk. On a travel booking product we first wrapped the Stripe booking fee into one clean total, reasoning that travellers want a single number. What we found was that people expected a platform fee as its own line, because that matches how they understand apps working. Hiding it created a worry that a surprise charge was coming later. We broke every fee out, and confidence went up even though there was more on screen.

Login, data and money sit under everything else in a product. When a vibe coded app got those wrong early, the fix is rarely local.

The Scope Creep Trap, Accelerated

On a sports club app, every refinement session we ran to cut scope down ended with a bigger product. Two co-founders were very close to the thing, both living and working in the world the app served, and both strong-willed about what it obviously needed. Simon's account of it is blunt. "Every time we go in and we start to refine a feature down, it's like well of course it needs to do this, of course it needs to do that, which is something we'd never talked about before."

The sessions meant to narrow the product became the place new requirements entered it, and each addition arrived already framed as something that had always been implied.

Sessions meant to shrink the product became the place where new features got in.

Vibe coding pours petrol on that dynamic. When generating a feature takes an hour, the natural brake disappears, and the thing that used to cost two sprints now costs an afternoon of prompting and six months of maintenance. The cost shows up later, on the day you try to change any of it, by which point the product is carrying twenty features that nobody ever agreed to support.

Rework Versus Rewrite: How to Decide

Repair is right more often than founders expect, and rewriting is right more often than developers like to admit. The question we ask is whether the existing shape can hold what the business does now. Signs that it can't, and that a rewrite of that part is the cheaper road, look like this.

• The data model can't store what the business has become
• Login or payments were bolted on after the fact
• Small changes keep breaking unrelated screens
• Nobody can say what a section does without reading all of it
• The fix keeps costing more than the feature did

A rewrite buys you decisions made on purpose. On a holistic mental health and wellness product covering mental health, eating habits, exercise and wellness, we looked at serverless first and ruled it out, because endpoints wouldn't be hit steadily enough and the cold-start latency would have been too high for the experience we wanted, and that kind of architectural judgement is central to good app development. We built a monolith with message queues and a small number of separate services, and that worked much better for that product.

No prompt makes that call for you. Somebody has to understand the usage pattern first.

What Modification Really Costs, in Money and Months

What it costs to fix a vibe coded app

The sports club app is the clearest number we have. What should have reached market in three to four months never launched at all after twelve to fourteen months of development, and the budget almost doubled on the way. All of it was forecast and advised against by the development team at the time, and the advice went unheeded.

Money pressure also arrives as lost reach. On a bootstrapped social football platform, the client wanted to launch on iOS and Android. Scope kept growing, budget got critically tight, and midway through we chose to pause the Android work and put all the remaining money into iOS. The client launched with iOS only, carrying as many features as we could get through, and addressing roughly half the potential market.

For a vibe coded app, the honest budget has three parts. There's time spent reading and testing what exists before anyone touches it, which founders rarely plan for. There's foundation work on login, data and payments, which usually gets done once properly or three times badly. Then there's the change you originally asked for, which is often the smallest line on the invoice.

Getting the App Into a State Where It Can Be Changed

There's a sequence that makes the difference between one painful month and four. It starts before any new feature gets built.

1. Freeze the feature list and write down what the product must do today
2. Get a read of the code, including where data, login and payments actually sit
3. Put the foundations right first, even though nothing visible changes
4. Add tests around the parts that take money or hold user data
5. Pull outside services behind a single layer so suppliers can be swapped
6. Then make the change you came for

Skipping to step six is the common move and it's the expensive one. Between 23% and 42% of an average organisation's development time gets wasted because of technical debt, according to CodeScene, and that's in companies with engineers who knew what they were doing at the time.

Get the read of the code done as a paid piece of work with a written output, before anyone quotes for features. A few days of reading changes what every later estimate is worth.

Working With a Development Team on Someone Else's Code

Handing a vibe coded app to a team is a negotiation about responsibility. They're being asked to stand behind decisions they didn't make, in code nobody can explain, and the honest ones will say so. The way through is agreeing what gets inspected, what gets kept, and what gets replaced, before anybody promises a date.

Design churn makes it worse than it needs to be. On the social football platform, the design kept changing throughout, driven by someone on the client's own team with no account taken of what each change cost in development. Every revision landed as new work on a budget that was already stretched, and it fed directly into the decision to drop Android.

Design changes are free to draw and never free to build.

Rework at that scale is normal rather than exceptional. Up to 80% of respondents told Geneca they spend half their time reworking software, which is self-reported and still worth sitting with as a reality check. If half of a team's effort goes on redoing work in ordinary conditions, inheriting an undocumented codebase is not the moment to assume a clean run.

How to Vibe Code So the Next Change Is Cheaper

None of this is an argument against vibe coding. The trading card platform client got in front of people because he had a demonstrable product to show, and no deck was going to do that for him. The aim is keeping that speed while leaving less mess behind it.

A few habits make the difference.

• Decide what the product is for, and keep anything else out of the prompt
• Keep every call to an outside service in one place
• Never put keys or payment logic in the browser
• Write down what you asked for and why, as you go
• Sketch the data model yourself before generating screens against it

The data model is the one worth real thought, because it's the part that's hardest to change later and the part a model will happily guess at. Twenty minutes drawing out what a user is, what they own and how those things relate will save weeks when the business shifts.

Treat your prompts as documentation. Keeping them in a file alongside the code gives the next developer the only record of intent that exists.

Conclusion

Modifying a vibe coded app is possible, and plenty of good products have started exactly that way. The cost sits in a place founders don't expect, which is reading and understanding before building. The work you came to do is usually the quick part.

Sort your change into cosmetic, additive, structural or foundational, and be honest about which one it is. Cosmetic changes stay cheap when the original build kept look and logic apart. Structural ones, like the supplier swap on our travel product, mean re-engineering flows rather than editing them. Foundational ones touching login, data or payments mean most of the product moves, and that's where the dating app messaging rewrite cost fifteen thousand pounds and two months that could have been spent elsewhere.

The decision that matters most is whether the shape you've got can hold the business you now have. When it can, repair it properly and put tests around the money. When it can't, rebuild that part deliberately, the way we sized the architecture on the mental health and wellness product, and keep everything else running while you do.

If you've got something working and you're staring at the next change, we're happy to look at it with you. Let's talk about what your app needs next.

Frequently Asked Questions