Building the Fern ICT Website: A Small Website, Deliberately Built

A website does not need to be complicated.

That sounds obvious, but it is surprisingly easy to build one that is.

There are content management systems, page builders, frameworks, hosting platforms, databases, plugins, analytics services and increasingly sophisticated tools that will generate software for you. It is possible to assemble an impressive technology stack for even the simplest website.

The fact that those technologies exist does not mean they are necessary.

For Fern ICT, the starting point was a much simpler question:

What does the website actually need to do?

It needs to explain what Fern ICT does, describe its services, publish technical writing, provide a useful way of navigating that material, work properly across devices, and be straightforward to maintain.

It does not need thousands of users, transactional functionality, a database-backed application or a complex publishing workflow.

So I chose to build it as a static site.

Start with the problem

This is a principle I apply to technical architecture generally.

It is very easy to start with technology rather than the problem. A particular framework is familiar, a particular CMS is widely used, or a particular cloud service makes something easy. Before long, the architecture starts to reflect the capabilities of the technology rather than the requirements of the system.

I prefer to start with the requirement.

For this website, the requirements led naturally towards static generation.

The source material is maintained as files. Pages and articles are written in Markdown. Metadata is held alongside the content. Templates define the common structure. A build process turns those inputs into HTML, CSS, images and other static assets.

The deployed website is therefore remarkably simple.

There is no database behind it.

There is no application server handling requests.

There is no CMS runtime.

There is simply a collection of files being served to visitors.

That is not technologically exciting.

It is, however, appropriate.

Simple does not mean simplistic

There is an important distinction between a simple architecture and an under-engineered one.

The website still has a build system. It deals with page metadata, article dates, categories, navigation, featured content, latest articles, the article archive, canonical URLs, the sitemap and other details that would otherwise have to be maintained manually.

The difference is where that complexity lives.

The build process does the work and produces a relatively simple deployed system.

That is a useful architectural property.

Complexity can exist in the process without becoming complexity in the runtime system.

There is no particular virtue in making a system complicated simply because it is possible to do so.

Why not use a CMS?

There is nothing inherently wrong with a content management system.

For many organisations, a CMS is exactly the right solution. If numerous people need to publish content, if editors require browser-based workflows, if content changes constantly, or if the website contains substantial application functionality, a CMS can make very good sense.

But infrastructure should have a reason to exist.

For this site, the content volume is relatively small and the person maintaining the technical infrastructure is comfortable working directly with source files.

A CMS would solve a problem that does not really exist.

It would also introduce problems of its own: software updates, dependencies, plugins, database state, security considerations and another layer of infrastructure to maintain.

None of those are necessarily difficult problems.

They are simply problems I don’t need to have.

Building from first principles

I deliberately chose not to begin with a pre-existing website framework and work backwards from its assumptions.

Instead, I built the relatively small amount of infrastructure the site actually needs.

There is a build script.

There are templates for the common elements of a page.

There is a small amount of CSS.

There is a content structure.

There is a manifest generated during the build which allows the site to derive things such as the featured article and the latest articles from the source content.

The individual pieces are not particularly complicated. More importantly, I understand how they fit together.

That matters to me.

One of the attractions of a small system is that it is possible to hold the whole architecture in your head. When something behaves unexpectedly, there are relatively few places to look.

That makes experimentation easier too.

The website became a useful engineering exercise

Although the site itself is small, building it provided a useful opportunity to apply some of the same principles that matter in much larger systems.

For example, the distinction between source data and generated output is explicit.

The Markdown files are the source of truth. The HTML is an artefact produced by the build.

The article index is not maintained separately from the articles. It is derived from their metadata.

Navigation is generated rather than copied into every page.

The site can therefore be rebuilt from its source rather than relying on manually maintained generated content.

These are fairly ordinary software engineering ideas.

They are nevertheless useful ones.

Where AI fitted into the process

AI was used extensively during the development of the site.

But that is not really the interesting part.

The interesting part is how it was used.

I used AI to accelerate exploration and implementation: discussing architectural options, generating and revising code, examining shell scripts, working through parsing problems, suggesting improvements, developing content and helping diagnose unexpected build output.

At times it was effectively another technical voice to bounce an idea off.

That was useful.

It made some parts of the process considerably faster.

But it did not remove the need to understand what was happening.

When a generated function produced the wrong result, the answer was not simply to accept the suggested correction. The manifest could be inspected. The generated HTML could be inspected. The build could be traced. The behaviour could be reproduced.

The actual system remained the thing that determined whether a solution worked.

AI is very good at being plausible

One of the things that becomes apparent when using AI for technical work is that plausible code is easy to produce.

Plausible is not the same as correct.

A shell command can look right while operating on the wrong field. A parsing expression can work for one input while failing for another. Generated HTML can look fine in isolation while producing an unexpected document when inserted into a template.

An AI system can also explain an incorrect answer very convincingly.

That is not a criticism of AI. It is simply a characteristic that has to be understood when using it.

The appropriate response is not to avoid the technology.

It is to maintain a feedback loop between the proposed solution and the actual system.

Write it.

Build it.

Inspect it.

Test it.

Question it.

Change it.

Build it again.

That process remains necessary whether the code was written by me, generated by AI, copied from a manual or produced by a team of developers.

The human judgement remains the important part

The architecture of the site was not decided by AI.

The decision to use a static architecture came from the requirements.

The decision about what Fern ICT should communicate came from the business.

The editorial direction came from the intended audience and from my own judgement about what is worth saying.

The technical decisions were made in the context of the actual system.

AI helped me get to implementations and alternatives faster. It also provided useful challenges to assumptions and helped investigate problems.

But at every meaningful decision point, somebody still had to decide whether the proposed answer was appropriate.

That distinction becomes increasingly important as AI becomes better at producing software.

The economics of software are changing

AI is making it considerably cheaper to experiment with software.

That is a significant change.

A developer can now explore several implementation approaches in the time that might previously have been spent implementing one. Documentation can be interrogated conversationally. Code can be transformed quickly. Errors can be investigated interactively.

The result is increased leverage.

But there is a corresponding danger.

When implementation becomes cheap, it becomes easier to build things that should never have been built.

It becomes easier to add another abstraction, another service, another integration or another layer because the effort involved in doing so is small.

The question therefore changes.

It becomes less about whether something can be built and more about whether it should be built.

That is an architectural question.

The website is deliberately boring

There is a temptation in technology to demonstrate sophistication through the technology itself.

This website does not really do that.

There is nothing particularly exotic about serving static HTML.

That is intentional.

The interesting question is not whether the technology is impressive. It is whether the solution is appropriate.

A good technical solution does not necessarily have the most features, the newest framework or the largest architecture.

Sometimes the best solution is the one that quietly does exactly what is required and very little else.

That is what I wanted from this website.

A small example of a larger philosophy

The Fern ICT website is a small system. The architectural decisions involved are obviously not comparable in complexity to designing a large distributed platform.

But the principles are the same.

Understand the requirement.

Make the constraints explicit.

Choose the architecture deliberately.

Avoid unnecessary dependencies.

Automate where automation provides genuine leverage.

Inspect the result.

And retain responsibility for the decisions.

AI has changed the economics of doing some of this work. It has made exploration and implementation considerably faster.

That is useful.

But speed is not the same thing as judgement.

The purpose of using AI in this project was not to remove the human from the engineering process. It was to make the human more effective within it.

And that, ultimately, is why the website was built this way.

It is a deliberately small system, built from first principles, using relatively simple technology and modern tools where they provide genuine leverage.

The technology is there to serve the objective.

Not the other way around.