I started using Home Assistant because I was tired of managing separate apps for every device. One app for smart plugs, another for lights, another for the EV charger — and most of them depended on cloud services that would misbehave when the internet had problems.

I wanted one platform that could bring everything together and give me direct control, ideally without sending every action through someone else's server.

Home Assistant is an open-source home automation platform you run on your own hardware. It supports devices from different manufacturers and, depending on the integration, lets automations run locally without touching the internet.

What started as a home automation project has gradually become part of my home infrastructure. I now use it for lighting, smart plugs, climate control, energy monitoring, EV charging, CCTV monitoring across two countries, and keeping an eye on some of my home server services.

Here is how I use it and what I have learned along the way.

Why I Run Home Assistant on a Separate PC

There are different ways to run Home Assistant — as a virtual machine, in Docker, or installed directly on dedicated hardware as Home Assistant OS. I chose the last option.

Home Assistant runs on its own small PC, separate from my main server, which I call homeserver-1. My main server handles self-hosted services, databases, web apps, and background tasks. It occasionally needs maintenance, updates, or a restart, and I did not want any of that to affect basic home automation.

If homeserver-1 goes down for maintenance, the lights, sensors, and automations keep working. Keeping Home Assistant on its own machine makes this possible, and it also means I can experiment on the main server without worrying about disrupting the smart home.

The Home Assistant machine runs continuously on very little power. It sits quietly and does not need much attention once everything is configured.

How I Access Home Assistant Remotely

Most of my smart home devices communicate with Home Assistant over my local network. I also use Zigbee devices — motion sensors, contact sensors, and other battery-powered equipment — managed through Zigbee2MQTT with a Sonoff Zigbee 3.0 USB Dongle Plus V2. This keeps those devices off Wi-Fi and gives me a reliable, low-power mesh.

For remote access to Home Assistant, I use the Cloudflare Tunnel add-on. This connects to my own domain and lets me reach Home Assistant from anywhere through a web address, without opening any incoming ports on my home router.

I also run Tailscale on my network, but for a different purpose. Tailscale gives me a private encrypted mesh across all my devices — I use it for SSH access to homeserver-1, remote Samba file shares, and as an exit node when I am travelling. I use the Raspberry Pi in India as an exit node from the UK when I want access to Indian content, and the Home Assistant PC as an exit node when I am in India. Tailscale and the Cloudflare tunnel are separate layers that handle different things.

Using Home Assistant to Monitor My Home Server

Home Assistant is not only useful for controlling lights and switches. I also use it to keep an eye on parts of my home server infrastructure.

homeserver-1 runs several services, and rather than logging into the server separately each time, I want important information visible in one place. The setup uses MQTT — specifically Mosquitto, running as a Home Assistant add-on — as the messaging layer. Services on the server publish their state to Mosquitto, and Home Assistant subscribes and surfaces it on the dashboard.

Some of the things I monitor include: * CPU temperature and processor load * Memory and disk usage * Status of important services * Uptime and response times for web-facing services

I also use smart plugs as part of this setup. Beyond controlling individual devices, some plugs report energy consumption, which is useful for understanding how much power certain equipment is drawing.

The Notifications I Actually Need

One thing I learned early is that it is very easy to create too many notifications.

Initially it is tempting to send an alert for every state change. After a while, the phone fills up with messages that do not require any action. I now send notifications only when something genuinely needs attention.

Notifications go to my phone through the Home Assistant companion app. I have it set up on both my iPhone and Samsung S24, so alerts arrive as push notifications without needing a separate service in the middle.

The kinds of things worth notifying about: * Water leak detection * Security-related activity on the cameras * Server temperature problems * Important power events * Situations where I may need to take action remotely

Routine sensor state changes stay on the dashboard. A notification for every motion event or every temperature reading would be noise.

Automations I Use at Home

The most useful automations are usually the simplest ones. Here are some from my setup.

Automatic Lighting

I use motion sensors and lux readings to control lights around the house. The idea is straightforward — lights should only come on when someone is present and there is not enough natural light coming in.

Lighting behaviour also changes depending on the time of day. There is no reason for full brightness lights to trigger at 2am when a dim level is enough. The staircase lighting automation, for example, uses a combination of motion detection and a lux threshold to decide whether to turn on at all, and at what level.

Climate Control

Home Assistant can combine temperature sensors, occupancy information, and window sensors to manage heating more intelligently. If a window is left open while the heating is running, the system can pause heating in that zone after a short delay. This avoids wasting energy heating a room that is being ventilated.

Energy Monitoring and EV Charging

Energy monitoring is one of the more useful things I have built into Home Assistant. I have a Hypervolt EV charger integrated, along with the Octopus Energy integration for time-of-use tariff data. This makes it possible to see total household consumption, track EV charging sessions, and understand exactly when electricity is being used and at what rate.

Having all of this in one place, rather than split across multiple manufacturer apps, makes it much easier to act on.

Monitoring CCTV — UK and India

CCTV is one of the more involved parts of my Home Assistant setup, and it covers two locations.

UK Cameras with Frigate

At home in the UK I have four cameras — the TV room, backyard, front garage, and a general home camera. These run through Frigate, an AI-powered video analysis add-on for Home Assistant that runs locally on the HA machine.

