Mark's Thoughts

From Bletchley to a nationwide AI community — and a vibe-coded website

markw@markwilson.co.uk (Mark Wilson) — Thu, 21 May 2026 00:00:00 +0100

From Bletchley to a nationwide AI community — and a vibe-coded website

I’m pretty stoked today because, after a very late night vibe coding session last night, I finally got the UK AI User Groups website to a state where I felt it was ready to go live. And, now the DNS changes have propagated, we are in business.

I’ve been involved in the Bletchley AI User Group from the sidelines for a while, but then my friend Phil Kermeen got involved and I became a regular attendee. After I was invited to speak last year, I suddenly found myself “voluntold” onto the committee. So, with strict instructions from my family not to take on yet more projects/responsibilities, I agreed to photograph the Bletchley events and create a website.

That escalated quickly.

I am not a web developer

OK, so, I’m not a web developer. I have a Computer Studies degree (so technically, “I can code”), but I haven’t written a line of code professionally since my internship in 1992/3 — except perhaps some MS-DOS batch files or a bit of bad PowerShell. I’ve had my own website since at least 1998 though, so dabbled in HTML/CSS, but mostly used WordPress (until I switched to Hugo earlier this year — that’s another story/post).

The point about the UK AI User Groups site is that I wanted to write something that:

is easy to maintain;
separates presentation from site logic and from data;
looks OK, using the group’s visual identity (I’m not a designer either);
feels “modern”;
is accessible and easy to navigate.

Cutting code

And this is where the vibe coding comes in…

I know some people will tell me there are better tools for coding, but I have a personal ChatGPT Plus subscription. That was enough for me to create a simple single-page site using HTML, CSS, and JavaScript. And then I got the memo that this was not just for Bletchley AI, but for all of the UK AI User Groups, adding a extra page for each group.

I used the W3.CSS framework with Font Awesome icons — in common with my own websites — and ChatGPT handled much of the app logic and presentation. Data (events) are read from a single file, and presented in various forms across the site.

There’s light and dark modes, and the site is responsive so it should gracefully adjust to different devices — though the best user experience is still in a desktop browser. I have my limitations (testing/access to devices and skill — as well as time).

A companion script pulls images from the actual event management platforms (currently Meetup and Luma) so we can bring the event cards on the site to life. And then, on the train home last night I decided to see if I could show the various groups as either a list or on a map — so Leaflet does all the heavy lifting for the maps, with the page offering a toggle between the two views.

Hosting it for free

Oh yes, and did I say this is free? Yep, hosted in a GitHub repository with CI/CD to push it to Azure Static Web Apps on the free tier.

The last challenge was the DNS setup for the custom domain — not difficult, but one of those tasks where everything feels slightly more complicated than it should because of the quirks of the GoDaddy domain registration.

So that’s it. It went live today. A vibe-coded website at https://www.ukaiusers.co.uk/

“Anyone can do that”

Now, some will be reading and saying “whoop-de-do Mark, anyone can do that” — and that’s my point. I’m not taking a professional developer’s work away — proper sites still need proper skills. Not just to write code but to perform proper analysis, design, creation, testing, and support. The code was never the whole job.

What generative AI (and just enough skill to be dangerous) has allowed me to do is create something functional, for a group with no budget for professional services (any sponsorship revenue goes to running the events). And it’s allowed me to exercise my inner geek.

And that’s where I see value in generative AI. Bouncing ideas around. Helping to draft content. Assisting people. And letting projects that would never get past the business case come to life.

The support question

Let’s discuss the elephant in the room though — support. A vibe-coded site is a bit of a black box. I understand enough to say “this is what I have created and this is how it works at a high level”. I don’t understand every line of JavaScript though, and the CSS had a lot of fixes applied to get it to behave properly.

I’ve no doubt that this could do with a complete refactor. Maybe I can use another AI assistant for that some time.

And that’s the main point I want to get across. Vibe coding is not magic. It doesn’t remove the need for skill, judgement or support. But it can lower the barrier enough for an idea to become real.

Sometimes that’s enough.

Especially when the alternative was another good idea sitting on the “maybe one day” pile.

The path to vCTO

markw@markwilson.co.uk (Mark Wilson) — Thu, 7 May 2026 00:00:00 +0100

I’m moving into a new role at Node4, as a vCTO (the “v” is for virtual).

