Cover image for How do you deal with content editing after the site has been shipped?

How do you deal with content editing after the site has been shipped?

madza profile image Madza ・1 min read

You have most likely experienced a situation where the client asks you to develop a custom static site with general info about the business, services, and contact info.

The client says the content will not change, so you eliminate the need to base it on WordPress, Joomla, Drupal, etc. So you write it from ground-up, deploy it on a server and the client is happy for now.

Half a year later, the client has changed the mind and decided to change some information in it, so he/she asks for some edits.

You might get down with one case, but what if you have like 50 sites? How do you deal with situations like that?

1) Do you always create some CMS that comes along in the beginning, no matter the complexity of the site and what the client assures about the content always being 'static' (as you know, it will be not), and then ship the site with access to CMS so clients can edit it later by themselves?

2) Do you prefer not to implement any CMS at the beginning for simpler sites (believing in the client) and offer to create CMS only if they start to ask for edits and then charge for the creation of CMS?

3) Or do you prefer to make an agreement with the clients on initial shipping about charging them for managing the site for X period of time, guaranteeing yourself the job, and some extra income in the long-term?

Posted on by:

madza profile



Discussions. πŸ’¬ Tools. πŸ›  Resources. πŸ“š All things productivity. πŸŽ―πŸš€πŸ’―


Editor guide

My favorite solution to this problem is. I always structure the static website payload in several JSON files. And adopting the web components paradigm is easy to manage each group of information. To change the content, I just look into the JSON files, I rarely touch the core. Unless changes to the UI.

I don't use no-code web tools to build a static website.

If the project case has closed. To reopen it even for small changes, I will consider it as a new project.


Interesting! Please, tell us more about on how to build a static site with JSON payload content.


This can be achieved by using VueJS, ReactJS, or using simply Vanilla JS to create web components.

Let say I need a section in a static HTML page to display articles in card design, first I create a new web component (HTML+CSS+JS) and UI styling based on the mockup from Framer.

I iterate the data from the JSON file to the card components without duplicating codes.

Example card component to display articles,

