45 minutes to change two links in a footer
Or how I stopped doing work that nobody actually needs.
It was a Wednesday afternoon. I was deep in thought and code on a new project when an email from a client popped up:
If you don't build websites, you'd think: that's a thirty-second job. And honestly, it should be. But we live in the age of the "modern web workflow".
So here's what that "quick favour" actually looked like:
- Find the folder with the repository where the project is checked out.
- Pull the latest version.
- Create a new branch:
hotfix/footer-links-update. - Find the right file with the footer partial.
- Change exactly 2 characters of text and two URLs.
- Commit, push, open a Pull Request on GitHub.
- …and wait for a colleague to approve the review (they have their own work, of course, so this has to wait).
- Watch the deployment pipeline spin its little circle for four minutes.
- Footer updated on the live site.
Total time: 45 minutes. Actual work: 10 seconds.
I sat there and — not for the first time — asked myself: why is this so complicated? And why am I acting as a communication layer between the client's brain and a text file? Don't get me wrong, complex web apps need workflows, development plans, deployment, database migrations, testing… the whole thing mirrored on production… But for a coffee shop website that doesn't even have a blog? Seriously?
The problem isn't the clients. It's how we've set things up.
Web development has made a massive leap in the past ten years. We've got CI/CD, containers, headless CMS, Docker, Git flow, thousands of frameworks and tools… But in the process, we've also created an absurd situation — even the tiniest change on a website requires a full deployment pipeline. And most importantly — the client is out of luck.
The standard answer to this came years ago — a CMS. WordPress, Joomla, Drupal and the like, where the client can edit almost everything. Or rather, whatever the developer's setup allows them to.
But seriously — WordPress for a footer?
That's like driving a tractor to pick up your kid from the nursery across the street. Sure, a CMS brings the comfort of editing and other features, but suddenly you're also dealing with plugins, security updates, a database, and an entire infrastructure — just so a client can change a phone number once a month.
And headless CMS? Great for large projects with dynamic content. But for a static business site with five pages? Should I rewrite clean code into API calls and loading states just so someone can edit a sentence in the "About Us" section?
I didn't need a "content management system". I needed an editing layer — something that sits on top of a finished website and lets the client change content without touching the code.
And that's exactly why Direct Edit was born.
How it actually works
The principle behind Direct Edit is simple. It doesn't rewrite your code, doesn't add a database, doesn't change how you build your site. It's a handful of files that sit on the server next to your website, read the existing HTML, and make the content editable.
I deliberately chose a modal interface — the client doesn't click directly into the page (that leads to accidentally deleting a container and breaking the whole layout). Instead, they click on the icon of the element they want to edit (text, link, image, SEO…), a clean window opens, they change the content and save. Done.
It's a safety net, essentially. The client gets the freedom they want. And I get peace of mind knowing they won't call me at 10 PM because the navigation menu disappeared.
What surprised me along the way
Originally, it was meant to be a simple text editor. But gradually I discovered you can go much further — and it still stays simple.
Section cloning. The client needs to add a new service card or a new blog post? No need to call a developer. They take an existing section, duplicate it, and rewrite the content. They're working within the design that was built for the site — they can't break it, but they can extend it.
SEO. Page titles, meta descriptions, image alt texts — all of that can be edited without a single line of code. No more "send me a screenshot from Google Search Console and I'll fix it for you."
Teamwork. When two people are editing at the same time, the system knows. Nobody overwrites anyone else's work.
I got my Wednesdays back
I built Direct Edit because I wanted to stop doing work that nobody needs. To stop being the middleman between the client and a text file.
These days, when a client calls about a typo, I just gently remind them: "You can fix that yourself in the editor :-)". And next time, they don't call — because they update the site themselves.
They feel like the website is truly theirs. And I can focus on what I actually enjoy — building new things, not fixing old typos.