It formalises the type of work I’ve found myself doing more of over time — working with clients to shape technology decisions, connect ambition to outcomes, and make sense of increasingly complex landscapes. The change of role adds increased focus (and accountability).

It’s also prompted me to look back at where that started.

A conversation at the wrong time

In May 2017, I pitched to the founding directors at risual and asked to be their CTO.

I understood what the role required. What I hadn’t fully grasped was the context we were operating in. 2017 was a difficult year, and any non-billable role was an overhead that had to be justified very carefully.

I was thinking with an enterprise mindset in a small to medium-sized business and, in doing so, showed that I wasn’t ready.

Becoming part of a larger organisation

When risual was acquired by Node4, we became part of a much larger organisation with an established CTO. One of the directors that I’d pitched to years earlier introduced me to him. He saw it as fulfilling a promise he had made — I’d never considered it a promise, but I did appreciate the recognition.

Ultimately, that led to a move into Node4’s Office of the CTO (OCTO), where I’ve spent the last three years.

The work has varied — as has the leadership of the function — but it has consistently involved working across technology, strategy, and customer engagement. It’s also drawn on earlier parts of my career, including time in the Fujitsu UK and Ireland OCTO, management experience from running a large technology practice, stepping back into solution and enterprise architecture, before leading a team of architects.

Individually, those roles were quite different. Together, they start to make more sense, and we’ll come back to my “red thread” in a moment.

What a vCTO does

The vCTO is not “the CTO”. As I wrote in a recent post, the CTO role itself varies widely depending on context. This is one of those variations. For me, in this role, it means:

Working with customers at a senior level to understand their goals, constraints, and priorities.
Shaping technology roadmaps that align to business outcomes.
Translating between business ambition and technical possibility.
Working closely with account teams and service delivery teams to make sure ideas turn into outcomes.
Building trusted relationships with customers and advocating for them within Node4.

It sits between strategy and delivery — close enough to execution to stay grounded, but focused on direction rather than implementation.

The red thread

There’s a red thread running through all of this:

Strategy Consultant -> Head of Practice -> Enterprise Architect -> Technology and Innovation Director -> vCTO.

Each of these roles has helped me develop new skills and experience, whilst building on what I already knew.

That 2017 conversation wasn’t wrong, but it was early (even if I didn’t think so at the time). What’s changed since then isn’t just experience. I knew I was becoming broader and shallower in my technology knowledge, but I’ve since realised I was also learning how technology leadership works.

And I’m still learning.

This move to a vCTO role feels like the right next step. Now I need to turn the theory into practice.

Invited in, then shown the door

markw@markwilson.co.uk (Mark Wilson) — Thu, 30 Apr 2026 00:00:00 +0100

Imagine being invited to an event. You accept, set aside the time, and arrive at the correct time. You’re welcomed in, find a seat, and things get underway. Then someone asks you to leave.

You explain that you were invited. They apologise, let you back in, and you sit down again. A few minutes later, you’re forceably removed. At that point it’s clear it’s not a misunderstanding. Someone has decided you shouldn’t be there, despite the invitation.

It would feel awkward — and rather unprofessional.

This actually happened

Last week, this actually happened to me.

A colleague and I were both contacted by a competitor and invited to a webinar they were running. We were completely open about who we worked for and there was no suggestion that this was an issue. In fact, they actively encouraged me to attend, suggesting there could be potential partnership opportunities.

We both signed up and, when the time came, we joined the event. As the speaker started the presentation, we were both removed from the meeting.

I assumed it was a glitch and rejoined. But the same thing happened again. After a couple more attempts it was clear this wasn’t technical. Someone was actively removing me.

Moving from a physical to a virtual context doesn’t really change the interaction. It just makes it easier to remove people without making a scene.

Where it goes wrong

Clearly there was a disconnect. The outreach team that cold-called me said “come along”, but the delivery team didn’t agree. That should have been resolved before the invitation was sent, not during the session. Or, if that wasn’t possible, a polite message to say there had been a mistake would have been acceptable — ideally before the event started.

It’s not hard to see how it happens. Outreach is often measured on registrations, so the focus is on getting people signed up. Moderation is dealing with a different concern entirely. It’s a good example of Goodhart’s Law — be careful what metrics you measure people on because they might not generate the desired outcome.

It’s not really a big deal — some time wasted, then looking up the appropriate contact to send a polite but firm email. But it’s an experience that I will remember (and tell people about — even if I’m not naming the company here). And our industry is remarkably small at times…

The quiet dystopia of modern work

