The second interface problem: who learns the builder, and who pays

The smallest version of the problem is a price in a header. A five-page site quotes a consultation fee in a header that every page shares. The fee goes up. The client opens the contact page, finds the header at the top, changes the number, saves, and checks. It is correct. The other four pages are not, and nothing on the screen said whether they edited the one shared copy or one of five.

That is not carelessness. To anyone not holding the database in their head, the header on the contact page and the header on the about page are the same object: same position, same pixels. The interface renders both possibilities identically, and the price is now wrong in four places.

A page builder puts a second interface on top of WordPress. The builder is where the site is; the admin is where the account and the page list live. The client learns whichever puts a visible result on screen, then uses it for everything, including the work it is bad at. That is the second interface problem. It is not a Divi problem: it is the shape of a decision made whenever a builder is sold as the editing experience.

Divi is the case here because Elegant Themes sells the theme and the builder as one editor, which makes the second interface the product rather than an add-on. Nobody at WPSifero has built a site in Divi. Nothing below is a review, and no sentence describes using the product. Every statement about Divi comes from Elegant Themes' pages, cited where it appears.

Disclosure: WPSifero earns a commission on sales made through the Elegant Themes link in this article. The price you pay is the same. Nothing here is a review: nobody at WPSifero has built a site in Divi, and every statement about the product is taken from Elegant Themes' own published pages, cited where it is used.

The client learns the builder, not WordPress

WordPress admin is a set of containers: posts, pages, media, menus, users, and whatever post types plugins register. The builder is a canvas. Both edit the site, and only the canvas shows the finished page while it is being edited.

The first month teaches the client to open a page, change words, add a section, replace an image and publish. It does not teach that a page is one post type among several, that a menu is assembled from links, or that a role decides which containers exist. None of that is needed to edit in a canvas.

The bill arrives later, in the questions the client cannot answer: where the staff biographies live, why the new page is missing from the footer, why the blog archive looks nothing like the page they were shown. Those are WordPress questions, and the interface they trust has no vocabulary for them.

There is a version of this that works, and it depends on one habit from whoever builds the site: calling the second interface a second interface, in the handover, in the training and in the document. Not "this is how you edit your site" but "this is where layout changes, and this other screen is where facts live". A client told there are two tools will use two.

A record dressed as a layout is the expensive mistake

Content splits in two, and the split has nothing to do with how it looks. There are records: staff profiles, testimonials, locations, opening hours, prices, stockists. Each is one row with the same fields as its siblings, the set grows and shrinks, and the site lists them somewhere. And there are arrangements: a homepage, an about page, a campaign landing page, used once, judged by how they look.

A builder is good at arrangements and indifferent to records. Each record becomes a hand-made arrangement of that record, so the seventh testimonial costs what the first did, and no screen lists testimonials as a set. Newest three on the homepage and all of them on a dedicated page is two arrangements kept in step by hand.

Builders answer this with reuse. Elegant Themes' documentation defines a global library item as a Module, Row or Section that appears the same on whatever pages it is added to, and says editing it changes every page that uses it. That solves the header, and it is the right tool for a logo, a phone number, a footer line. It does not turn a layout into a record. Adding the sixth person means editing the layout that holds the five, and nothing can sort the set, filter it or hand it to a feed.

The diagnostic is a query, not an opinion. Pick a fact that should exist once, such as the main phone number, and ask the database how many published rows contain it.

SELECT ID, post_title, post_type
FROM wp_posts
WHERE post_status = 'publish'
  AND ( post_content LIKE '%555 010%'
     OR post_content LIKE '%555-010%' );

One row is healthy. Four rows mean four copies of a fact the client will update in one place, because four places is four decisions. Run it for a price, an address and a strapline. Each result is a line in the handover conversation, and the fix is not a better builder. It is a post type with the fact as a field.

Not all repetition deserves that. A copyright line in a footer belongs to the layout, and turning it into a setting is how a site acquires screens nobody opens. The test is whether the content changes on its own schedule.

