How 3PRIME moved A-1 Sealcoating from a heavyweight Divi build to a lean, hand-coded WordPress theme the client can still edit end to end — with Claude Code working inside the real development environment from migration to launch.
We built the editing experience directly into a custom, hand-coded WordPress theme. The new site is live today at a1sealcoating.com: a homepage and nine inner pages, pixel-faithful to the approved design, with every word and image on every page editable from the standard WordPress dashboard.
The question every small business rightly asks (“will I still be able to edit it myself?”) was answered with a simple yes, built right into the site.
The client and the challenge
A-1 Sealcoating Drivewaysaver LLC has been protecting Connecticut driveways and parking lots for more than 20 years. The company is family-owned, earns roughly 90% of its business by referral, and leads with its BBB A+ accreditation. It’s also a specialist in a precise sense: A-1 protects, seals, and repairs asphalt that’s already in the ground. That focus defines their brand voice, and, as you’ll see, it surfaced in an unexpected place during the rebuild.
After years online, the site was due for a refresh. The brief was to carry two decades of hard-earned reputation into a faster, cleaner site the team could keep current on their own.
The brief had three requirements that usually pull against each other:
- Lean. Hand-coded and lightweight, for fast page loads.
- Faithful. A pixel-accurate port of the approved design: a port, not a reinterpretation.
- Editable. The owners update their own copy and images from the normal dashboard, with no agency ticket needed for a text change.
The headline decision: a custom, client-editable content layer
We built a three-layer content system on native WordPress primitives:
- Per-page content (every hero, section, call-to-action, and image) lives in post meta, edited through meta boxes right on each page’s normal editor screen.
- Global content (the header, footer, and the site-wide testimonials band) lives in options, edited under a custom “Site Content” admin menu.
- Business settings (phone, address, license number, reputation link, analytics ID) live on a dedicated settings screen, so a number that changes once changes everywhere.
The part we’re proudest of: one field-schema definition drives both the page meta boxes and the global option screens. The form renderer and the per-field-type sanitizers are decoupled from where the data is stored, so the validation and escaping logic was written once and reused everywhere. And the code’s built-in defaults are the single source of truth: clear any field and the site falls back to sensible default content, so no page can ever render blank. Building an entirely new page became a clean four-file recipe.
How we actually used AI (and how we didn’t)
This was not “AI wrote our website.” It was two tools with two distinct jobs, inside a human-led process.
Claude (claude.ai) handled the thinking that precedes code: planning, architecture decisions, detailed work orders, design and report reviews, and persistent project memory across weeks of sessions. Claude Code handled execution inside the actual environment, not as autocomplete, but as a hands-on engineer. It migrated the live site down to a working local copy, ran WP-CLI, curled rendered pages to verify output, captured headless-browser screenshots at phone, tablet, and desktop widths, linted every file it touched, and read the server logs when something broke, then wrote each fix down so it never cost us twice.
Three habits made the difference:
- Decisions before code. Three product decisions (the site-wide contact-link policy, the service-page mapping, and the editability model itself) were explicitly surfaced, debated, and locked with the humans before the build started. The AI asked; we decided.
- The spec got code review. Before the inner-page work order went to Claude Code, it was audited like a pull request. That audit caught and fixed 18 issues in the spec itself, including an instruction that would have destroyed real content during testing, and a sequencing bug that would have transiently broken the site’s rendering mid-build. “Prompt engineering,” done seriously, means engineering the spec like code.
- Living documentation as a first-class output. An engineering guide, a design-system style guide, a plain-English editing guide written for the client, and phase reports, all maintained as the work happened, so any session, human or AI, could pick up cold.
The AI also enforced the client’s non-negotiable brand rules in both code and content: the language rule below, the BBB-first reputation strategy, exactly one H1 per page, and escape-on-output security throughout.
Four hurdles worth telling
The forbidden-word SEO leak. A-1’s marketing deliberately avoids one specific industry term: it names a kind of work the company doesn’t offer, and using it would misrepresent them. During the rebuild we found the SEO plugin was auto-generating each page’s meta description from leftover demo text in the old build, and that text contained exactly the off-limits term, quietly leaking it into Google search snippets and social-share previews. The fix was two layers deep: a clean, in-voice meta description written for every page, then clearing the SEO plugin’s cached copy of each page so it rebuilt from the corrected content.
Brand color vs. accessibility. A-1’s signature orange is great for buttons and fills, but as small text on light backgrounds it failed WCAG AA contrast. Rather than abandon the brand color, we surgically redefined just the text-color variable to a darker, AA-compliant shade. True brand orange stays everywhere it already passes: fills, buttons, and orange-on-dark. A documented, intentional deviation, not a global “darken everything.”
A silent form-field trap. The editing layer’s link fields legitimately hold relative paths and on-page anchors. Native HTML URL inputs reject both, and in WordPress, that rejection silently blocked the entire page from saving, with no error a normal person would ever find. We switched to plain text inputs that still bring up the URL keyboard on mobile, and moved validation server-side. The kind of gotcha that costs an afternoon, once.
Shortcuts made real. The approved mockup had the usual placeholder stand-ins: dead links, a decorative menu, a static form. Every one was replaced with the real thing (a working estimate form, a real mobile menu, a real services dropdown, live click-to-call and click-to-email) plus a single centralized contact-link policy, so every call-to-action routes correctly: scroll-to-form on the homepage, the contact page everywhere else.
How we knew it was done
Most agencies say “we tested it.” Here’s what that meant on this project. Before anything was called done:
- Every theme PHP file lint-clean; every script syntax-checked.
- Automated sweeps for the forbidden wording across the entire codebase.
- The whole site re-rendered with debug logging on, to prove zero PHP notices or warnings.
- Every page confirmed loading correctly with exactly one H1 and proper heading order, no leftover legacy markup, working CTAs, and no dead links.
- Responsive checks at desktop, tablet, and phone widths via headless screenshots.
- A regression diff of the homepage against a saved baseline, so the approved design provably didn’t drift while the rest of the site was built.
And the tests themselves were designed to be non-destructive, proving the default-fallback behavior, for example, without ever touching real content.
Launch and results
Going live, we verified from multiple independent vantage points: regular browsers across different networks, plus a fetch using a search-crawler user agent, because any single observer can hold a stale, cached view of a freshly migrated site. The lesson worth passing on: never trust one browser’s view of a fresh launch; check from vantage points that can’t share a cache.
The result, live in production, is a homepage plus nine inner pages on the new theme: lean and lightweight by design, with one hand-written stylesheet, two self-hosted font families, and no build step; fully client-editable from the standard dashboard; brand-safe; with documented accessibility improvements (WCAG AA contrast fixes, keyboard-accessible navigation and interactive components); clean, in-voice search descriptions on every page; and analytics plus the estimate form confirmed working in production.
The rebuilt homepage backs that up in Google Lighthouse: 100 Best Practices, 95 Accessibility, and 92 SEO, with 92 Performance on desktop. Those scores aren’t incidental: the 95 Accessibility reflects the contrast and keyboard-navigation work described above, and the 92 SEO reflects the clean, in-voice per-page descriptions and disciplined heading structure. (Mobile performance scores lower, the usual pattern for a photo-rich homepage, and it’s the area we keep tuning.)
What this means for your business
Planning a website refresh? If you want a site that’s fast, easy to update yourself, and fully in your own hands, that’s exactly what we build. 3PRIME does custom WordPress theme development that’s lean by construction and leaves the site fully in its owner’s control. And we use AI-assisted development the way it actually earns its keep: as a disciplined teammate inside a human-led process, operating in the real stack from first migration to final launch.
Thinking about a rebuild? Talk to us about what you’re working with.