markw@markwilson.co.uk (Mark Wilson) — Tue, 14 Apr 2026 00:00:00 +0100

Nineteen eighty-four was meant to be a warning. Not a playbook for how we design modern work.

There’s a particular kind of meeting that leaves you wondering why you were there at all.

I joined one this morning, hosted by a major technology company. Almost two-hundred people were on the call, and it started late — a particular bugbear of mine, especially when it wastes a huge amount of other people’s time and quietly signals that they can all wait for someone else who isn’t properly prepared. Chat and comments were disabled, cameras were off, and ten slides were presented in a tightly controlled format. Then the call ended. No questions. No discussion.

Everyone had been gathered together, but there was no real interaction. The whole thing could have been recorded and shared afterwards with no real loss. It might have been better received that way.

The content itself was fairly straightforward. It was clearly intended to guide partners in a particular direction and avoid problems further down the line. That part made sense. What didn’t land so well was the tone. It felt more like instruction than collaboration, with just enough polish to make it presentable.

We often joke that a meeting could have been an email. In this case, it probably should have been. Or a short video that people could watch in their own time. Instead, it became a good example of how easy it is for communication to drift into something performative, where the act of broadcasting matters more than whether anyone is actually engaged.

When communication becomes a product

That meeting was a minor irritation. But at least I don’t work for a Silicon Valley social media giant.

Mark Zuckerberg is in the news again – because Meta is reported to be building an AI version of its leader to “connect with employees”. I can see the thinking behind: large organisations struggle with scale; Leaders cannot be everywhere; and consistent communication is difficult to maintain.

So, instead of effective leadership and delegation the answer (if you think like a tech bro) becomes automation. Create something that looks and sounds like you, deliver the message, and maintain a presence across the organisation.

And Sharon O’Dea summed it up in her calmly-delivered but razor-sharp LinkedIn post with this fantastic line:

“[Marshall] McLuhan said the medium is the message. And the message here — beamed directly into the faces of Meta’s workforce in HD, with accurate lip-sync — is: you are not worth my time. Your relationship with leadership is now a content type. A deliverable. A thing that can be optimised and scaled and A/B tested like everything else.”
– Sharon O’Dea, April 2026.

When leadership can be rendered, replayed and optimised, it changes the nature of the relationship. It starts to feel transactional.

Scaling presence vs. replacing it

I use AI tools every day. Microsoft Copilot is becoming genuinely useful, particularly for research and identifying action items. I also use ChatGPT extensively for writing and problem solving. Used well, these tools remove friction and save me time.

But tools don’t replace being present.

If I ever suggest sending an AI version of myself to a meeting, it will be a fairly strong signal that something has gone wrong. The value is rarely in delivering a perfectly formed message. It sits in the interaction around it – the questions, the pushback, the moments where the conversation goes slightly off-script and something more useful emerges.

There’s also a slightly uncomfortable implication. If someone can swap me out for an AI in that situation without losing anything, it is worth asking what I was contributing in the first place.

A gradual shift in what’s acceptable as normal

None of this comes from bad intent. The meeting this morning was trying to create clarity. The AI avatar is an attempt to deal with scale and time.

In isolation, these may be sensible decisions. But something feels off. Communication becomes more one-way. Leadership becomes something that can be produced and reused. Presence becomes less important.

And it’s happening gradually, which is probably why it passes without much comment.

A small course correction

There is a simple test that helps cut through most of this.

If something doesn’t need to be a meeting, don’t make it one.
If communication is one-way, be clear about it rather than presenting it as a conversation.
If the answer to scale is to replace human interaction with an artificial version of it, it’s worth pausing to think about what is being lost.

It’s hard not to think of Orwell when this becomes the norm.

What does a CTO do? It depends — and that’s the point

markw@markwilson.co.uk (Mark Wilson) — Tue, 31 Mar 2026 00:00:00 +0100

Same title, different jobs

Ask ten people what a CTO (Chief Technology Officer) does and you will get ten confident answers. What’s interesting is that each answer is usually correct in its own context. In one organisation, the CTO runs engineering. In another, they shape product direction. In a third, they sit alongside the board and help make sense of technology choices. The title is consistent, but the role is anything but.

That variation can make the role feel vague from the outside but the shape of the job reflects the organisation around it. A startup trying to build something new needs a very different kind of CTO to a large enterprise trying to modernise decades of systems. A services business has different needs again, where credibility, narrative, and client engagement matter just as much as technical depth.