Frigate does person and vehicle detection on the camera feeds in real time. When a person is detected in the backyard or at the front, it can trigger recordings, notifications, or other automations. All of the processing happens locally — nothing goes through a cloud detection service.

This is one of the parts of the setup I find most useful. Rather than dealing with constant motion-triggered noise, Frigate filters events down to actual people and vehicles, which makes the alerts much more actionable.

India CCTV via Hikvision DVR

I also have a Hikvision DVR at my family property in India, connected through Home Assistant here in the UK. This brings the India camera feeds and event sensors — line crossing detection, field detection, face detection — into the same dashboard I use for everything else.

Instead of managing the Indian installation through a separate app, I can see it alongside the UK cameras and home automation from one place. It is a good example of how Home Assistant can pull together systems in different locations without treating them as completely separate problems.

Things I Have Learned from Running Home Assistant

Home Assistant is flexible, but running it also means looking after the system. A few things worth paying attention to.

Database Growth

Home Assistant records state changes from all your sensors. On a larger installation with many sensors reporting frequently, the database grows quickly. My setup runs the recorder against a PostgreSQL database rather than the default SQLite — at this scale it handles the volume better and gives more control over retention and performance.

Regardless of which database you use, it is worth configuring the recorder to exclude sensors that do not need long-term history, and setting a sensible retention period. Letting every sensor record everything indefinitely will cost you disk space and slow down history queries.

Be Careful with Updates

I do not apply every Home Assistant update as soon as it is released. Before updating I check the release notes, look for any reported problems, and take a backup. This matters more when Home Assistant is controlling things the whole household relies on every day.

Having a recent backup also makes recovery much less stressful if an update causes a problem.

Zigbee Over Wi-Fi for Battery Devices

I prefer Zigbee for motion sensors, contact sensors, and other battery-powered devices rather than putting everything on Wi-Fi. The coordinator is a Sonoff Zigbee 3.0 USB Dongle Plus V2, and the devices are managed through Zigbee2MQTT. A well-configured Zigbee mesh is easier to expand and keeps battery-powered sensors off the Wi-Fi network, which matters when you have a lot of them.

Home Assistant Is More Than a Smart Home Controller

For me, Home Assistant has become one of the central parts of how my home infrastructure works. It handles everyday device control, energy and EV charging monitoring, camera detection across two countries, push notifications when something needs attention, and a view into what homeserver-1 is doing.

It is not a plug-and-play system. Getting integrations working takes time, some need occasional attention, and not every device supports fully local control. But having a single platform that brings all of this together is worth the effort.

I still add and improve things regularly. That is probably part of the appeal.

My setup: Home Assistant OS on a dedicated PC, with Zigbee2MQTT (Sonoff Zigbee 3.0 USB Dongle Plus V2), Frigate for local AI camera detection, Cloudflare Tunnel for remote access, Tailscale for private mesh networking, HA companion app push notifications, PostgreSQL for the recorder database, and integrations for home automation, EV charging, energy monitoring, and CCTV across the UK and India.

What Is Geotechnical Instrumentation and Monitoring?

When you excavate a deep basement in a city centre or construct a tunnel close to existing buildings, the surrounding ground can move. Even small movements can affect nearby structures, roads, railway lines and underground utilities.

You cannot simply assume that everything will behave as expected. You need to measure what is happening while construction is underway.

This is where geotechnical instrumentation and monitoring (GIM) comes in.

It is part of my day-to-day work at Sixense UK. My work involves infrastructure monitoring systems, instrumentation, telemetry and the management of the data collected from construction sites.

In simple terms, geotechnical monitoring helps engineers understand how the ground and surrounding structures behave during construction. It provides measurements that can be compared against design predictions and agreed project limits.

What Does Geotechnical Monitoring Actually Mean?

Geotechnical monitoring involves installing instruments in the ground, on retaining walls and on nearby structures to measure movement, pressure, loads and other physical changes.

Depending on the project, monitoring might include:

• Ground movement around an excavation
• Settlement of nearby buildings and roads
• Changes in groundwater pressure
• Movement of retaining walls
• Loads acting on temporary structural supports
• Movement and deformation of railway tracks

The instruments collect measurements at agreed intervals. These readings are then made available to engineers and construction teams through monitoring systems and software.

The important thing is not just collecting measurements. It is understanding what those measurements mean.

For example, if a retaining wall starts moving more than expected, engineers need to know whether this is within the predicted behaviour or whether something needs investigating.

Monitoring provides that information while construction is progressing, rather than waiting until visible damage appears.

The Sensors We Install in the Ground

Some of the most important monitoring instruments are installed below ground. Once construction progresses, these instruments may be difficult or impossible to access, so their installation and commissioning need careful planning.

Here are some commonly used instruments:

Inclinometers

Inclinometers measure lateral ground movement.

They are commonly installed in vertical boreholes using special grooved casing. Survey measurements taken inside the casing help establish how the ground is moving at different depths.

For automated monitoring, in-place inclinometer systems can be installed to collect readings without requiring someone to visit the instrument for every survey.

They are particularly useful around deep excavations, retaining walls and potentially unstable slopes.

Extensometers

Extensometers measure displacement between reference points or anchors installed at different positions.