<!-- @file: /src/views/components/card/articles.html -->
  <!-- looping data from article.json -->
  <y each="{ data in articles }">
    <!-- begin CSS styling -->
    { data.title }
    { data.description }
    { data.tags }
    { data.date }

    // fetch() data from JSON file
    export default {
      onMounted() {

        const self = this
        self.articles = []

        const url = '/path/to/file/articles.json'

          .then(res => {
              .then(data => {
                delete self.error
                self.articles = data
              .catch(error => {
                self.error = error


An example of payload (data) for the card web component in JSON (example: articles.json).

    "id": "",
    "title": "",
    "description": "",
    "tags": "",
    "date": ""

If I need to make the component reusable, I can make changes to the component with added API callbacks to use it on any pages I want.

An example to convert a web component with added API callbacks.

<!-- @file: /src/views/components/card/articles.html -->
  <!-- begin CSS styling -->
  { props.title }
  { props.description }
  { props.tags }
  { props.date }

And then, mounting and looping the data at another page that need to reuse the same component.

<!-- @file: /src/views/pages/article.html -->
  <!-- looping data from article.json -->
  <y each="{ data in articles }">
    <!-- mount the `card` component -->
      title="{ data.title }"
      description="{ data.description }"
      tags="{ data.tags }"
      date="{ data.date }">

    // fetch() the data from JSON file showed earlier

For me, it doesn't seem too complicated for a static website. But every component (header, navbar, hero, cta, footer, gallery, etc.) are much easier to manage. I can also be hosting the payload (data) at Firebase, which the website is running as serverless.

Do you have a example site in your Github repo with Vanilla JS or at least tutorial to learn this ?

Hoho... I do not have any tutorial for that. But you can find a working example repo of My Portfolio Website.

$ git clone --branch 2.x.x https://github.com/loouislow81/loouislow81.github.io.git
Enter fullscreen mode Exit fullscreen mode

The payload (data) path is in,

Enter fullscreen mode Exit fullscreen mode

I am using the in-house proprietary framework, instead of (Vue.js, React.js, etc.). I am more prefer less, clean and concise programming language design. So that I could spend less time on typing too many codes.




Curious to see peoples responses to this! Good question! Personal experience, I've just gone through the sites html and edited it, not so efficient, but typically when there's a request for content change, there's usually a new feature that they want too..


P.S. Charging for changes is a must..


Exactly, by the end of the day, it's still your work and time πŸ˜‰
Think of that like working full-time 10 years and getting paid for the first month only, as they already paid you once πŸ˜„πŸ˜„


Yeah, on the contrary to the belief of lesser experienced devs that deployment and shipment are the last two phases of the project, it could actually be the beginning depending on the update strategies you use, thus the question πŸ˜‰


Certainly! You gotta play the game, because if you don't someone else will!! πŸ€‘πŸ€‘


I think this is the kind of use case for which 11ty shines. If the customers asks for a content change, it's just a matter of editing a markdown file somewhere or changing an entry on some random json file.


New content === new bill

Add extra time to get back in the project and for the discussion with the client.


Usually I give my clients access to change the content themeselves (wordpress/drupal editor access) but if they keep on asking me for changes they can do on their own I will consider billing them when the changes are done (but perhaps I will be clear about the charges before implementing them so they know before hand)


Hahah, yeah, that's the dilemma πŸ˜ƒ
Tbh, I feel like updating content for them is boring and you cant charge as much as you would spending your time on coding, working on exciting stuff πŸ˜‰βœ¨


If you developed the app using some CMS like wordpress drupal etc. Then you can just relax on some beach. It's ok 😊

And if you used some custom approach like core or framework then it's also cute if you have created custom module for updating contents.

When I dont use CMS, i create custom modules which is smart too. It lists all part of website in a table and on CMS page, it lists all content with edit option. You can just edit and save it. Doing this, it'll refresh cache and user can see new contents

It's not like wordpress but it's good for what I need to deliver on static side


No, I do not always create a CMS. I let the customer decide after giving my SOW recommendations which includes some Pros and Cons for using a CMS.
No matter if the scope changes during the build or 6 months later, it is a new project.
As for small changes, it's up to you. Depending on the change, a good customer gets a little more from me than a bad customer.


Following SOLID with lots of reusable functions and models fixes this problem. Keep views simple and for just one concern. Let functions alter the view and data.

But I do not work on CMS systems.


When I'm in college, I built a simple CMS that generates static files, and took up three websites: housing department, student services, and psychology counseling office.
Two of the departments pay me a fixed amount monthly. The other won't, so I made a complex service plan that includes CMS license fee, monthly service fee, per article posting fee, picture editing fee, text editing fee, etc; if I mess up (e.g. typos), there would be deductions. I learned this from telephone companies.
The posting itself is (1) open the Word document received from email (2) copy-paste to the CMS (3) edit typos (4) move pictures around.

If they want me to repair office computers, I charge by the hour and pay my classmate to do that dirty work.
With that, I don't need my parents to give me lunch money anymore, and I frequently take pretty girls to dinner.


We use Directus which is a flexible headless CMS, and get content from it using API. It's versatile, and we use it for blog, documentation, products, placeholders, media, etc.

You can get it up and running in minutes with Docker image.

You can even use it to send there content via API. For example, our Github Actions send there new versions of our CLI tool, so once it's built and distributed, the web is immediately and automatically updated too.

It can be theoretically used for user accounts, there are some roles and permissions, etc.


When I was doing websites for customers (rarely do that anymore), I always went the CMS route since some content ALWAYS changes. The most important realization for me was:

Customers tended to say, they want to update site content themselves. Thus I developed a lot of sites using Joomla, since it offers WYSIWYG editing. But creating a good template for Joomla allowing easy extension and editing is tough and time consuming/expensive.
A few months after training them on the CMS they always came back asking me to do the edits. Some even did not have the credentials for the backend anymore or had no idea how to do anything in there.

My conclusion:
I tell/told customers that they will possibly never edit the site themselves and enabling a CMS to do so makes the initial project a lot more expensive. The calculation is that it is cheaper to let me do the edits and charge by the hour.
I then use OctoberCMS, which is easily customizable/themeable to the customers wishes and offers me easy editing (requires some HTML/CSS) and maintenance, when I need to.

Result: Happy customer, happy developer.