The common core

Despite that variation, there’s a common core. Strip away the organisational differences and the job usually comes down to three things: setting direction, making decisions, and developing leadership:

Direction is about ensuring there is a coherent technology roadmap that supports the business rather than competing with it.
Decisions are about navigating trade-offs that do not have neat answers — speed vs. resilience, standardisation vs. differentiation, build vs. buy.
Leadership is about creating the conditions for others to succeed.

This is where the role is often misunderstood. A CTO should not be the person with all the answers, or the most hands-on engineer in the room. The job is to help the organisation consistently arrive at better answers, and to turn individual pieces of work into something that adds up to a clear direction.

For a neutral definition of the role, MIT provides a useful overview of how CTO responsibilities typically span strategy, architecture, and innovation.

Turning technology into outcomes

Several years ago, I came across a line about the CIO (Chief Information Officer) that stuck with me. Gideon Kay observed on Twitter that:

“The mark of a strong CIO is the ability to turn a technology platform question into a business outcome answer.” — Gideon Kay (@gids), April 2017

That felt right, but I thought it could also work the other way round:

“The mark of a strong CTO is the ability to take a business problem and turn it into a technology solution.” — Mark Wilson, May 2017

Today, I would add that the solution needs to deliver something meaningful to the business — not a solution in isolation, but one that aligns to both business and technology strategies.

That distinction shifts the role away from technology for its own sake, and towards translation. The CTO sits between ambition and execution, helping ensure that what gets built is both technically sound and commercially relevant.

Why context matters

The reason the role varies so much comes down to a few factors. Stage is one:

Early-stage organisations are focused on building.
Growth-stage organisations are trying to scale.
More mature businesses are often optimising or modernising, while others are trying to reinvent themselves altogether.

Each of those requires a different emphasis.

The business model matters too, and a useful way to think about this is whether the organisation primarily builds technology or uses technology. A product company will expect its CTO to lean heavily into engineering, product development, and platform decisions. An organisation that is primarily a user of technology will lean more towards architecture, integration, and ensuring that technology choices support business outcomes. A services organisation often sits somewhere in the middle, with an added emphasis on client engagement and external credibility.

Add in the organisation’s risk profile — particularly in regulated industries — and the balance shifts again towards governance, resilience, and control.

CTO and CIO

This is also where the distinction between CTO and CIO often comes into play, although the boundaries are not always neat. A CIO is typically focused on internal systems and operations — keeping the organisation running and enabling people to do their jobs effectively. A CTO is more often outward-looking, concerned with how technology shapes products, services, and the organisation’s position in the market.

In practice, many organisations blur or combine these roles, which is fine as long as the underlying responsibilities are understood. Problems tend to arise when the ownership of strategic technology direction is unclear, regardless of what title is used.

There’s a useful article from McKinsey that explores how the two roles differ and where they overlap, along with a lot of advice on different approaches to the CTO role.

It’s also worth noting that both roles have evolved. There was a time when CIO was jokingly expanded as “career is over”, reflecting a perception of the role as operational and inward-looking. That is no longer true. The CIO role has shifted towards business leadership, just as the CTO role has broadened beyond pure technology.

A role that keeps being reinvented

A friend once advised me that I shouldn’t seek to become a CTO because it was a “dead job title”. The implication was that the role had either peaked or would be absorbed into something else.

Happily, it turned out that my friend was wrong and, if anything, the opposite is true. As organisations rely more heavily on technology, the need for clear technology leadership has increased.

That said, it’s worth being precise about the different titles that appear around it. A Chief Digital Officer, for example, is often focused on digital channels, customer experience, and business model change. There can be overlap with a CTO, but it’s not simply another flavour of the same role. Similarly, titles like Field CTO or Customer CTO tend to describe where the role operates — closer to customers, sales, or market engagement — rather than a fundamentally different purpose. You will also see the term vCTO (Virtual Chief Technology Officer), which can refer to the same strategic capability delivered on a fractional or shared basis.

There’s also a practical question about the word “Chief”. In theory, there should only be one Chief Technology Officer. In practice, that’s not always the case. As Matt Watts (himself, a former Field CTO) put it in a recent LinkedIn post, “how many CTOs do you have?” — pointing out that some organisations end up with dozens of CTO-titled roles, each with different scopes and levels of influence.