For example, a multi-point extensometer installed below an excavation can help engineers understand how different ground layers are moving.

They can be used to monitor settlement, heave and other ground displacement, depending on their installation and orientation.

Piezometers

Piezometers measure pore water pressure within the ground.

Vibrating wire piezometers are commonly used in construction monitoring. Changes in pore water pressure can have a significant effect on soil behaviour and ground stability.

They are particularly important when working below the groundwater table or carrying out excavations where groundwater conditions need to be controlled.

Earth Pressure Cells, Strain Gauges and Load Cells

These instruments help engineers understand the forces acting on structures and temporary supports.

Earth pressure cells measure pressure acting on a surface, while strain gauges measure deformation in structural elements. Load cells measure forces acting on elements such as anchors, tiebacks and temporary steel props.

Together, these measurements help engineers compare actual structural behaviour against design expectations.

Monitoring Buildings, Roads and Railway Lines

Ground movement does not stop below the surface. It can affect nearby buildings, roads, bridges, utilities and railway infrastructure. For this reason, monitoring often extends beyond the excavation itself.

Automated Robotic Total Stations (ARTS)

Automated total stations are widely used to monitor the movement of surrounding structures.

The instruments are installed at carefully selected locations, ideally with a stable reference network, and automatically measure optical prisms fixed to buildings, retaining walls and other structures.

Using electronic distance and angular measurements, the system calculates the three-dimensional coordinates (X, Y and Z) of each prism. By comparing these coordinates over time, engineers can identify movement and settlement.

Depending on the monitoring arrangement, readings can be collected throughout the day and night without requiring a surveyor to visit every monitoring point.

However, automated survey systems still need regular maintenance, instrument checks and suitable environmental corrections. A clear line of sight and reliable reference points are also essential.

Railway Track Monitoring

Railway infrastructure requires particular attention when construction takes place nearby.

Monitoring can include track geometry surveys, precision track trolleys, automated survey measurements and wireless tilt sensors.

Measurements typically include:

• Track settlement
• Track cant and cross-level
• Track twist
• Changes in alignment
• Localised movement

The permitted movement limits depend on the railway infrastructure, the monitoring specification and the applicable railway requirements.

Even relatively small movements can be important, which is why monitoring data needs to be reviewed against project-specific limits.

The Real Challenge: Data and Telemetry

Installing instruments is one thing. Getting reliable readings from them throughout a construction project is another challenge altogether.

A large infrastructure project can have hundreds of monitoring instruments distributed across a wide area. Many of these instruments are connected to automated data loggers that collect readings at scheduled intervals.

The loggers then transmit the information to central monitoring systems, often using mobile networks or other wireless communication technologies.

Depending on the instrument and location, systems may use batteries, solar panels or external power supplies. This is where things can become difficult:

Communication problems

Underground structures, deep excavations and enclosed spaces can make wireless communication difficult. Mobile network coverage is not always reliable, particularly when instruments are installed below ground or behind concrete structures.

Power management

Remote loggers need a reliable power supply. Battery capacity, solar charging, transmission frequency and environmental conditions all affect how long a system can operate without maintenance.

Construction site conditions

Construction sites are not friendly environments for electronic equipment. Dust, cement, water, vibration and accidental damage from machinery can affect instruments, cables, loggers and solar panels.

A logger that was working perfectly yesterday might stop transmitting after nearby construction activities.

Missing or unreliable readings

A communication failure does not necessarily mean that an instrument has stopped measuring. Sometimes the logger continues collecting data but cannot transmit it.

In other cases, the instrument itself may have developed a problem. Understanding the difference is important when investigating missing readings or unexpected changes.

This is why monitoring does not finish when the instruments are installed. The telemetry network needs regular checks, maintenance and attention throughout the construction period.

Turning Raw Readings into Useful Information

Collecting measurements is only part of the job. Engineers need to understand what the readings mean.

Monitoring data can be affected by several factors, including temperature, environmental conditions, instrument behaviour and construction activities.

For example, steel structural elements can expand when temperatures rise and contract when temperatures fall. This can create regular changes in strain or load measurements throughout the day.

If these effects are not understood, engineers might interpret normal environmental changes as actual structural movement. This is where data validation and engineering interpretation become important.

At Sixense, automated and manual monitoring readings can be brought together through our Beyond Monitoring platform. The platform provides a central place to review monitoring information, examine trends and compare measurements against agreed project limits.

Projects commonly use a traffic-light system to communicate monitoring status:

• Green: Readings are within normal operating limits.
• Amber: An agreed warning threshold has been reached and requires investigation or engineering review.
• Red: An agreed action threshold has been reached and requires an immediate response from the project team.

The exact response depends on the project, its monitoring requirements and the procedures agreed by the organisations involved.

Automated alerts can also be configured to notify the relevant people by email or SMS when readings cross specified thresholds.

The important point is that an alert is not a replacement for engineering judgement. Someone still needs to understand the reading, check the circumstances and decide what action is appropriate.

Field Lessons: Why Reliable Data Matters

Working with instrumentation and monitoring systems has taught me that collecting data is not necessarily the difficult part. Making sure that the data is reliable and available when people need it is often the bigger challenge.

