By role · 4 tools
The web stack for a Head of Web
A Head of Web is accountable for a site other people change daily, so the stack is picked for control rather than speed. That means every change reviewed before it ships, content that outlives any one design, deploys that can be rolled back, and an assistant wired into all three.
What is a Head of Web actually accountable for?
You own a site that marketing, product and sales all want to change this week. Your problem is not building pages, it is making sure the twenty people touching the site cannot break it, and that you can prove what changed and put it back.
What should a Head of Web build the site on?
Four picks, each with the trade it makes. None of them is the right answer for every company, and a shortlist where everything is excellent is an advert.
Every change to the site is recorded and reviewed before a visitor sees it. When something breaks at 4pm you can see exactly what shipped and revert it.
Watch outIt only helps for the parts of the site that live in code. Content edited in a CMS bypasses it entirely, so the review discipline has to be set up twice.
The content lives in a database you control, so a pricing change does not need a developer and an export is never a support ticket.
Watch outYou are now running a piece of infrastructure. Somebody on your side owns updates, backups and the bill, which is the cost of not being on someone else's platform.
Every branch gets its own URL, so a stakeholder reviews the real page instead of a screenshot, and a bad deploy rolls back in one click.
Watch outUsage-based pricing means a traffic spike is also a bill spike. Worth knowing the ceiling before a campaign rather than after.
Pages ship as plain HTML by default, which keeps the marketing site fast without anyone having to defend a performance budget in a meeting.
Watch outIt expects someone comfortable in code. If your team is marketers only, this is the pick that creates a dependency on a developer without announcing it.
What can a Head of Web hand to an assistant?
Each of these is one file you paste once, and then the job runs the same way every time.
Which tools should a Head of Web connect to their assistant?
Connecting these means asking a question about the real site instead of copying screenshots into a chat window.
Questions people in this role ask
Taken from what people actually ask about this, not written to fill the page.
Who should own the company website, marketing or engineering?
Whoever holds the budget usually owns the strategy, but the working answer is simpler. If every change needs engineering to deploy it, engineering owns the site whatever the org chart says. The arrangement worth aiming for is one named owner for standards and guardrails, with marketing able to publish inside them without raising a ticket.
How do I stop twenty people breaking the site?
Split the site into what people may change and what they may not. Content edits go through the CMS with a review step. Anything structural goes through code review and gets its own preview URL. The mistake is one process for both, which is either too slow for a headline change or too loose for a template.
Does version control help if the content lives in a CMS?
Not for the content. Git records changes to code, so a CMS edit bypasses it entirely and will not appear in any history you can revert. That is why the review discipline has to be set up twice, once in the repository and once in the CMS, and why knowing which system a change lives in matters.
Webflow or headless for a team that edits every day?
Webflow when editing is the priority and the site stands alone. Headless when the content also feeds a product or several markets and there is engineering capacity to connect it. Daily editing does not decide this by itself, because both handle it. What decides it is whether the content has a second destination.
Not your job?
Every tool named here has a full entry in the stack, with the verdict and what it costs you.