It might feel messy, but it reflects how the role has evolved. What matters is not the purity of the title, but whether the responsibilities are clear and whether someone is accountable for setting direction and making the key technology decisions.

The titles may shift slightly, and new variations appear, but the underlying need remains.

Why the CTO role matters

Most organisations are not short of technology activity. There are always projects, initiatives, and new tools being introduced. What is often missing is coherence. Without a clear direction and someone accountable for the decisions that shape it, work can become fragmented. Individual teams may make sensible choices in isolation, but those choices do not always add up to a clear strategy.

This is where the value of a CTO becomes visible. It isn’t about knowing the technology better than anyone else. It’s about helping the organisation make better decisions about how technology is used, and ensuring those decisions are aligned with what the business is trying to achieve.

You can usually tell when that role is missing, even if the title is not. Repeated debates about priorities, uncertainty about where to invest, and a sense that there are lots of initiatives but no clear direction are all indicators. In those situations, the organisation doesn’t necessarily need more projects or more tools: it needs clarity, ownership, and a way of turning activity into something coherent.

That, in essence, is what the CTO provides.

ABBA Voyage and the future of live performance

markw@markwilson.co.uk (Mark Wilson) — Sun, 22 Mar 2026 00:00:00 +0000

ABBA last performed in London in 1979.

And yet, yesterday afternoon, I was in an East London arena watching them perform. Except they weren’t really there.

ABBA Voyage is not a reunion tour. It’s a new form of live performance, built on a blend of digital production, physical staging, and carefully engineered illusion.

Many reviews focus on the music and the spectacle, but that’s only part of the story. As a technologist, what makes ABBA Voyage notable is not that it recreates a band, but that it challenges what we mean by a “live” performance.

A mixed reality performance, not a hologram

ABBA Voyage is often described as a hologram show. That’s convenient, but not really accurate. It’s not just a projection of flat images onto a stage, nor a simple visual trick. The show combines motion capture, visual effects, real-time rendering, and a physical stage environment. The digital performers, known as ABBAtars, were created by Industrial Light and Magic in collaboration with the band. The original members spent weeks in motion capture suits, effectively re-performing their younger selves.

Alongside that, there is a live band on stage. The music is real. The lighting is real. The environment is real. The result is a mixed reality performance where digital and physical elements are presented as one.

The illusion is engineered

What makes this work is not just the quality of the digital characters. It is how the entire experience is designed to guide perception.

Lighting plays a central role, shaping what you can see clearly and what you cannot. It directs your focus and, at times, deliberately hides the edges of the illusion. The live band anchors the experience, giving your brain something that is unquestionably real and making it easier to accept what you are seeing.

I spent a good part of the show trying to work out what was real and what was rendered. That lasted until a moment where the illusion did something that felt impossible. I won’t spoil it, but it was enough to make me exclaim “Wow!” out loud.

As Benny Andersson himself puts it:

“I think the only way to understand what this is you have to come and see it. It’s sort of non-explainable […] you need to go and see it.” — Benny Andersson, ABBA

Solving the uncanny valley problem

Digital humans often fall into what’s known as the uncanny valley. Close to real, but not quite right. The ABBAtars mostly avoid that.

Presenting ABBA as their 1970s selves helps. It removes the expectation of a perfect, present-day likeness and allows for a slightly stylised interpretation. More importantly, the performances feel human. Movement, timing, and interaction are convincing enough that you engage with them as performers rather than as effects.

That is what makes the illusion sustainable over an entire show, rather than just impressive for a few minutes.

Why this matters beyond ABBA

It would be easy to dismiss ABBA Voyage as a one-off built around a globally recognised band. I see it as a proof of concept for a different model of live entertainment.

Performances are no longer constrained by the physical presence of the artist. Shows can run continuously in a fixed location. The experience is consistent and repeatable. Performances can be preserved, recreated, or reimagined.

From a technology perspective, this is what happens when film production, game engine thinking, and live event design converge. The business model is just as interesting, built around a permanent venue and a long-running production rather than a touring schedule.

Culturally, it raises a simple question: what does “live” actually mean?

A brilliant show, built on something bigger

It is worth saying this clearly: ABBA Voyage is a brilliant show.

(It also messed with my head a little.)

The technology is impressive, but it never feels like the point. It serves the performance rather than distracting from it. The music, the energy, and the atmosphere all land exactly as you would want them to. Without that, none of the rest would matter.