Consider a simple example: an automated total station reports that a building prism has moved by several millimetres. Before drawing any conclusions, someone needs to consider whether the prism has been disturbed, whether the instrument reference points are stable, whether environmental conditions have affected the measurements and whether the change is consistent with other monitoring points.

The same applies to underground instruments and telemetry systems. A missing reading, an unusual measurement or a sudden change in a data trend needs investigation.

On a major infrastructure project, monitoring information is used by different teams to make decisions. Engineers, surveyors, construction managers and monitoring specialists all need access to information they can trust.

That is why I see geotechnical monitoring as more than installing sensors and collecting numbers. It is about connecting instruments, communication networks, software and engineering knowledge to provide a reliable picture of what is happening on site. And that is what makes the data side of this industry just as important as the instruments themselves.

Technical Standards and Further Reading

For anyone interested in learning more about geotechnical instrumentation and monitoring, these are useful starting points: - BS EN ISO 18674: Geotechnical investigation and testing – Geotechnical monitoring by field instrumentation. This is a series of standards covering general monitoring principles and different types of instrumentation. - CIRIA C760: Guidance on embedded retaining wall design. Includes guidance on retaining wall design, construction, monitoring and the Observational Method. - British Geotechnical Association (BGA): A useful source of geotechnical engineering publications, technical guidance and industry information.

Geotechnical monitoring brings together civil engineering, instrumentation, surveying, telecommunications and data management. It is an important part of making sure that construction work behaves as expected and that surrounding infrastructure remains safe throughout the process.

The Raspberry Pi That Lives in India

Building a remote home setup between the UK and India, with a little help from Claude.

I live in the UK, but I still have a home in India. Being thousands of kilometres away means I can't just walk over to a device, check a cable or restart something whenever there's a problem.

That's one of the reasons I decided to build a setup around a Raspberry Pi.

It's a Raspberry Pi 5 with 2GB of RAM, a 500GB NVMe drive and Raspberry Pi OS Lite. It sits at my home in India and runs around the clock.

There's nothing particularly impressive about the hardware itself. But over the past few months, I've turned it into a useful part of my home network, helping me stay connected to India while managing other systems from the UK.

The interesting part isn't just what the Pi does. It's how I built the setup, the problems I ran into along the way, and how Claude helped me work through them.

What I Wanted to Achieve

I wanted a reliable way to connect to my home network in India, monitor services running in the UK and access my CCTV system remotely.

I also wanted to avoid unnecessary complexity. There was no point streaming several cameras across the internet all day when I only needed the video occasionally.

The plan was to let each device do what it was good at. The Raspberry Pi would handle networking and a few background services, the CCTV recorder would manage detection locally, and Home Assistant in the UK would handle the automation side.

It sounds straightforward when written down like that. Getting all the pieces to work together took a little more effort.

How Everything Fits Together

The Raspberry Pi is the always-on machine at the India end. Tailscale connects my devices across the two locations, giving me secure remote access without having to expose every device directly to the public internet.

The Pi also acts as a Tailscale exit node, allowing me to route internet traffic through India when needed. Subnet routing provides access to devices on the Indian home network.

At the UK end, Home Assistant runs on a separate PC. This is where the CCTV integration comes in.

My Hikvision DVR handles detection locally, including motion and human/vehicle detection, along with face capture. It sends ONVIF events to Home Assistant over the Tailscale connection.

The important thing here is that the DVR does the detection itself. I don't need to send five camera feeds to the UK continuously just to find out whether something has happened.

When I need to view a camera, the video can be pulled over RTSP on demand. This keeps the normal setup lighter on bandwidth while still allowing me to access the footage when needed.

It suits my situation quite well. The cameras and recorder stay in India, while Home Assistant can receive events and use them for automations in the UK.

A Few More Jobs for the Pi

The CCTV connection is only part of the setup.

I've also configured AdGuard Home to filter unwanted advertising and tracking domains through DNS. Unbound sits behind it as a recursive resolver, looking up DNS records through the hierarchy rather than relying entirely on a third-party DNS resolver.

The configured DNS chain works with Tailscale, AdGuard Home and Unbound together. Getting that arrangement right took some troubleshooting, particularly when dealing with connectivity and resolver timeouts.

There are a few other tools running on the Pi as well.

Cockpit provides a web interface for system administration, Glances lets me check resource usage, and log2ram helps reduce routine log writes to the storage drive.

I can keep an eye on CPU usage, memory, storage, temperature and network activity without needing to connect a monitor to the Pi.

Most of the time, the resource usage is low. That's one of the advantages of using a small computer for jobs like these.

It Took a Few Months to Get Here

This wasn't a project I finished in a weekend. It developed gradually as I worked through the network configuration and tested different parts of the setup.

Back in early June, I started with a pre-move audit. I checked DNS, reviewed the firewall configuration, tested the Tailscale connection to Home Assistant and looked into internet connectivity options for India.

One of those tests recorded latency of around 11.7 ms to Home Assistant. It was a useful early result, although it was only a snapshot of the connection at that time.

By July, I'd settled on the approach for the CCTV integration. The DVR would detect events locally, Home Assistant would receive ONVIF notifications, and RTSP video would be accessed only when required.

