TL;DR
You have three options, and they differ mostly in how much of everyone's time they burn. Option 1: they tell you the change and you make it (the relay). Option 2: they get their own AI session and re-prompt a copy (the fork). Option 3: they edit the live page directly with a no-code editor (the fix). The relay wastes your time, the fork splits the app into competing versions, and direct editing is the only one that scales past two people.
The situation
The AI built the app, it works, and now the person who owns the words wants in: the marketer fixing the headline, the consultant adjusting a client's numbers, the founder who wants the pricing section reordered. None of them writes code, and the app is code.
What makes this awkward is that their changes are almost never structural. They want to change a sentence, a price, a color, a photo. The gap between "trivial change" and "requires a developer or a prompt" is exactly the frustration.
Option 1: the relay (they ask, you do it)
The default. They send you "can the button say Get a quote instead?", you paste it into your AI session, regenerate, re-export, re-share.
Where it's fine: rare edits, or apps genuinely too delicate for anyone else to touch.
The honest cost: you become the bottleneck for every comma. Feedback arrives as prose ("the third box, no, the other one"), you translate it into a prompt, and each round trip costs hours-to-days of latency for seconds of change. Multiply by every stakeholder and every revision round; this is the loop that makes people give up and mail PDFs instead.
Option 2: the fork (they re-prompt their own copy)
Hand over the HTML, or a shared AI conversation, and let them continue with their own AI.
Where it's fine: they're genuinely making their own variant, and divergence is the point. Remix, not revision.
The honest cost: the moment they regenerate, there are two apps. Their copy has the new headline; yours has last week's bug fix; nobody has both. AI regeneration also has a blast radius: ask for a new button label and the model may help itself to "improving" the layout too. And it assumes they have (and can drive) the same AI tool, which for clients is often false.
Option 3: direct editing, without code
Put the app on a surface where the live page itself is editable: click the headline, type the new one; select the button, change its label and color; done. No code shown, no regeneration, no fork. That's the category move: the same HTML, hosted on a collaboration layer with editing turned on for people you choose.
- Publish the app's HTML to the collaboration tool and get a live link.
- Give edit access to the people who need it (viewers and commenters stay account-free).
- They click the thing they want to change and change it. Every edit lands in one version history you can roll back if someone overreaches.
Where it's fine: copy, styling, content, imagery: the changes non-coders actually make, which is most changes.
The honest cost: structural rework (new features, new logic) still belongs in the AI or with someone technical. Direct editing removes the relay for the 80% of edits that never needed engineering; it doesn't make your client a developer, and shouldn't.
Which option, when
| The edit | Best route |
|---|---|
| Words, prices, colors, images | Direct no-code editing |
| "Make me my own version of this" | Fork with their own AI |
| New feature or logic change | Back through the AI, by whoever owns the app |
| One tiny fix, once a quarter | The relay is honestly fine |
The test: count how many of the last ten requests were text or style changes. If it's eight, you're paying relay prices for edits the requester could have made in less time than the message took to write.
How Coedit fits
Coedit is option 3 as a product. Paste in the HTML from any AI tool (Claude, ChatGPT, Gemini, Lovable, v0) and share the link; people you allow edit copy and styling right on the live page with zero code, comments pin to the element they're about, and every change (human or agent) lands in one version history with rollback. The 47/47 concurrency test suite is what lets several people edit at once without stepping on each other.
FAQ
Q: Can someone without coding skills edit an AI-generated app? A: Yes, for the changes they actually want to make: text, styling, images, content. They need the app hosted on a tool with visual, no-code editing rather than as a raw file. Structural and logic changes still go back through the AI or a technical owner.
Q: Isn't it safer to keep all edits going through one person? A: Version history with rollback gives you the same safety with none of the bottleneck: anyone's change can be undone in one click. Gatekeeping made sense when edits were irreversible; on a versioned surface, it's mostly latency.
Q: What if two people edit at the same time? A: On a real-time collaborative surface built on CRDTs, concurrent edits merge automatically rather than overwriting each other, the same behavior you know from Google Docs.
Q: Do my editors need accounts with the AI tool that made the app? A: No, and that's the point. Once the app is on a tool-agnostic collaboration surface, editing needs no AI accounts, no prompting skill, and no knowledge of which model built it.