Marketing Site Engineering

You’re a technical Head of Growth. You can read the code, you know what the landing page should do, and you have a list of changes that would move the numbers. But the site lives in Framer, so anything beyond a copy change means a custom component, a code override or an embed, and the moment it does, it needs an engineer.

So you put a ticket into engineering’s backlog and wait. But engineering is booked on the product roadmap, your ticket sits behind the features that ship revenue this quarter, and a quick change becomes six weeks. So you do it yourself inside Framer’s limits: a tag here, an embed there, a script pasted into the head of every page. But every workaround adds weight the page carries on every visit, and nobody owns the pile. The site gets slower, the tracking gets less trustworthy, and the next change is harder than the last.

So you make the case for a custom site. But the first question back is “who maintains it?”, and the honest answer is the same engineering team that had no time in the first place. The case dies in the meeting, and you stay where you are: paying for a tool that can’t do what you need, unable to leave it, patching around it, and slowly losing the argument that growth needs engineering at all.

Listing the pain doesn’t fix it. What fixes it is someone who lives and breathes marketing, engineering and product at the same time: one person who ports the site into code your team can change, makes it measurably faster, runs the growth experiments with you and maintains it afterwards. That’s the job I do, so the website stops being the liability the product team resents and becomes the asset growth actually owns.

The natural worry: “But what if I need to edit the site? Do we lose everything Framer let us do?” No. You get your own CMS, built around what your team actually changes: copy, pages, sections, images and the blog. Editing is a browser tab, not a pull request.

If your team wants the page-builder feel, that exists too. Craft.js and similar what-you-see-is-what-you-get tools give you drag-and-drop sections and inline editing on the live page. The Jenni AI rebuild has it: anyone signed in appends ?edit to a page and works in place, while visitors never download a byte of the editor. But most teams find they don’t need it, so we decide together whether it is worth building rather than assuming it.

The part that changes is where design happens. You design in Figma, the way you already do, and I build it to match. That is faster than fighting a builder into a layout it wasn’t designed for, and it leaves the site with one source of truth. I train the team on all of it: the CMS, the editor if you have one, the deploy flow and how to read the performance and search numbers, so the capability lives with you rather than with me.

A marketing site is a search asset first. Every page is server-rendered HTML with the title, description, canonical, structured data and social preview you decide, not what the builder’s SEO panel allows. The blog, tag and author pages come with sitemaps chunked to scale to tens of thousands of URLs, and every old URL redirects to its new home, so the move costs you nothing in rankings and usually earns some back.

Speed is a ranking signal and a conversion lever at once. Core Web Vitals are measured from real visits, so a site that ships two thirds less data and paints in a third of the time moves both the search result and the number of people who stay on it. But that only holds if it stays fast, so the performance budget is checked on every deploy rather than once at launch.

Then there is the part a builder cannot do at all: pages generated from data. Comparison pages, use-case pages, integration pages, one per row of a spreadsheet or a database table, with internal links between them that a crawler can follow. That is how a site grows from fifty pages to five thousand without anyone building five thousand pages.

The same applies to how fast you move. A landing page is a CMS entry. An experiment is a branch with a preview link, reviewed and shipped the same day. The content model is yours: relations, fields and collections shaped around your product rather than around the plan you are on, exportable and queryable. But a builder’s CMS is a tool you rent, so you stop being its tenant and start owning the asset.

Jenni AI, an AI writing product with a nine-thousand-post blog, ran its marketing site on Framer. On a simulated mid-range phone the homepage shipped 1.9 MB, made 125 requests and took thirteen and a half seconds to paint its largest element. So I rebuilt it in Next.js with a Payload CMS and inline editing, keeping the design pixel for pixel, and the clean build shipped 482 KB, painted in 3.6 seconds and scored 90.

But the site was never the whole problem. Putting the same twelve marketing scripts back, from Tag Manager and Cookiebot to Clarity, PostHog and Bing, ate most of the saving: 1.1 MB, 9.1 seconds, a score of 73. So I gated the optional tools behind consent and browser idle time and removed the page builder’s own analytics. The optimized site ships 622 KB and scores 79 on mobile and 99 on desktop, with every tool the growth team relies on still firing, and two thirds less data on arrival than the Framer original.