Most DIY WordPress sites fail in the same place. They look acceptable on a laptop and fall apart on a phone. That was exactly the situation Marcio Cohen described when he messaged me in May 2025. He had built cohencanarias.com himself in Divi and knew it needed work. This post walks through the full Divi website redesign I delivered for him, including the parts that did not go smoothly. You will see how the scope was set, why we deliberately stayed on Divi instead of switching builders, and how a two-factor login problem stretched a fourteen-day job across two months. It is written for business owners who built their own site and now want it done properly.

The Client & The Problem

Marcio Cohen runs a business based in the Canary Islands, Spain. He found me through my Fiverr gig for WordPress design and development. His first message came in Spanish, and he mentioned he was comfortable in English too. Working across two languages became a small but real part of the project.

A Self-Built Divi Site That Had Outgrown Itself

Marcio had built the site himself using Divi. He was clear about what was wrong with it. In his own words, he needed "un diseño responsivo, optimizado y funcional, que se vea bien sobretodo en dispositivos movil" — a responsive, optimised and functional design that looks good above all on mobile devices.

That single sentence framed the whole brief. This was not a rebrand or a new business launch. It was an existing site that worked in principle but did not hold up on a small screen. Mobile presentation was the priority, and everything else followed from it.

Finding a Visual Direction

I asked for a reference site early. That question saves hours of guesswork later, and it is the first thing I ask on almost every WordPress design and development project. Marcio sent over villageremedies.com. He liked the layout but not the blue and pink palette, and he was firm that he did not want a copy of it. So the reference set the structural direction only, not the colours.

What I Proposed

My first suggestion was actually the wrong one, and it is worth being honest about that.

The Elementor Question

The reference site Marcio liked was built in Elementor. Since the layouts he admired were easier to reproduce in that builder, I asked whether we could switch from Divi to Elementor.

He declined, and his reasoning was better than mine. As he put it: "I prefer to work with Divi because I already know it so if I have to update anything later on, I can do it. I dont know how to work with Elementor."

That settled it. A site the owner cannot edit is a site that goes stale within six months. We stayed on Divi. This is a trade-off I now raise openly during scoping on every Divi and Elementor build I take on.

Scope, Budget and Timeline

Marcio's budget was 300 euros. I sent a custom offer at $350 with five revisions and a fourteen-day delivery window, and he accepted it on 23 May 2025.

The scope I outlined was deliberately plain. Redo the module designs across the site. Rebuild the header. Add and remove footer widgets as needed. Then produce a full plan once I had access and could see the build from the inside.

I did not oversell the timeline either. I told him fourteen days was the maximum and I would aim to have a first draft sooner. His reply set the tone for the whole job: "I prefer to wait a bit more and have a good website than do things in a hurry." If you want to see how I structure this kind of fixed-scope offer, my service breakdown lays out the packages.

The Build Process

The design work was straightforward. The logistics were not.

Rebuilding the Modules Inside Divi

Working inside the client's existing Divi installation meant respecting the structure he already understood. Rather than replacing the theme wholesale, I rebuilt the module designs section by section. The header was reworked. Footer widgets were added where they earned their place and stripped where they only added clutter.

The Home page and the Equipo (Team) page were the two layouts delivered at the end of the build. Every design decision was checked against the original brief, which was mobile first, not desktop first. Responsive behaviour drove the layout choices rather than being patched on at the end, which is the same approach I take on all mobile and speed optimisation work.

The Access Problem That Cost Weeks

Here is the part that most case studies leave out. After Marcio accepted the order on 23 May, I asked for the website logins the same evening. Then again the next morning. Then again the day after that.

The messages went unanswered for a long stretch. Marcio was busy running his business, which is entirely normal for a client. But no access means no work, and the fourteen-day clock does not care why. The order duration had to be extended multiple times across the following weeks.

The Two-Factor Authentication Bottleneck

When access finally came through, a second obstacle appeared. The login was protected by a one-time passcode that went to Marcio directly, and that code expired after fifteen minutes.

With a time difference between Pakistan and the Canary Islands, a fifteen-minute window is genuinely tight. It took several attempts before we were both online at the same moment. On 22 July he replied, I triggered a fresh code, he sent it across, and I was in. Small friction like this is why I now request hosting and admin access before the delivery clock starts on any WordPress project I take on.

Migrating the Site to Live Hosting

The final technical step was moving the completed build onto the client's live hosting. That required a separate hosting login and another short coordination window with Marcio. The transfer went through cleanly and the redesigned site went live at cohencanarias.com in the early hours of 23 July 2025.

The Result

The redesigned Divi site was transferred to the client's own hosting and delivered on 23 July 2025. The order was completed and accepted within minutes of delivery, with no revision rounds requested afterwards.

What the Client Said

Marcio's response when he saw the live site was short and unambiguous: "That's great Tallha, thank you!!!"

For a project that ran two months past its original fourteen-day window, closing with the client happy and the order accepted immediately is the outcome that matters. Nothing was rushed, nothing was compromised, and Marcio kept a site he can still edit himself in a builder he already knows.

Key Takeaway

Three practical lessons came out of this build, and all three now shape how I run projects.

Keep the Builder the Client Already Knows

Switching page builders can be technically tidier for the developer. It is often worse for the client. If the owner cannot make a small text change without hiring someone, the site starts decaying the day it launches. Marcio was right to push back, and that lesson stuck.

Collect Every Login Before the Clock Starts

The fourteen-day delivery estimate was reasonable. It was never tested, because the build could not begin without access. Admin logins, hosting credentials and a plan for two-factor codes should all be settled before an order goes live. This is now a fixed step in how I onboard clients for every WordPress engagement.

Time Zones Are Part of the Scope

A fifteen-minute code expiry is a non-issue between neighbours and a real problem across continents. Agreeing a shared overlap window at the start would have removed several days of waiting from this project outright.

Work With CodeSyte

If you built your own WordPress site and it no longer holds up on mobile, a full rebuild is rarely necessary. Often the existing Divi or Elementor foundation is fine and the layouts simply need reworking properly, screen size by screen size. That is the work I do at CodeSyte, and I will tell you honestly if a redesign is not the right spend for your situation. Have a look at what is included in each package on the CodeSyte services page, and send over your current site URL when you are ready for an assessment.