In early August, I got the Pi back online in India and restored the DNS setup. A few days later, I worked through the network configuration during a live session and changed the subnet to 192.168.2.0/24. That resolved the addressing issue and made the DVR reachable again.

By late August, just before I returned to the UK, the setup had developed into a working combination of remote access, subnet routing, DNS services and CCTV integration, with motion and human/vehicle filtering configured.

Looking back, much of the work wasn't about installing software. It was about getting the different pieces to communicate properly.

Working Through Problems With Claude

I used Claude as a pair-debugging partner throughout much of this project.

We worked through the architecture in conversation, including the Tailscale setup, the ONVIF event flow, the on-demand video approach and the DNS chain.

Claude helped me work through the installation using step-by-step command-line instructions and web-interface guidance. I'd connect to the Pi over SSH, run a command and share the output. We'd then look at the result and decide what to try next.

Not everything worked first time.

We ran into a subnet conflict, a problem with the DVR's static IP configuration and a timeout involving AdGuard Home and 127.0.0.1.

Instead of guessing, we used the command output to narrow down the problems and work through them one at a time.

Claude also helped me think through hardware choices, including whether a 6mm lens would be suitable for the gate camera at a distance of around 15–20 metres.

One important point: Claude didn't have direct access to my Raspberry Pi, DVR or router. It couldn't make changes to those devices itself. I carried out the commands and configuration changes, then shared the results so we could continue troubleshooting.

The India session was handled remotely over the phone, with me coordinating the work on site.

For me, this was a useful way to approach a project with several interconnected parts. I could make a change, test it and understand what had happened before moving on.

When the Pi Went Offline

On the evening of 20 October, the Raspberry Pi suddenly disappeared from the network.

Remote access stopped working, and the monitoring services running on it became unavailable. For just under two hours, I couldn't reach the machine that helped connect my two locations.

Eventually, it came back online. The signs suggested that it had restarted, so a local power interruption was the most likely explanation. I couldn't confirm the exact cause from the UK.

The outage also exposed something I needed to improve in my monitoring dashboard.

Some indicators turned red even though the systems being monitored might still have been perfectly healthy. The Pi had disappeared, so it could no longer check them.

That made me think about the difference between a system that has actually failed and one whose status is unknown.

They're not the same thing, and the dashboard should make that clear.

I've been working towards a clearer distinction: red for a confirmed problem and grey when a system can't be checked.

It might seem like a small detail, but when you're managing equipment remotely, it matters. You need to know whether something has failed or whether you've simply lost visibility.

It also reminded me that the machine doing the monitoring can fail itself. If the monitor goes offline, an independent way of detecting that outage becomes important too.

What I've Learned

Building this setup has taught me that remote management involves more than getting everything working once.

You need to think about what happens when a connection drops, a device restarts or a service stops responding. You also need a way to diagnose the problem when you can't physically access the equipment.

Working through the project with Claude helped me break those problems into manageable steps. But the changes still had to be tested on the actual hardware, and the results mattered more than assumptions.

I've also learned that a small computer can do a lot when you give it a clear purpose. There's no need to run everything on one powerful machine when several simpler components can work together.

Final Thoughts

My Raspberry Pi spends most of its time quietly running in India, using very little of its available resources.

Yet it helps me connect to my home network, provides DNS services, monitors its own health and supports the connection between my CCTV system in India and Home Assistant in the UK.

It took a few months to bring everything together, and there are still things I can improve. The recent outage was a reminder that even a setup that works well most of the time needs a plan for when something goes wrong.

For now, I'm happy with how it's coming together.

I've got my Raspberry Pi in India, with Home Assistant and my Lenovo ThinkCentre Tiny home server in the UK. Each has its own job, and together they're becoming a useful part of my home setup.

It's taken quite a bit of planning, testing and troubleshooting to get everything working the way I wanted. There's still room for improvement, but that's part of the fun of running your own setup.

And with a little help from Claude along the way, it's been a good learning experience too.

AI Built It... But Can a Non-Developer Trust It?

While reading The Daily Telegraph over breakfast this morning, I came across an article called “Anyone’s Domain”, published on 21 October 2026. It discussed the risks of AI-generated software.

Most of the article focused on businesses using AI to build applications, but it got me thinking. How much of this applies to someone like me?

When people talk about the risks of AI writing code, they often mention large companies, customer data, security risks and compliance. These are all important concerns, especially when AI-generated code is used in systems that businesses rely on.

But I don't work for a software company.

My day job is in geotechnical instrumentation and data management. I work with telemetry, monitoring systems, sensors and data used in major civil engineering projects.

So, where does AI fit into my world?

Becoming a Developer Without Planning To

A few years ago, if I wanted to build a custom tool, dashboard or website feature, I had two choices. I could spend weeks learning how to code, or I could forget the idea and move on.

Things are very different now.

I regularly use tools like Claude, Gemini, GitHub Copilot and ChatGPT to build things I probably wouldn't have attempted a few years ago.

For example, I use AI to help me:

• Write Python scripts to process PDFs and Excel files.
• Work with SQL databases to query and check telemetry data.
• Build small web applications using HTML, CSS and JavaScript.
• Create automations using Power Automate and VBA.
• Find and fix coding problems without spending hours searching online.

AI doesn't magically do everything for me. I still need to explain what I want, test the results and work through problems when things go wrong.

