The Cost Usually Moves Somewhere Else#

A website builder replaces money with a mixture of time and constraints.

There is time spent choosing a theme, resizing images, working around the editor, connecting a domain, and discovering which useful feature belongs to the next pricing tier. None of these jobs is especially difficult on its own. Together, they have a habit of filling an afternoon.

That may be a perfectly good use of an afternoon. I have spent longer on less useful things. But it is still worth noticing, particularly when the site belongs to a business and the person building it has other work to do.

The relevant question is not simply, “Can I make this myself?” It is whether making it yourself is how you want to spend the time.

The Limits Usually Appear Later#

No-code tools are convenient because they make a large number of decisions on your behalf. Hosting, templates, content editing, forms, and deployment all arrive in one box.

That box has edges.

You may eventually want a layout the editor does not quite support, a faster page, cleaner markup, a particular integration, or a way to move the content somewhere else. The feature might be possible with a plugin or an upgrade. It might also be impossible without rebuilding the site.

This is not a flaw unique to website builders. Every technical choice creates constraints. A custom site has plenty of its own, including the rather important question of who maintains it. The difference is that the constraints of a free platform tend to appear later, after the convenient beginning.

Maintenance Does Not Disappear#

It is easy to think of a website as something that gets finished. Most of them are closer to small, quiet pieces of software.

Links break. Business details change. Dependencies need updates. Contact forms attract spam. Domains expire with impressive punctuality. If the site uses a content management system and several plugins, those parts also need attention.

A hosted builder handles some of this work, which is one of its genuine advantages. A self-hosted system gives you more control but leaves more of the upkeep with you. A custom static site can have fewer moving parts, although someone still needs to understand how it is built and deployed.

There is no maintenance-free option. There are only different places for the maintenance to live.

Sometimes Free Is Still the Sensible Answer#

None of this means every website needs a developer.

If you are testing an idea, making a simple event page, or putting together a small personal site, starting with a free tool is sensible. You can learn what the site actually needs before spending much money on it. In many cases, the platform’s limits will never matter.

The trade-offs start to matter more when the website becomes part of how a business operates. If it needs to be fast, accessible, easy to find, connected to other systems, or dependable enough that nobody wants to think about it on a Monday morning, the cheapest starting price becomes less useful as a measure.

At that point, paying for a suitable platform or for someone to build and maintain the site is not automatically better. Sometimes you are simply paying to save time, get more flexibility, or make the problem someone else’s responsibility.

A More Useful Question#

I no longer think “Should a website be free?” is a particularly helpful question.

I would ask what the website is for, how long it is likely to exist, what happens if it stops working, and who wants to look after it. Those answers usually make it much easier to decide what is worth spending.

A free website is not secretly bad, and an expensive one is not automatically good. The price is only part of it.

Starting from an Empty Repository#

I first created an empty repository on GitHub, then cloned it locally:

1
git clone https://github.com/YOU/YOUR-BLOG.git
2
cd YOUR-BLOG

Because the repository was empty, there was no main history to preserve. I created the clean template branch first:

1
git switch -c template

Then I added the source repository as upstream:

1
git remote add upstream https://github.com/AUTHOR/REPO.git

I only need to fetch from that remote. Disabling pushes adds a small guard against sending anything there by mistake:

1
git remote set-url --push upstream DISABLE

Now git remote -v should show something like this:

1
origin    https://github.com/YOU/YOUR-BLOG.git (fetch)
2
origin    https://github.com/YOU/YOUR-BLOG.git (push)
3
upstream  https://github.com/AUTHOR/REPO.git (fetch)
4
upstream  DISABLE (push)

Next, I fetched the upstream history and made template point to its default branch:

1
git fetch upstream
2
git reset --hard upstream/master

The upstream repository in this example uses master. If it uses main, the last command should be git reset --hard upstream/main instead.

There is no merge here. The local repository started empty, so template can simply begin at the same commit as upstream.

Creating the Working Branch#

With template in place, I created main from it:

1
git switch -c main

All personal changes belong on this branch.

I then pushed both branches to my own repository:

1
git push -u origin main
2
git push -u origin template

At this point, the branch roles are clear: template is the clean reference, while main is allowed to diverge.

Pulling Upstream Changes Later#

The update routine is:

1
git fetch upstream
2

3
git switch template
4
git reset --hard upstream/master
5

6
git switch main
7
git merge template
8

9
git push origin main
10
git push origin template

Using reset --hard on template is intentional. That branch should contain no personal work, so its job is to match upstream exactly.

It is still worth checking the current branch before running the reset:

1
git status --short --branch

If upstream has changed files that I also customised, the conflict happens when template is merged into main. That is where it belongs: the clean branch remains clean, and the decisions about my version stay on the working branch.

Why Keep the Extra Branch?#

It would be simpler to modify the template once and forget about upstream. For a small site, that may be entirely reasonable.

I kept the extra branch because it answers two useful questions:

• What did the original project change?
• What did I change on top of it?

The branch does not remove merge conflicts, but it makes their source much easier to understand.

A little structure now is cheaper than trying to remember the history six months later.

A Personal Site, Not a Product Page#

The old versions of my site were always trying to explain me quickly.

There would be a headline, a list of technologies, a few carefully arranged projects, and some variation of the usual full-stack developer introduction. None of it was necessarily wrong, but it made the site feel finished before I had written anything on it.

That is not what I want from this version.

I want a small corner of the internet where I can keep notes, write about things I am building, and occasionally follow an idea that has nothing to do with software. It does not need a detailed content strategy. It just needs to be somewhere I am happy to publish.

The rough description is simple:

A developer’s personal corner of the internet — mostly software, occasionally everything else.

That leaves enough room for the site to change without requiring another identity crisis every six months.

Why Astro?#

I spend most of my working time building web applications, and I have worked with Angular for several years.

For a personal blog, though, I didn’t really want an application.

I wanted pages.

Astro fits that idea quite well. Most of this site is content, so static HTML is a sensible default. If a page needs something interactive later, I can add it without turning the whole site into a client-side application.

The basic model stays pleasantly small:

content goes in, HTML comes out.

There are plenty of good ways to build a blog. I chose Astro mostly because its defaults match what I want this site to be: simple, fast, and fairly boring.

I mean that as a compliment.

What I Plan to Write#

I do not have a publishing schedule or a long list of topics ready to go.

I will mostly write about software, things I am building, problems I have run into, and ideas that stayed in my head long enough to be worth writing down. Some posts will be technical. Some may not be.

A Small Beginning#

This is not a launch announcement or a promise that I will suddenly become consistent at blogging.

It is just the first note on a rebuilt site, and a reminder of what I wanted the site to be before I started adding too much to it.

For now, I am mostly happy to have a personal website that feels personal again.

Let’s see how long it takes before I rebuild it.