There is also a personal thread running through it. ABBA were one of the few bands that worked across generations when I was growing up. They were a constant on car journeys, and I remember saving Christmas money to buy their albums. I was too young to see them live.

And yet, somehow, I now have.

Sort of.

Where this goes next

ABBA Voyage is unlikely to remain unique for long. The underlying technologies are already well understood. What is new is how they have been combined, refined, and delivered at scale.

It is easy to imagine what comes next. Legacy artists returning without touring. Performances running in multiple locations. New acts designing shows that blend digital and physical elements from the outset.

This does not replace traditional live music. It does something different. It trades spontaneity for precision, and physical presence for creative control.

Closing thoughts

What ABBA Voyage demonstrates is not just that this kind of show is possible, but that it works as a format.

It shows that audiences are willing to accept a performance that is not physically live, as long as it feels live. That distinction matters because it opens the door to new ways of creating, distributing, and experiencing performance.

For decades, technology has supported live entertainment from the sidelines. This feels like a shift. Not technology enhancing the performance, but technology becoming the performance.

Credits

ABBAtars and performance image © Aniara Ltd, 2022 used under the fair dealing provisions of UK Copyright law.
ABBA curtain call image by Raph_PH via Wikimedia licensed under the Creative Commons Attribution 2.0 Generic license.

The true cost of complexity in modern cars

markw@markwilson.co.uk (Mark Wilson) — Fri, 20 Mar 2026 00:00:00 +0000

Today, I got my car back after a month-long repair. It started with a slightly unsettling experience when the steering failed. Not in a “that feels a bit heavy” sort of way, but completely. There was no ability to steer the car at all. The AA’s patrolman initially suggested I follow him to the garage until I pointed out that I literally couldn’t turn the wheels. (In the process of recovering my car, he also broke a connector on the electronic parking brake, but that’s another story.)

It got me thinking about how modern cars are put together, and what that means when something goes wrong.

From mechanical to electronic

Modern vehicles hide a lot of complexity beneath what still looks like a simple interface. In older cars, the steering wheel is connected to the wheels. It might be power-assisted, but the linkage is direct. If something wears out, you replace that part and move on.

On newer vehicles, the steering wheel is a controller - similar to one you might use with a driving game on a console. Turning the steering wheel is an input that is interpreted by a control unit, which then tells another system what to do. It works perfectly well until it doesn’t. The interface feels connected, but it really isn’t.

That pattern repeats across the car. Mechanical systems are now mediated by software and sensors. The added features improve the driving experience, but the complexity is easy to overlook until something fails.

Why small faults become big bills

When the steering failed on my car, it wasn’t a worn part. It was a complete unit — a sealed assembly. In this case, a £1600 component that wasn’t even in stock at Volvo’s central distribution centre in Gothenburg and took a few weeks to arrive.

The same applies elsewhere. What might once have been a minor repair can now mean replacing an entire assembly. On older cars, a worn suspension component might mean replacing a rubber boot. Now it is more likely to be a full suspension arm.

The effect is simple: faults that used to be small and local are now larger and more expensive to fix.

Complexity is not an accident

This is not poor design — it’s a deliberate consequence of how cars are built today.

Modern vehicles rely heavily on software and interconnected systems, managing everything from braking and stability to driver assistance features. Many of these features are expected or required, and they do make cars safer.

But each additional system brings more hardware, more software, and more potential failure points. When something breaks, it is rarely isolated, and it is usually expensive.

The cost of a middle-aged car

All of this adds up. The steering repair, labour, wheel alignment (tracking), and parking brake work have cost a sizeable sum on a seven-year-old car. Add in some tyres and brake pads (which are expected service items) and I had a significant bill shock.

All of this was on top of a timing belt replacement, front brakes and a major service a few thousand miles ago. In total, I’ve spent around £5000 on the car in the last 12 months. That’s roughly twice my annual budget for car maintenance.

At some point, I have to think about the sunk cost fallacy. But, for now, the plan is to keep it going, ideally long enough for a summer road trip across France, and then reassess.

Why the UK car market has shifted

For some time now, the UK car market has been built around finance, and servicing. Most new cars are acquired on PCP, HP or lease agreements — finance is used for the vast majority of new car purchases in the UK — and many are simply handed back at the end of the term rather than owned.

I bought my Volvo V60 nearly-new using a PCP and made the balloon payment to take ownership at the end of the agreement. Because the original list price was over £40,000, it still attracted the additional rate of vehicle excise duty for several years, even as a used car.