The biggest difference is that I can now turn an idea into something that actually works, without having to learn everything from scratch first.

The Problem With Trusting AI

For someone like me, the biggest risk isn't necessarily a major security breach or a business-critical system failing.

It's believing that the AI knows what it's doing when it doesn't.

If you've used AI to write code, you'll probably recognise this experience.

1. You explain what you want.
2. The AI writes the code.
3. Everything looks professional.
4. The explanation sounds convincing.
5. You run it, and something breaks.

Sometimes the problem is easy to spot. Other times, you can spend hours trying to work out what's wrong.

Perhaps the AI has used a function that doesn't exist, suggested an outdated library or simply got the logic wrong.

The frustrating part is that the answer can look completely correct until you actually try it.

AI is very good at sounding confident. Unfortunately, confidence doesn't guarantee correctness.

That's something worth remembering whenever you're using it to build anything.

Sometimes, You End Up Arguing With It

There's another side to working with AI that I don't think gets enough attention.

Sometimes, it's genuinely frustrating.

You can spend several prompts explaining your requirements, discussing different approaches and finally agreeing on how something should work.

Then, halfway through, the AI decides to take a completely different approach.

I'll look at the result and think:

What are you doing? We literally just discussed this.

At that point, my reaction is somewhere between laughing and wanting to throw my laptop out of the nearest window.

There have definitely been moments when I've stared at the screen thinking:

Honestly, I'm going to kill you.

Of course, a few seconds later, I remember it's not a person. It's a machine generating an answer based on the information it has.

So I take a breath and tell it:

No, not that way. Do it this way instead.

Usually, we eventually get back on track.

That's one of the strange things about using AI. The conversation feels natural enough that you start treating it like a colleague. But it doesn't understand the discussion in quite the same way a human does.

Sometimes it follows your instructions perfectly. Other times, it confidently changes things you never asked it to change.

Working with AI has taught me a little more patience.

And occasionally, a few new swear words.

Trust It, But Check Its Work

Over time, I've developed a simple rule:

AI writes the first draft. I'm responsible for the final result.

Whenever I build a script, automation or website feature, I try to follow a few basic steps:

• Read through the code rather than blindly accepting it.
• Test everything locally before putting it on a live server.
• Ask the AI to review its work and look for possible problems.
• Check what happens when something goes wrong, not just when everything works.
• Make sure I understand what the important parts of the code actually do.

I don't always understand every line straight away, and that's part of the learning process. I can ask questions, work through the explanation and test things until they make sense.

But there's one rule I try to stick to.

If I can't understand what a piece of code is doing, I shouldn't be rushing to put it on my server.

That doesn't mean I need to become an expert programmer. It means I need to understand enough to recognise problems, ask sensible questions and know when something needs a closer look.

Why This Matters

One of the best things about AI is that it allows people to build tools around the work they already understand.

A geotechnical engineer can automate data processing.

A photographer can build a portfolio website.

A project manager can create a reporting dashboard.

Someone running a home server can automate backups, monitoring and other routine tasks.

None of these people needs to become a professional software developer overnight.

They already understand the problems they want to solve. AI can help them bridge the gap between that knowledge and the technical skills needed to build a solution.

Of course, the more important the application, the more careful the testing needs to be. A small personal script is very different from software controlling critical infrastructure.

But for everyday projects, the possibilities are enormous.

Things I've Actually Built With AI

This isn't just theoretical for me. I've used AI to work on real projects, including things I probably wouldn't have attempted a few years ago.

B26 Sheldon: Building a Local Website

One example is my B26 Sheldon website, which focuses on local news, updates and information for the Sheldon community.

Building and managing a website involves more than writing articles. There's the technical side, the structure of the site and all the little things that need fixing along the way.

AI has helped me tackle parts of that work without having to become a professional web developer first.

It's also given me the opportunity to work on something useful for the local community. Instead of simply having an idea for a local website, I can develop it, make changes and keep improving it as I go.

Home Servers and Self-Hosting

I've also been working on home server and self-hosting projects.

These involve setting things up, troubleshooting problems and figuring out how different parts of a system work together.

Sometimes things go smoothly. Other times, I end up going back and forth with AI trying to work out why something that should work simply doesn't.

It's a good example of how AI can help you learn while doing something practical. Rather than spending hours searching through documentation before getting started, I can ask questions, try a solution and learn from the result.

Of course, I still need to check what the AI suggests, especially when changes could affect a running service or the security of my server.

Camini: From an Idea to a Published App

Then there's Camini, an app I developed and published on the Google Play Store.

That was a different kind of experience. It wasn't just about getting code to work; it was about taking an idea and turning it into an actual product that people could download.

I no longer actively support Camini. It was a niche product in a market where much larger companies offered similar solutions, making it difficult to justify continuing to develop it.

But I don't see that experience as a waste of time.

Building and publishing an app taught me something important: getting a product built is only one part of the challenge. Finding your place in the market, standing out from established competitors and deciding whether a project is worth continuing are just as important.

AI can help you build a product, but it can't guarantee that people will use it or that it will succeed commercially.

Sometimes, you have to recognise when it's time to move on. That's part of building things, too.

What These Projects Have Taught Me

Each of these projects has given me a different experience.