The handover document has to name both interfaces

Most handovers are an inventory: plugin names, a password, a note that backups run nightly. That does not answer the only question the client will have at 9am, which is where to make this change.

The interface column carries the weight, because it answers what the client may touch and what they should ask about. Naming the shared items belongs there too, because the opening failure was not a wrong click. It was ambiguity: one header, two states, no label.

Write it in the client's words. "The box at the top that says the fee" is a better landmark than a module name, because the module name is the thing the client has not learned. Then test it on someone who has not watched the site being built: hand them the document and a change, and see whether they find the screen.

The next maintainer knows WordPress, not the builder

The cost missing from most proposals is not the licence. It is the second set of conventions every person after launch has to learn.

A WordPress developer can open the admin and find posts, menus, media and users, because those are core and their shape has been stable for years. Faced with a builder, the same developer has to learn the canvas, the global items, the module names and the storage. That cost is paid at every handover, because the builder knowledge lives in a person rather than in the site.

Storage is where the skills diverge. Elegant Themes' documentation states that Divi 4 stored a page as shortcodes in the post content, for example [et_pb_text ...], and that Divi 5 uses a block-based framework that does not use shortcodes. A maintainer who knows only WordPress can read the text inside a shortcode page. The newer storage keeps words and layout in the same markup.

Migrations sharpen the split, and Elegant Themes publishes the caveat rather than hiding it.

None of this argues against builders. It argues for pricing the second interface as a recurring cost with an owner, and for writing into the handover which parts of the site depend on conventions the next maintainer will not have. A site whose layout only one person can change is not a bad site. It is a site with a named dependency.

The test is a price change in the header

There is a way to find out what was handed over, and it needs one meeting. It also works before launch.

Pick a figure in a shared part of the layout, such as the header fee from the opening. Ask the client to change it, without instructions, while somebody watches and says nothing. What matters is which tool the client reaches for first.

• The builder, and every page updates. The client has learned the shared item. The second interface is doing its job.
• The builder, and one page updates. The client is editing copy inside a layout and believes they are editing what they can see. Every later change will be page-shaped, including the ones that are data.
• The WordPress admin, looking for a field. The client thinks in records. For this fact that instinct is right, and the price belongs in a field.
• A question. Nothing has been handed over. Either the document does not name the screen, or the training named too many and settled on none.

Run it twice: in the week after launch, and a month later without warning. The first run tests the training. The second tests what survived it. A client who solves the second run without asking was handed an interface. A client who asks again was handed a dependency.

When the second interface earns its place

The second interface earns its cost when the person paying intends to design. Not edit words: design. Changing backgrounds, rebuilding a page for a promotion, adding cards for a new service, trying a layout and discarding it. That person gets a tool that matches the work, and the licence is a line they chose.

The price of that choice is public. Elegant Themes' pricing page, as published on 2026-10-19, lists Divi at $89 billed yearly for unlimited websites and Divi Lifetime at $249 as a one-time payment, with the page's own comparison table showing one year at $89 and ten years at $249. Prices change, so read the page before planning around it. The question is whether the tool is worth anything to the client who uses it twice a year to correct a phone number.

Where the second interface is a cost with no return is a site whose content is facts: prices, hours, staff, addresses, stock levels. Those changes are small, frequent and have nothing to do with design, and a layout tool is the wrong instrument for all of them. The client will still use it, because it is the tool they were taught, and the site will accumulate layouts where it needed fields. The real number for that trade sits on Elegant Themes' current plans and prices, next to a renewal date the client meets in twelve months.

So the decision rule, in the order the work happens. Count the changes the client will make in a year and sort them into arrangements and records. If arrangements outnumber records, the second interface is the product and the handover is about learning it. If records outnumber arrangements, the client needs post types and a document saying which screen owns which fact. Then run the price-change test in week one and week five, and believe the second result.

A builder is not the mistake. Assuming one interface is enough is the mistake, and it is made by the person who writes the handover, not by the client who uses it.