How Eddy works
One request, end to end: from a client pointing at their live site to a merged, live change. No new tools for them, no lost afternoon for you.
The portal a client actually sees: their own site, one request at a time.
The four steps
The client points and asks
They open their own live website inside Eddy’s portal, click the headline, photo, or button they want changed, and type the request in one plain sentence. No GitHub account, no dashboard to learn.
Eddy finds the file and makes the change
Eddy’s agent works against a clone of your GitHub repository, locates the right file, makes the edit in code, and opens a clean pull request with full context attached. A preview build deploys so the change can be inspected before anything merges.
You review it like any other PR
Skim the diff, check the preview, merge when you’re happy. Nothing reaches production without the merge strategy you chose for that site.
It goes live
With auto-deploy on, the merge ships right away. Prefer to control deploys yourself? Turn auto-deploy off and release on your own schedule instead.
Merge strategy is yours to set, per site
Not every site should be treated the same way, so the merge strategy is a per-site setting, not a global one. Manual review means nothing merges until you click merge, every time. CI-gated means Eddy’s PRs still need your tests and checks to pass before they’re eligible. Auto-merge hands the routine, low-risk changes through automatically once checks are green, so only the ones worth a second look land in front of you. Whichever you pick, it’s a policy you set in advance, not a decision Eddy makes for you in the moment.
A safety net if something ships wrong
Any pull request Eddy opens, merged or not, can be reverted in one click from the developer portal. Because every change is a normal commit on your repo, reverting it is just Git doing what Git already does well. Nothing about an Eddy change requires special handling to undo.
What Eddy won’t do
Eddy is built for content and styling changes, the long tail of “can you change this text” requests, not feature development. It declines requests for new pages, new functionality, or checkout systems, and routes the client back to you instead of guessing at scope it wasn’t asked to handle. That boundary is deliberate: it’s what keeps every PR small enough to review in a minute.