But £40,000 is no longer a luxury car. It means that running costs are increased for nearly-new cars, which is one of the reasons an all-in monthly charge looks more attractive.

That starts to make sense when you look at how cars behave in practice. When a single failure can cost four figures and take weeks to resolve, predictable monthly costs (e.g. leasing) and a warranty begin to look less like convenience and more like risk management.

Rethinking car ownership

Cars today are better than they have ever been. They are safer, more efficient and more capable. But they are no longer simple machines, and that has consequences.

Ownership now carries more uncertainty than it used to. Not because cars are worse, but because they are more complex, less repairable, and more expensive to fix when something goes wrong.

If the practical way to manage that risk is to hand the car back before anything expensive breaks, then it is worth asking a simple question:

Do we really want to own our vehicles, or just run someone else’s and give it back when the warranty ends?

Archiving my Twitter/X history

markw@markwilson.co.uk (Mark Wilson) — Tue, 17 Mar 2026 00:00:00 +0000

For many years I was an active user of Twitter/X @markwilsonit. I shared links, ideas, photos from events, commentary on technology and the industry, and some personal chit-chat too. Over time that added up to more than 70,000 tweets.

But the platform changed. Eventually it reached the point where continuing to use it no longer felt compatible with my values, so I stopped posting there, and made the tweets private.

Historical records

That left me with a problem though. Buried in those tweets is a lot of history – links to blog posts, conversations with people I respect, and snapshots of what was happening in the industry at the time. Twitter/X lets you download an archive of your data, but it also contains items that should remain personal to the user, like direct messages - so it can’t be published directly.

I wanted to build a small static website that turns the archive into something searchable and browsable that I could share more widely. There were some scripts around for converting Twitter archives to websites, but they didn’t seem to work for me when I tried a couple of years ago – maybe the archive format changed since they were written.

Vibe coding a script to create my own archive site

I ended up “vibe coding” (with ChatGPT) a small Python script that converts the Twitter data export into a static Twitter archive site. It’s intentionally simple: a static page; and a lightweight search index using JavaScript and JSON. All the tweets remain exactly as they were written (although with expanded URLs where t.co short links were in place), but now they’re accessible outside Twitter/X.

Rather than keep the script to myself, I’ve published it on GitHub so anyone else can do the same with their own data. If you’re curious about how it works – or you’d like to build your own archive – the code and documentation are available in this GitHub repository.

Just be aware that I downloaded my archive in August 2024 – Twitter/X archive formats have changed over time so, if it doesn’t work for you, you might need to tweak it.

Importing Eufy smart scale data into Garmin Connect

markw@markwilson.co.uk (Mark Wilson) — Sun, 15 Mar 2026 00:00:00 +0000

For years, most of my health and fitness data has ended up in one place: Garmin Connect. My watch syncs automatically. Steps, heart rate, sleep, runs and rides all flow into the same timeline. Activities are also synced from Garmin to Strava. There are a few bits and pieces in Apple Health (medications), but it’s pretty complete.

So when I bought some smart scales, I wanted the same thing. One place for all the data.

“Man maths”

The obvious option would have been scales from Garmin or Withings. But those are not cheap. Instead I bought a set from Eufy. Even my man maths couldn’t justify the extra expense.

The theory is that investing in technology to help manage my weight is worthwhile. The reality, of course, is that compulsive eating and weight management are much more complicated than that. But if a gadget nudges me in the right direction, I’m willing to try it.

The problem is that the Eufy app does not integrate with Garmin. So the data sits in its own ecosystem.

Fortunately, Garmin Connect allows body metrics to be imported from a CSV file. With a bit of spreadsheet wrangling, the Eufy export can be reshaped into something Garmin understands.

The format Garmin expects

Garmin’s import format is very simple. A CSV file like this:

Body
Date,Time,Weight,BMI,Fat
11/01/2026,07:22:16,75,25,22

Exactly like that – nothing extra, just those five columns. And the Body line seems to be essential – without it the import fails.

Preparing the Eufy export in Excel

Once you know that structure, the challenge becomes transforming the Eufy export into the same layout.

Start by exporting your data from the EufyLife app and opening the CSV file in Excel.
Delete the extra columns so you are left with Time,WEIGHT (kg),BMI,BODY FAT %.

The Eufy export stores date and time together in one field. Garmin expects them separately so we have to split the date and time.