B26 Sheldon is an ongoing website project. My home server gives me plenty of opportunities to learn through trial and error. Camini gave me experience of taking an idea all the way to an app published on a major platform.

None of this means AI did everything for me. I still had to make decisions, work through problems and learn along the way.

But without AI, some of these projects might never have moved beyond the idea stage.

And that's what makes it so useful. It gives you the opportunity to try things you might otherwise have considered beyond your reach.

Turning Ideas Into Real Projects

I think this is where AI really makes a difference.

Over the past year, I've worked on things that probably wouldn't exist without it.

Not because they were impossible to build before, but because I wouldn't have had the time to learn everything needed to get started.

Some of the tools and projects I've worked on began with a simple question:

I wonder if I can build something that does this?

In the past, that question might have led to a few Google searches before the idea ended up on a list of things to try someday.

Now, I can often have a working prototype in an evening.

It might not be perfect, and it will probably need a few rounds of testing and fixing. But at least I have something to work with.

That is a big change.

AI gives me the freedom to experiment, learn as I go and try things that would previously have been outside my skill set.

For me, that's one of its biggest advantages. It doesn't remove the need to learn. It makes learning and building much more accessible.

So, Can a Non-Developer Trust AI?

My answer is yes, but not blindly.

AI is a useful assistant, a patient tutor and, at times, a very capable junior developer. It can save hours of work and help turn ideas into real projects.

But it can also make mistakes, overlook important details and confidently suggest solutions that don't work.

And it won't take responsibility if something goes wrong.

That's why I think the real skill isn't simply getting AI to write code. It's learning how to check the results, question its decisions and understand enough about what you're building to make sensible choices.

You don't have to know everything before you start. But you do need to be willing to learn, test and take responsibility for the finished product.

For me, that's the real value of AI. It's not about replacing knowledge or pretending that everyone is now a professional developer.

It's about giving curious people the opportunity to build things they might never have attempted otherwise.

And when the AI ignores everything we've discussed and decides to do its own thing?

Well, I suppose that's just another debugging session.

Inspired by “Anyone's Domain”, published in The Daily Telegraph on 21 October 2026.

I Stopped Paying for Web Hosting — Here's My Home Server Setup

For years, I did what most people do when starting a website: I paid for web hosting.

I've used Bluehost, Hostinger and a few other providers over the years. They all seemed reasonably priced at first, but then the renewal emails arrived. Suddenly, what looked like a bargain was costing two or three times as much as I expected.

At one point, I was paying for multiple hosting services at the same time because different projects were running in different places.

Eventually, I added everything up and realised I was spending a frankly silly amount of money every year just to keep a few websites online.

So I decided to do something different. I cancelled my hosting subscriptions and moved everything I could to a small refurbished PC sitting in a corner of my house.

Today, that little machine runs my website, a couple of other projects and a Jellyfin server for the TV.

The entire setup was built with a lot of help from Claude. Since I already pay for that subscription, I could use it to help develop and troubleshoot the system without hiring a developer for the initial build.

Here's how it all works.

The Hardware: A Refurbished Lenovo ThinkCentre

The heart of the setup is a refurbished Lenovo ThinkCentre Tiny M910q that I picked up on eBay.

It's roughly the size of a hardback book, doesn't take up much space and is more than powerful enough for what I need.

The specifications are fairly modest:

• Processor: Intel Core i5, 7th generation
• Memory: 16GB RAM
• System drive: 256GB SSD running Debian
• Storage: 2TB external drive for backups, photos, videos and other files
• Operating system: Debian 13, running headless

Running headless simply means there's no monitor or keyboard permanently connected. Once everything is configured, I can manage the machine remotely.

Despite its age, the ThinkCentre handles the workload comfortably. It hosts this website, a couple of smaller projects and my Jellyfin media server.

For my current needs, there's no reason to invest in an expensive dedicated server.

Why I Chose a Static Website

One of the things I've learned is that not every website needs a database or a full content management system such as WordPress.

The public-facing part of this website is static. It serves HTML, CSS, images and other supporting files through nginx, without requiring a database for visitors to browse the content.

That has several advantages:

• Fewer components to maintain.
• No WordPress plugins or database to manage for the public website.
• A lightweight setup that runs comfortably on modest hardware.
• Straightforward deployment and version control.
• A smaller attack surface than a more complicated installation, provided the rest of the system is secured properly.

Static websites aren't suitable for every project, but they work well for blogs and many smaller websites.

There's also an important distinction in my setup: although the public website is static, I've built a small custom admin application to make publishing easier. More on that below.

Getting the Website Online with Cloudflare Tunnel

Running a website at home is one thing. Making it accessible to everyone on the internet without unnecessarily exposing my home network is another.

Initially, the idea of exposing a server in my house to the public internet made me a little nervous.

Instead of opening ports on my router, I decided to use Cloudflare Tunnel.

The tunnel allows my server to establish an outbound connection to Cloudflare. Visitors can then access the website through my domain without requiring me to expose an inbound web port on my home router.

This means I don't need traditional port forwarding for the website, and I can keep my home IP address out of the website's public DNS records when everything is configured correctly.

It's a practical solution for home hosting, particularly when you don't want to manage incoming connections directly.

