A personal brand site is a living document.

Business websites are brochures. Personal brand sites are chronicles.

A business website tells a stable story: who the company serves, what it sells, how to buy. The offer does not shift much. The about page does not shift much. The pricing might change once a year. The portfolio updates when a new project ships. Most business sites can sit untouched for months and still do their job.

A personal brand site works on a different clock. The writing pushes the voice somewhere new. The voice changes the positioning. The positioning changes the home page. The visual system tightens with every pass. Pages get rewritten, sections get cut, new ones get added as the operator learns in public.

The difference is not effort. Both kinds of sites are real work. The difference is the update cycle. Most business websites can survive on annual cycles. Personal brand sites that are still evolving usually cannot. That single difference changes how you should build the second one.

Most personal brand sites are built like business sites anyway. Designer or agency ships version one, hands it over, owner posts a few times, and six months later the brand has evolved past the site. The voice on the new posts does not match the voice on the about page. The visual system has shifted but the home page still uses the old palette. The site that started as a launch becomes a maintenance problem.

The fix is to build the site so the operator can update it on the same cycle as the writing.

This is not advice for every founder, freelancer, or creator. It is advice for the operator who treats the site as part of the writing practice, not just as a place to archive finished work.

Why I run a web design agency and built my own personal brand site myself

I run a small web design agency with my wife. We have been shipping websites for small businesses since 2013. The agency is the right call for the customer it serves: a small business owner who wants a professional website without learning the stack, with a clear scope, on a stable offer that will not change much over the next two or three years.

That customer is not me on this brand.

This brand is changing every week. The voice playbook from yesterday is not the voice playbook from today. The visual system that locked last month already has three small refinements in the queue. I have rewritten my about page four times since launching. I have changed the home page hero copy six times. The blog category labels have moved. The newsletter signup language has been tightened twice. None of that fits inside an agency engagement, even if my own agency was the agency in question.

If I had hired even my own team to ship this site, the loop would look like this. I email a change. Someone schedules it. Two days later the change is live. Then I see the change in context and want to revise it. I email another change. Two days later. By the time the third revision is live, I have two more I want to make. The site is always two or three iterations behind where my head is.

That works for a business client. The business client does not want to live inside the site. They want to ship it once, run their business, and let the site stay in the background. For personal brand work, the operator and the site cannot run on different clocks. The operator is not adjacent to the site. The operator is the source material.

So I built mine myself. Same person who writes the posts builds the layout. Same person who locks the visual system tightens the spacing. Same person who decides the voice updates the home page. The site keeps up because the operator is the only one in the loop.

Hiring is often right for stable business websites. DIY is often right for personal brand sites that are still evolving weekly. Different customers, different cycles, different builds.

The stack that supports a fast update loop

Three pieces. The choices are based on time-to-update, not on cost. Cost happens to be low because static sites are inexpensive to host. Cost is the side effect, not the reason. The cost you avoid in hosting, you pay back in comfort with files, git, and the occasional debugging session.

A static-site framework. I use Astro. Markdown files in a content collection become blog posts at build time. Layout components written once render every page. The framework generates plain HTML. There is no database, no admin panel, no logged-in users. The trade is that the site does not have a visual editor, which is fine for someone whose changes happen in markdown anyway. Other static frameworks (Eleventy, Hugo, Next.js in static mode) work on the same model.

Source control on GitHub. Every change goes through a git commit. The history of the site is the history of the brand. Past versions are recoverable. Branches let me try a layout change and discard it without affecting what is live. The repo is portable, which means the site is portable. If the host changes pricing in five years, the same code moves to a different host in an afternoon.

A static-site host with auto-deploy on push. I use Cloudflare Pages. When I push to the main branch, Cloudflare rebuilds the site and ships it. The deploy takes about thirty seconds. From the moment I save a markdown file to the moment it is live on the domain is under a minute. Other hosts (GitHub Pages, Netlify, Vercel) work the same way at the static-site tier. The point is the loop, not the brand.

What the loop actually looks like

Three concrete examples from this brand in the last month.

Voice rule update. I noticed my newer posts had a sentence rhythm I wanted to lock in across the whole site. I opened the writing rules file in my vault, the document where I keep my house style, added the rule, then went into the older blog posts and applied the rule where it fit. The whole pass took about an hour. By the end, every post on the site reflected the new rule. Pushed once. Live.

Newsletter signup language. The original CTA on the home page said one thing. After watching how readers responded, I rewrote it to be more honest about what the newsletter actually contains. Edited one component file. Pushed. Live in ninety seconds. The next visitor saw the new copy.

OG image regeneration. When I refined the visual system for blog post share images, I needed all twenty-six existing posts to get new OG images that matched. A Python script regenerated them in about ninety seconds. Pushed the new image files. Live in a minute. Twenty-six posts updated at once.

The pattern under all three: idea, edit, push, live. Minutes, not days.

The nine pages this site ships

The site currently ships nine intentional pages. Five are content: Home, About, Blog, Resources, Contact. Four are operational: Subscribe, Thank-you, Privacy, Disclaimer. The 404 exists too, but I do not count it because visitors only see it when something breaks.

The important part is not the number. It is the structure: one file per page, all under source control, all part of the same deploy loop. Most are .astro components. Blog posts are markdown files in a content collection. Privacy, Disclaimer, and Thank-you are simple components with mostly static copy.

Subscribe and Thank-you are paired with the email signup. Privacy and Disclaimer are legal hygiene. The five-page minimum I argue for in the methodology post is the floor for content. The four extra pages are the operational layer that comes with running a real site.

What this approach is good for and what it is not

The approach is good for a personal brand operator who is willing to work in markdown and use AI to write code when needed. It is good for someone whose site needs to keep up with their writing. It is good for someone who values ownership and portability over visual editing convenience.

It is not the right tool for several real situations. If multiple non-technical people need to draft, approve, schedule, and edit content inside a browser, use a CMS or a managed builder. If the site needs ecommerce, gated content, user accounts, or other logged-in functionality, the static base is not enough on its own. If a content team needs preview workflows, comment threads on drafts, or formal sign-off steps, this stack will fight you. Those are real needs and they deserve the right tool.

Put This Into Practice

If you are deciding how to build your own personal brand site, paste this into Claude or ChatGPT. The prompt is the decision conversation, not the code generation.

The point of the prompt is to land on the right path for your situation, not to push you toward DIY. Some people are better served by hiring. Some are better served by a managed platform. The static-site DIY path is right for a specific operator profile, not for everyone.

The cycle is the lesson

Pick the build approach that matches the update cycle of the thing you are building.

Stable products tolerate slower build cycles. Personal brand sites usually do not. The voice evolves, the visual system tightens, the writing keeps pushing somewhere new. The site has to keep up.

The agency model works beautifully for the customer it serves. The DIY model works beautifully for the customer it serves. The skill is matching the model to the customer. On a personal brand site, the customer is you.

Come build with me.

~ Anthony