Insert two new columns (B and C) after Time.
In cell B2, enter =INT(A2). Then format the column as Short Date (dd/mm/yyyy).
In cell C2, enter =MOD(A2,1). Then format the column as Time (hh:mm:ss).

Excel stores date and time as one number. The integer part represents the date. The decimal part represents the time. These formulas simply separate them.

Fill both formulas down the column for as many rows of data as you have.

Reshaping the file for Garmin

Rename the columns so they read DateTime,Date,Time,Weight,BMI,Fat.

The DateTime column is the original combined value exported by Eufy. We keep it temporarily while splitting the date and time.

Save the file (still in .CSV format) and close it.
Reopen the file. Excel will now have replaced the formulas with calculated values.
Delete the DateTime column.
Insert a new row at the top and enter Body in cell A1.
Delete any rows that already exist in Garmin Connect so the file only contains new entries.
Save the final CSV file. Your file should now look similar to this:

Body
Date,Time,Weight,BMI,Fat
14/03/2026,12:55:51,101.9,32.8,34.7
13/03/2026,10:12:27,103.4,33.3,35.4
12/03/2026,06:54:42,104.3,33.6,35.5

Importing into Garmin Connect

Open the Garmin import data page and upload the CSV file you prepared earlier.
The Garmin Connect site will recognise the data as Fitbit-style body metrics and ask how the values should be interpreted. Make sure you choose Kilograms for weight units and a date format of dd/mm/yyyy (31/12/2026), then click Continue.

The import should complete successfully.

The new entries should appear alongside the rest of your health data (Weight).

That all seems a bit of a faff, Mark!

It’s not quite the seamless integration I would have liked. But it works, for now. As I was writing this up, I thought I should probably script the CSV transformation. Maybe that’s the next step.

For now, at least I have my weight data in the same system as the rest of my fitness data.

Which feels like a small victory – even if the real challenge still happens in the kitchen, at the supermarket, at the petrol station, in the office and just about everywhere else.

It’s time to end “manels” at tech events

markw@markwilson.co.uk (Mark Wilson) — Fri, 13 Mar 2026 00:00:00 +0000

With International Women’s Day taking place last weekend, I’ve been reminded of a couple of industry events I attended late last year. I thought I’d posted on LinkedIn at the time about the poor female representation, but I can’t find those posts now. So while we’re celebrating women, it’s worth making the point again – because it’s still an issue.

The content at the events was… okay. One was a major IT channel/distributor event – and it was probably a bit too panel-heavy for me. The other event was run by a storage vendor and I was soon bored of tech product-and-feature talk (I only stayed for the excellent afternoon keynote). Both brought together people from a multitude of IT companies. Unfortunately, almost everyone on stage was male.

At the first event, it was well into the afternoon before the first female presenter took the stage. And the day was almost over before we saw a panel that wasn’t an all-male line-up.

The number of “manels” (all-male panels) was so noticeable that I started to keep a tally. At the end of the day the final speaker count was 30 men and 4 women. Thirty to four. In 2025. In a sector that claims to value progress and innovation.

At the second event, the only woman on stage had opened the event and quickly handed over to male colleagues. We didn’t hear a female voice again until after the lunchtime break.

To be fair, I’ve attended some really good events recently that have been far more balanced. That just proves it can be done. But those two stood out – for all the wrong reasons.

Yes, IT is still a very male-dominated industry. But that’s not an excuse for putting on events that simply mirror the imbalance. If anything, it’s a reason to work harder to widen the pool and to champion the diverse voices that are out there.

And to be clear: I’m quite happy to have my share of the limelight. But I’m a middle-aged, white, straight man. If someone else can bring a different perspective to the table, I’ll happily stand aside. We don’t move our industry forward by hearing the same voices over and over again.

There are organisations trying to change things. For example, techUK committed to ending “manels” back in 2017 and reaffirmed that commitment in 2020. For March 2026, they have a TechTogether campaign that is:

“Celebrating what organisations are doing to support diversity, equity, and inclusion, while acknowledging how much more needs to be done.”

And Thoughtworks has written about the importance of bringing diverse voices to tech conferences. But that was back in 2020 - and the events I described earlier make it clear that progress is still too slow.

So a simple ask for event organisers: try to make your events diverse. I know it’s not always easy. But if your speakers are mostly white men, and your panels are all “manels”, it might be worth reconsidering your line-up.

Events shape narratives, and narratives shape culture. If we want a more inclusive industry, we need to start by changing what – and who – we put on stage.