Of course, Cloudflare Tunnel isn't a magic security shield. The server, admin application and any other exposed services still need secure configuration, regular updates and proper authentication.

Getting everything working wasn't completely smooth, either. There was plenty of reading documentation, changing configurations, troubleshooting errors and wondering why something worked perfectly one minute and not at all the next.

That's probably the real cost of self-hosting.

You save money, but you're now the IT department.

Building a Simple CMS with AI

Originally, I was editing website files directly on the server whenever I wanted to publish something.

That became annoying very quickly.

I wanted a simpler way to write articles, upload images and publish content without manually editing files every time.

So I used Claude to help me build a simple custom content management system.

It's deliberately basic. The admin page uses passwordless authentication, sending me a login code by email. Once authenticated, I can write a post, upload images, preview the content and publish it without working directly on the server.

The public-facing website remains static, while the admin application handles the publishing workflow.

It's nowhere near as feature-rich as WordPress, but that's exactly the point. I don't need hundreds of features or plugins that I'll never use.

I need something that does a handful of things reliably.

AI made it possible for me to develop something tailored to my requirements without having to build everything from scratch or hire a developer for the initial implementation.

That doesn't mean the application is automatically secure or maintenance-free. Authentication, input validation, software updates and backups still matter. But it's been an interesting way to build a tool that fits the way I work.

Backups, Power Cuts and Reliability

Self-hosting means I can't blame a hosting provider's infrastructure every time something goes wrong. The responsibility for keeping things running sits with me.

That's why backups and recovery are important.

The website files and scripts are version controlled and synchronised elsewhere, while larger media files are stored on the external drive.

The important distinction is that version control and synchronisation aren't substitutes for a complete backup strategy. Important data needs independent copies, and those copies should be recoverable if the server or its storage fails.

Power outages are another consideration.

The ThinkCentre is configured to start automatically when power returns. Debian boots, the Cloudflare Tunnel service reconnects and the website becomes available again, assuming the internet connection and other required services are working.

That makes recovery from a straightforward power cut relatively painless.

It doesn't protect against every possible failure, of course. Hardware faults, internet outages and software problems can still take the website offline.

For a personal website, I'm comfortable with that trade-off. If the site disappears for a short period occasionally, it isn't the end of the world.

A business that depends on continuous availability might reasonably make a different choice.

What Does It Actually Cost?

One of the biggest reasons for making the switch was reducing recurring expenses. After paying for multiple hosting subscriptions over the years, I wanted something simpler and cheaper to maintain.

My current costs are surprisingly low.

The electricity figure is based on an average power draw of 6.9 watts, measured through Home Assistant while my server is running.

At that rate, the server consumes approximately 60.4 kWh of electricity per year.

I'm on Intelligent Octopus, with a day rate of 34.96p/kWh and an off-peak rate of 6.6p/kWh. Assuming six hours of off-peak electricity each night and 18 hours at the day rate, the estimated electricity cost works out at around £18.56 per year.

Adding my £12 annual domain renewal brings the combined cost to approximately £30.56 per year, or £2.55 per month.

These figures cover the domain and server electricity, not the initial hardware purchase, backup storage or the time spent maintaining everything. My home internet connection is also essential, but I already pay for it regardless of whether I host a website.

I also use Claude, which costs me £18 per month. It helped me build the custom CMS and troubleshoot the setup. However, I already subscribe to it for other work, so I treat it as an existing expense rather than an additional website hosting cost.

If I included the entire Claude subscription in the cost of running this website, the total would be higher. But the subscription isn't exclusively for hosting or maintaining the site, so I prefer to keep the two costs separate.

The real saving comes from no longer paying for multiple hosting subscriptions. I can run my website and other small projects on hardware I already own, without adding another monthly hosting bill every time I experiment with something new.

For my needs, that's a trade-off I'm happy with.

Is Self-Hosting Better Than Traditional Hosting?

Not necessarily. It depends on what you're building and how much responsibility you're willing to take on.

Traditional hosting gives you a service managed by someone else, although the level of support and maintenance depends on the plan you choose.

With self-hosting, you have much greater control over the hardware and software, but you also take responsibility for updates, security, backups, power and connectivity.

For a personal blog, a development project or a small website where occasional downtime is acceptable, a home server can be a sensible option.

For an online shop, a business-critical website or a service that must remain available around the clock, professional hosting may be worth the additional cost.

The savings only make sense if the setup meets your reliability and security requirements.

Was It Worth It?

Absolutely.

I wouldn't recommend self-hosting for everyone, and I don't think traditional hosting is a bad option. Managed hosting exists for good reasons, and not everyone wants to spend their evenings troubleshooting server configurations.

But for my requirements, moving to a home server has been worthwhile.

I've reduced my recurring hosting costs, learned a lot about Linux, nginx and networking, and ended up with a setup I understand because I've built and configured it myself.

The other benefit is flexibility. I can experiment with new projects, try different software and host additional services without having to rethink my hosting arrangements every time.

The next steps are to expand the photo gallery, upload some archived content and see how the custom CMS performs over the long term.

What started as an attempt to escape rising hosting fees has turned into a useful little home server that does much more than I originally planned.

And for now, I'm happy to let that refurbished ThinkCentre quietly get on with the job.