About Eddy
For developers who ship client websites and are tired of sitting between the client and the repo.
Eddy started from a familiar pattern. A developer ships a site, the client loves it, and then the emails start: change this headline, swap that photo, fix the opening hours. Each edit takes five minutes. Each one costs a twenty-minute context switch. Little of it is billable, and somehow all of it is your job.
Another feedback tool was not the fix. Those tools collect the request and hand you a ticket. Someone still has to open the repo, find the file, and make the change. That someone is still you.
So Eddy does the part after the ticket. The client opens their live site, clicks what they want changed, and describes it in plain English. Eddy finds the file in your GitHub repo, makes the edit, and opens a pull request. You review the diff. That is the job now.
Clients click their live site, describe the change in plain English, and Eddy turns it into a previewable pull request you can review and publish.
What we believe
The repository stays the source of truth. Eddy does not add a shadow CMS or a parallel content database that drifts from your codebase. Every change is a normal pull request on your repo, reviewable like any other change.
You stay in control. Merge strategy is yours per site: review everything by hand, require CI to pass first, or auto-merge the routine ones. Nothing reaches production without a decision you already made.
Clients do not need to learn anything. No GitHub account, no dashboard, no new login. They already know their own website. Eddy meets them there.
Where things stand
Eddy is in beta and free while we build it with the developers and studios already running it on real client sites. We would rather ship something narrow and honest than promise a roadmap we cannot back yet. If Eddy cannot do something today, we will say so.