If you’ve spent any time on YouTube, Instagram or TikTok recently, you’ll have seen them everywhere. Funky cases. Mini keyboards. Little screens bolted to the side.

In simple terms, a cyberdeck is:

“a custom-built, portable computer often designed with a retro-futuristic or “cyberpunk” aesthetic, usually featuring exposed components, rugged casings, and specialized, personalized functionality”.

So of course I had to make one.

And because I’m incapable of building anything that isn’t somehow related to Formula 1, I decided to put the F1 Race Replay project inside one.

I’d actually had this idea sitting in my notes for months. No idea why it took me this long.

The Idea 💡

You know the F1 Race Replay project? The one that went a little bit viral?

What if it lived inside a physical box, with two screens, an LED strip that flashes yellow for yellow flags and white for safety cars, and a little LCD panel showing race control messages?

This idea has bee circulating in my mind for weeks if not months. A dedicated piece of hardware. A proper pit wall on my desk.

Sounds simple. It was not simple.

The Components 🔩

Here’s the thing nobody tells you about hardware projects: you can’t just start building. There’s no npm install. You have to figure out what you need, order it, wait for it to arrive, realise you got something wrong, and order again.

Here’s the final parts list:

• Raspberry Pi 5 — the brain of the whole thing

• 2x ELECROW 5” Touch Screen Monitors — one for the track map, one for telemetry

• RGB LED Light Strip — yellow flags, red flags, safety car, VSC. All of it.

• Freenove I2C LCD Module — displays live race control messages

• USB-C to USB-C Panel Mount — so there’s a clean power port on the outside of the case

• Ethernet Panel Mount — same idea, clean external connection

• Momentary Push Button — a proper power button on the exterior

• Wireless Mini Keyboard — used as a backup mouse and keyboard

• Peli-style rugged case — the housing for the project.

I already had jumper wires knocking around from a previous project, which saved me a few quid.

Assembling the Electronics 🔧

Before you start throwing everything into a case, you get everything working on a desk first. Lead times are brutal, if you find out a component doesn’t work after you’ve screwed it into a frame, you’re losing days waiting for a replacement.

So I wired it all up loose. Displays via HDMI and USB. LED strip connected to the GPIO pins. LCD module over I2C.

First power-on: most of it worked. Most.

I had originally bought an LED panel which I thought was RGB, however in the fine print in the description of the product, it mentioned it was the colour red only. Gutted, but glad that I had a spare LED strip lying around to replace it.

I wrote some software to flag the lights, display text on the LCD and show content on both screens to make sure they were working.

Eventually: working. Moving on.

The Software 💻

This is where I got overconfident.

I assumed loading the F1 Race Replay project onto the Pi would be straightforward. Clone the repo, install the dependencies, run it. Ten minutes, tops.

It was not ten minutes.

The Pi 5 threw a wall of errors related to OpenGL and Anti-Aliasing. Basically the graphical rendering that makes the full version look polished wasn’t going to fly on this hardware. So essentially the Pi isn’t powerful enough to run it as-is.

So I had to build a lite version, which took a day, but turned out to be a really great move for this project.

It meant I could strip the project back to exactly what I needed for the cyberdeck and rebuild it with the aesthetic I had in mind: minimalistic, retro, a bit brutalist. No fluff.

I ripped out everything that didn’t belong. Then I rebuilt the Driver Telemetry view with proper touch controls, so you can tap the screen to select a driver rather than fiddling with a keyboard.

It actually fits the build better than the original version would have.

What’s Next 🚀

I was hoping this week’s newsletter would end with a finished cyberdeck.

Spoiler alert: It’s not finished.

Turns out building a custom internal frame to mount several separate components is significantly harder than “just screw some stuff together.” The electronics work. The software works. It’s the physical housing that’s still giving me grief, and 3D printing takes a long time.

Currently, parts of the frame are sat on my kitchen table drying after being glued.

All that’s left to do is finish printing some of the cosmetics, and then finally install it inside of the case.

Have a great week. Keep building. See you in the next edition! 😀

I don’t know if that’s true. But I do know that lately, I’ve stopped feeling like a developer.

I feel like a product manager.

I delegate tasks. I review outputs. I approve things. And somewhere in the middle of all of that, the actual feeling of building something quietly slipped away. I don’t feel like that all of the time, it depends on the project, but its there.

So at the start of this year I told myself that I’m going to make an effort to increase my knowledge of electronics.

The Adult Version of Lego 🧱

I’ve always been curious about hardware. Done bits here and there. But it wasn’t until earlier this year that I sat myself down and made a proper commitment to make it more a part of my every day life, instead of just a tiny side-hobby / offering to clients.

Last year I built a game for an AWS conference using microcontrollers and break beam sensors; and I loved it.

If you’ve been following along, you’ll know I’m currently building F1-style telemetry sensors for my go-kart. It’s been a steep learning curve. It’s also been the most fun I’ve had on a project in a long time.

You can learn more about that project in the post linked below:

The Learning Problem 💡

Here’s the annoying thing about electronics: you can’t just install it on your laptop.

There are browser tools like TinkerCAD for designing circuits, but working with a simulator doesn’t give you the same feeling as actual components in your hands.

So I picked up one of those “Ultimate Starter Kits” from Amazon. Mine came with a Raspberry Pi Pico and a ton of components for £50. I actually bought it back in 2022, but it gathered dust because it felt overwhelming and I couldn’t justify the time.

These kits always come with a workbook or tutorial PDF. And in my experience, those are almost impossible to engage with. It’s hundreds of pages of components you have no immediate interest in using.

I learn by building real things. A 360-page manual isn’t going to change that.

So what am I actually using to learn?

You’re not going to like this.

I’m Using AI to Learn Electronics 💻

Here’s the thing, because hardware is such a human-involved process, I have to stay deeply engaged in a way I just don’t with software anymore.

Say I want to build a G-Force sensor. I still need to research which sensors to buy. I still need to think about power supply and whether I need resistors. I still need to design and 3D print a housing that fits my exact use case. I still need to physically wire everything together.

I can ask for guidance along the way. But I’m the one making the decisions. And unlike broken code, broken components don’t just undo themselves.

You can’t prompt an AI agent to go from idea to finished device sitting on your desk. Not yet and probably not soon. Well, I wouldn’t trust a “vibe-hardware” product in my house anyway.

That’s exactly why I’m enjoying this so much.

For the first time in a while, I feel like I’m actually building again. My creativity is the differentiator between a project that works and one that doesn’t. That feeling has been missing from my software work lately.

Where to Start 🚀

If you’re curious about hardware but have no idea where to begin, here’s what I’d tell you:

1. Buy a cheap starter kit. Spend £50 on Amazon and you’ll have more components than you know what to do with.

2. Skip most of the manual. Run through the first project so you know how to turn an LED on. Then close it and forget it exists.

3. Find a project that’s ambitious but affordable. Too easy and you’ll lose interest. Too expensive and you’ll be scared to break anything.

4. Ask for help, but always understand what you’re doing. If something isn’t working, ask why isn’t it working? If you’re using a component, ask what does it actually do? Blindly copying AI output works fine for a side project. It does not work when the wrong resistor fries your board.

There has never been a lower barrier to getting into electronics. The tools are there. The components are cheap. And weirdly, AI makes the learning curve a bit less brutal.

You just have to actually show up and build the thing yourself.

This week I shipped F1 Race Report, an automated system that wakes up every Monday morning, checks whether a Grand Prix took place the day before, and if it did, sends you a fully formatted race report straight to your inbox. No app to open. No website to visit. Just a clean email waiting for you.

The Project Idea 💡

The concept is simple. Every F1 Sunday, millions of fans either watch live or catch up on highlights. But there’s no great “morning after” summary that combines the data and a readable narrative in one place.

Correction, there is, Formula 1 themselves post articles, but I wanted to build one myself.

So this tool does exactly that. Automatically, every week, for the entire season.

Features 🏎️

• Automatic race detection: checks every Monday at 09:00 UTC whether a race happened the day before. If not, it skips silently.

• Full race results: podium finishers, fastest lap, and a complete results table

• Lap position chart: a dark-theme line chart showing every driver’s position throughout the race, coloured by official F1 team colours

• AI-written narrative: a proper race summary written by a GPT-4o-mini agent, not just a data dump. (other models can be used but GPT-4o-mini is insanely cheap and does the job)

• Inbox delivery: a polished HTML email that renders correctly in Gmail, Outlook, and Apple Mail

How It’s Built 💻

This one’s a bit of a polyglot stack, which made it interesting to put together.

• Language: TypeScript + Python

• Scheduler: Trigger.dev — fires a scheduled task every Monday morning. Free tier is more than enough.

• Race Data: FastF1 — a Python library that pulls official F1 session data. Lap times, positions, team colours, all of it.

• Chart Generation: Chart.js with Node canvas — renders the lap position chart server-side as an image, then embeds it inline in the email as a CID attachment so it actually shows up rather than getting blocked.

• Email Generation: OpenAI Agents SDK (gpt-4o-mini) — the agent receives the raw race data and outputs a plain text report of what happened, which is inserted into the HTML template.

• Email Delivery: Resend — sends the finished email. Again, free tier handles it fine.

The TypeScript side orchestrates everything. The Python script handles the FastF1 data fetch and hands the results back as JSON to the TypeScript app. I would have built the entire thing using TypeScript, but the FastF1 package only works with Python, so I created a quick executable script for the import.

One thing worth calling out, the chart embedding. Getting inline images to actually render in all major email clients is more annoying than it should be. CID attachments are the right approach and it works, but it took a bit of fiddling.

The Lap Position Chart 📈

Finishing positions don’t tell you anything about the actual race. They just tell you where everyone ended up. This chart fixes that.

Every driver gets a line. Every lap gets a data point. The y-axis is inverted so P1 sits at the top, and each line uses the official F1 team colours, so you can trace your favourite driver across the full length of the race.

It’s rendered server-side using Chart.js and chartjs-node-canvas. No browser, no headless Chrome nonsense. Just a buffer that goes straight into the email.

The Agent 🤖

The results, podium, and chart are all deterministic, FastF1 gives you the data, you render it. The narrative is a different problem.

I didn’t want a summary that just reads back the lap times. Anyone can see those. The interesting stuff is the story, the undercut that won the race, the safety car that reshuffled everything, the driver who threw it in the wall on lap 3. FastF1 just doesn’t give you that data.

So instead of prompting a model with raw JSON and hoping for the best, the report uses the OpenAI Agents SDK with the WebSearchTool enabled. The agent researches the race itself before writing anything.

The finished HTML drops straight into a pre-built template alongside the deterministic content. The agent never sees the full email, it just returns 2-3 <p> tags and nothing else.

The Future 🚀

Right now the tool covers the race. But an F1 weekend is three days long.

The obvious next step is adding equivalent reports for qualifying and practice sessions, so you’d get a summary drop after each session across the whole weekend. FastF1 supports all of that data, so it’s entirely doable.

That’s where you come in.

Get Involved 🫵

This project is fully open source and I’d love for the community to help shape where it goes next.

Whether that’s adding qualifying support, improving the email template, tweaking the chart, or fixing something that’s broken… contributions are very welcome.

👉 github.com/IAmTomShaw/f1-race-report

Star it, fork it, open a PR. Let’s build it out together.

Have a great week. Keep building. See you in the next edition! 😀

The software was better. The UX was tighter. The architecture held up under load. That mattered. It took time and skill to ship something good, and not everyone could do it.

That gap is closing fast.

What AI actually changed

The conversation about AI in development tends to focus on speed. You can ship faster. You can prototype in an afternoon. Junior devs punch above their weight.

All true. But that’s not the real shift.

The real shift is that the barrier to building something functional has dropped to almost zero. Not just for you. For everyone. Your competitor can spin up the same stack, with the same features, in roughly the same time. The thing you spent three months building last year? Someone can replicate the core of it in a week.

The code itself is no longer a competitive advantage.

Which means if you’re a developer who’s been quietly assuming that writing good software or building a good product is enough, it’s time to think about what your actual moat is.

As far as I can tell, there are two answers.

Moat #1: Marketing and audience

The first moat is still digital, but it has nothing to do with the code.

If people already know you, trust you, and follow what you build, then it doesn’t matter that someone could clone your product. They’d still come to you first. They’d still buy from you because they trust you.

This is what’s been quietly true in the indie dev world for years. Developers with large audiences ship mediocre products and make a living. Developers without audiences ship excellent products and get nowhere. The code quality has almost no correlation with the outcome.

Distribution has always been the moat. AI just removed the last excuse for pretending otherwise.

I started building my audience back in 2021, long before this felt urgent. Not because I had some grand strategy, but because I wanted to reach more freelance clients and create social proof around my work. That compounding head start is something I’m genuinely grateful for now. If I were starting from scratch today, with no audience, I’d be urgently getting started.

The developers who spent the last few years building in public, writing, talking to people, they’re in a very advantageous position right now.

Moat #2: The real world

The second moat is harder, and most developers aren’t even thinking about it.

Software that only lives on a screen is now trivially replicable. But software that interacts with the physical world is a different story. Hardware. Devices. Sensors. Tools that do something tangible, that connect to a machine, read from a physical environment, control something in the real world.

Nobody can vibe-code their way to a well-engineered embedded system. You can’t prompt your way past supply chain constraints, or skip the part where you actually test a physical prototype. The real world doesn’t have a fast-follow.

AI compresses the time it takes to write code. It can’t compress the time it takes to understand a real problem.

This is something I’ve been getting more curious about myself. I’ve been working on a sensor project for a go-kart, capturing real telemetry data from a physical vehicle. I’ve been 3D printing custom housing for the hardware. It’s messier than writing a web app. It’s slower. Things don’t work the first time.

And that’s exactly the point.

Think about the software that feels genuinely hard to displace. It’s rarely a web app. It’s the thing bolted to a piece of machinery. The firmware running on a device. The system that has to work in a warehouse, on a factory floor, in a car, on a track. Those problems require domain knowledge, physical intuition, and real-world testing that no amount of prompting replaces.

That’s where the moat is.

So what should developers actually do?

I’m not saying stop caring about the code. Write good software. Ship clean, reliable things. That still matters.

But start being honest about where your edge actually comes from.

Are you building an audience? Are you writing, posting, being visible in the places your customers exist? Or are you quietly assuming the product will speak for itself?

Are you building things that touch the real world? Things that require knowledge, context, and physical understanding that can’t be Googled or prompted into existence?

The developers who thrive in the next few years won’t necessarily be the best at writing code. They’ll be the ones who figured out that coding is now the easy part, and went and got good at something harder.

Have a great week. Keep building. See you in the next edition! 😀

Let’s get into it.

Project Idea 💡

The goal is simple: build an AI agent that can answer anything about Formula One.

Not just “who won the 2026 championship?”.

I’m talking about stats, race results, what happened at each circuit, and eventually, what the lap data actually looked like.

The kind of questions an F1 obsessive would ask.

Features 🏎️

• Conversational AI: Ask any F1 question and get a detailed, contextual answer

• RAG-powered knowledge base: 40+ public knowledge sources indexed across driver profiles, team histories, circuit guides, and FIA regulations.

• Streaming responses: Real-time token-by-token streaming via Server-Sent Events so you’re not just staring at a blank screen waiting for a response to finish generating.

• Stats Querying: The agent can query a database of statistics from champions, races, qualifying sessions, etc to answer complex questions that wouldn’t be possible via a traditional RAG pipeline (still working on this, not in the repo yet).

The Tech Stack 💻

Language: Python 3.12

Agent Framework: OpenAI Agents SDK

Backend: FastAPI

Database: PostgreSQL + pgvector

Web Scraping: Playwright

Frontend: React + TypeScript + Tailwind CSS

How the RAG Pipeline works

The core of the project is a RAG pipeline (Retrieval-Augmented Generation).

In plain English: instead of relying purely on what the model already knows, we feed it relevant chunks of real F1 content at query time.

The pipeline runs in four stages.

1. First, a Playwright-based scraper pulls clean text from Wikipedia articles, stripping out all the boilerplate (navigation bars, styling, references, etc) before anything gets stored.

2. Then it chunks the content into overlapping ~400-token segments using tiktoken, respecting paragraph and sentence boundaries to keep things semantically coherent.

3. Each chunk gets embedded using OpenAI’s text-embedding-3-small model.

4. The embeddings are loaded into pgvector (PostgreSQL with vector search built in)

When you ask the agent a question, it performs a cosine similarity search over that vector store and surfaces the most relevant chunks to inform its answer.

It’s a clean setup. And it works really well for the narrative side of a given subject (in this case F1 and its history, driver profiles, team stories, regulation changes, etc).

The future 🚀

This is just the MVP. Currently, it only supports the RAG knowledge search, but not for long.

I’ve already started building out a database search for statistics, which will allow the agent to reference and filter structured data. Lap times, race results, championship standings, tyre strategy, etc. The stuff that makes F1 data genuinely fascinating.

The end goal is an agent that can answer the full spectrum of F1 questions. Not just who won, but fastest laps, driver comparisons, potentially generating charts, etc.

How you can get involved 🫵

If you’re an F1 fan, a data nerd, or just someone who wants to poke around a proper RAG implementation, the repo is open source and ready to run.

Give it a star if you find it useful. ⭐

👉 https://github.com/IAmTomShaw/formula-chat

Thank you to everyone that’s supporting the newsletter and keeping up to date with my projects. See you in the next one! :)

This is the short story of how I went from getting scammed by a software development agency to building my own career in tech and learning to build projects for myself.

Let me take you where it's all began, spring 2020…

I Had No Idea How to Build an App 📱

I didn’t come from tech. Not even close.

My background was marketing. For years I ran marketing campaigns for bars and restaurants. I felt like I knew that world inside out.

So when lockdown hit and venues were being forced to close overnight, I felt it personally. My entire business was gone, and I had friends losing their livelihoods in real time.

So I had an idea.

An app that would help restaurants and bars adapt and safely sell to their customers through the various stages of lockdown restrictions. A lifeline for businesses that had no idea how to pivot online.

The only problem? I had absolutely no idea how to build it.

So I Hired an Agency 💰

It seemed like the logical move at the time.

We spent weeks working with them. Requirements, scope, back and forth. Getting excited about what this thing could become.

Then we asked for access to our own code.

They said no.

Their reasoning was that if they handed it over, we might not come back for continued support. They wanted us locked in. Dependent on them.

They were holding our own product hostage to protect a retainer.

Trust broken. Instantly.

The Red Flags I Should Have Caught Sooner 🚩

Looking back, the signs were there.

Before signing anything, I should have asked:

• Who owns the code? This should be in writing before a single line is written.

• Will I have access to the repository? If they hesitate on this, walk away.

• What happens if we part ways? If you’ve paid, you’re entitled to what you paid for.

A good agency / freelancer should never make the client feel like they don’t own the work.

The Decision That Changed Everything ⚖️

I had two options.

Find another agency. Or figure it out myself.

I chose the second one. Which, honestly, terrified me.

No CS degree. No developer friends to call. No idea where to even start. Just an idea I believed in and a lot of frustration pointing me in one direction.

So I started learning to code. And then I started building my first app.

What Actually Happened 🚀

I launched the app / web platform.

Thousands of users signed up. It drove tens of thousands of dollars in revenue. For someone who had never written a line of code before, that felt completely unreal.

But more importantly, it opened a door I didn’t know existed.

The app eventually shut down when the world returned to normal. But that project turned my failed marketing business into a new career in tech.

I began freelancing and making videos about programming, building things, etc

Which turned into where I am now.

None of this would have happened if that agency had just handed over the code like they should have.

The Thing Nobody Tells You ‼️

Doing something yourself is terrifying at first.

But it is also the fastest way to learn. And learning compounds. Every project teaches you something the next one benefits from. Skills that feel impossible in month one feel obvious by month six.

If I had just hired another agency, I wouldn’t have learnt anything.

If I was too busy, outsourcing would have been a good idea. But the reality was that I had all the time in the world.

If you are sitting on an idea right now, waiting until you feel ready or until you can afford someone else to build it… consider whether that wait is actually protecting you, or just delaying you.

Sometimes if you want to build something, you have to build it yourself.

A Note for the Freelancers Reading This 🫵

If you’re running an agency or freelancing, I hope this story teaches you something too.

• Be transparent about code ownership from day one. It protects both of you.

• Give clients repository access. If they’ve paid, it’s theirs.

• If you part ways, they get what they paid for. No exceptions.

Trust is the only thing that keeps clients coming back. Holding code hostage doesn’t create loyalty. It creates resentment.

And sometimes, it accidentally launches someone else’s tech career.

F1 Race Replay entered it’s pit wall era.

The project that started out as a simple way for developers to visualise F1 races on a 2D map has now become a pit wall-style tool for developers and F1 lovers to be able to analyse data.

Here’s how…

2 weeks ago I built the telemetry service. A way for the main race application to stream data to different windows on my desktop.

This meant that we could make a start on adding insights outside of the Race Replay window that you’re used to seeing.

Introducing the Driver Telemetry Insight

This new insight allows you to view the telemetry traces coming of of all of the drivers cars, onto a line chart while the Race Replay screen is in view.

This exact style of charts are used by motorsport engineers to analyse how a driver is actually driving the car. Such as:

• Where they’re braking

• Where they’re changing gear

• How heavily or steadily they’re applying the brake

These charts are probably the most valuable charts that an Engineer has access to during a race weekend, especially when they’re used to compare telemetry between teammates.

You can access this new insight by selecting it using the Insights menu that automatically appears when the Race Replay Window is loaded.

How you can build your own Insight!

This new method of building insights has been made super easy using the “PitWallWindow” class.

The “PitWallWindow” class implements the essential logic for initialising and running a pit wall insight inside of the project.

The “MyCustomWindow” template inside of “pit_wall_window_template.py” is a blank canvas built on top of the PitWallWindow to make it super easy for you to build your insight.

It receives all of the telemetry data that you’ll need from the Telemetry Service by default, so you don’t have to worry about how its connected.

‼️ Important: Make sure to add your chart to the “Insights Menu” so that it can be selected by users.

I’ve written a guide for building your own Insights and added it to the GitHub repository. You can find it here: https://github.com/IAmTomShaw/f1-race-replay/blob/main/docs/PitWallWindow.md

Projects of the Week 🚀

Last week on my Instagram, I asked developers to drop the links to their open-source projects, with the intention of showcasing my favourites on my social channels!

Here are three of my favourites!

1. DhruvGoswami10/TARS-WIZARD

Open-source guide to building a replica of TARS from the Interstellar movie!

• Python 🐍

• 3d Printing 🖨️

• Hardware 💻

GitHub: https://github.com/DhruvGoswami10/TARS-WIZARD

2. saccofrancesco/Deepshot

ML application for predicting NBA game outcomes using historic data.

• Python 🐍

• scikit-learn 📈

GitHub: https://github.com/saccofrancesco/deepshot

3. TemRevil/Kittle

Chat with your codebase to understand vulnerabilities, bugs, etc using your own AI API Keys.

• TypeScript 🔵

• LLMs 🧠

GitHub: https://github.com/TemRevil/Kittle

If this is successful, I might turn “Projects of the Week” into a regular feature on this newsletter!

If you’d like to get your project feature, send it in by commenting on this post (via Substack) using the following format: [Your GitHub link] - [Project Description]

Not because I couldn’t build a good product.

That’s the painful part.

I’ve always wanted to build something real. Something that solves a problem for thousands of people.

People love my open-source projects (not to brag). But there’s a huge difference between building communities around open-source projects and launching a paid service to customers.

I’ve had many failed attempts in the past:

1. Kardlo (2021)

My first proper app.

A mobile ordering system for restaurants.

We launched during COVID.

Customers signed up. Orders came in. Revenue grew.

Over $40k revenue in 45 days

I thought I’d hit a home run.

Then lockdown ended. And with it, the urgency.

Restaurants went back to normal service. They didn’t need another system. They needed fewer systems.

The product didn’t fail technically.

The market no longer needed it.

2. Code Planner (2023)

I was so excited about this one. And some developers still love it, so I’ve kept online. (link here)

Over 10,000 registered users.

And yet… it doesn’t make meaningful money.

Why?

Because I built it for me.

I assumed:

• Developers want to plan projects exactly like I do

• Developers are juggling multiple large-scale projects at once

• Developers care enough about planning to pay for it

Turns out… most don’t.

Most devs spin up a repo and just start building.

I built a “nice to have” and tried to price it like a “need to have.”

Classic mistake.

3. CreatorBee (2023)

A pitch deck platform for content creators.

On paper? Smart idea.

In reality? My audience doesn’t follow me for creator advice.

They follow me to watch me build.

I tried selling swimming lessons to people who showed up to learn rock climbing.

The product wasn’t terrible. The distribution was.

So what’s the lesson here?

None of these failed because the product was bad.

They all failed because of one thing.

I started building before thinking about distribution.

That’s backwards.

Here’s the uncomfortable truth:

Most developers don’t fail because they can’t build.

They fail because nobody knows they built something.

And distribution isn’t a “launch day” problem.

It’s a “before you write a line of code” problem.

If you don’t know:

• Who exactly it’s for

• Where those people are

• How you’ll consistently reach them

• Why they would care

Then you’re just building for the dopamine.

And dopamine doesn’t pay the bills.

Distribution First. Product Second.

Before you build:

• Do you have an audience?

• Do you have access to someone else’s audience?

• Are you solving a painful problem, or a clever one?

• Would someone pay today for a scrappy version?

If you can’t answer those clearly, pause.

Because once you press “deploy,” you’re not a builder anymore.

You’re a marketer.

And most developers aren’t ready for that identity shift.

You can keep building for fun.

But if your goal is a startup?

You need to figure out how you’re going to sell it, before you start building it.

That’s the lesson I learned the expensive way.

I hope you’ve enjoyed this slightly different broadcast of build notes.

If you did, please give it a like so I know to send out more advice like this :)

Until now, every new feature in F1 Race Replay had to fit inside a single window.

That constraint shaped everything:

• what insights we could add

• how complex charts could be

• which Pull Requests could realistically be merged

That limitation is now gone.

Introducing the Telemetry Stream Service

I mentioned in a video on YouTube a few weeks ago that the next step of building the project meant that we needed to find a way to share data between application windows. So since then, I’ve been building a new internal service that streams telemetry out of the race replay window in real time.

Instead of every feature living inside the Arcade Race Replay UI, telemetry is now broadcast via WebSockets to any window or application on your local machine that wants to consume it.

In simple terms:

• the race replay window becomes the producer, and everything else becomes optional add-ons.

• Each rendered frame publishes a chunk of telemetry data, and any connected client can subscribe to it as if it were live car data.

Why this matters (especially if you’re a contributor)

Since launching the project:

• 160+ Pull Requests have been opened

• 30+ contributors have had code merged

One of the most common reasons PRs were rejected wasn’t because the submissions weren’t good enough, it was because I had to be so careful about filling up the user interface.

If a feature:

• didn’t fit cleanly into the existing UI, or

• added too much visual clutter

…it was hard to justify merging.

The Telemetry Stream Service changes that completely.

New features no longer need to live inside the main race replay window. They don’t even need to use Arcade.

You can now build:

• standalone dashboards

• external charting tools (PySide6, anything else you want)

• multi-monitor pit wall layouts

• experimental insights without bloating the core UI

If it can consume telemetry, it can be part of the project.

What you can build now

A few examples of what’s suddenly possible:

• tyre degradation or stint analysis dashboards

• driver delta and gap visualisations

• strategy simulators running alongside the replay

• custom “second screen” pit wall tools

• experimental ideas that don’t need to be merged into the core UI at all

• Users can open only the tools they care about, and ignore the rest.

No more fighting for space inside one window.

How to try it

The service is ready, but it’s not enabled by default yet.

Run the project with the --telemetry flag to enable streaming.

When enabled, a Telemetry Stream Preview window opens alongside the replay.

This just shows raw streamed data so you can understand exactly what’s being broadcast.

If you’d like to take a look at the code for yourself, you can view the Pull Request on GitHub:

https://github.com/IAmTomShaw/f1-race-replay/pull/223

This is a huge step toward turning F1 Race Replay into something that actually feels like a real F1 pit wall.

The Problem 🤔

I’ve been self-employed (a freelancer and small business owner) since the day that I turned 18 (I’m 25 now), and I can say with absolute confidence that the most annoying task for me to complete on a regular basis is sending proposals. Its full of issues:

• Figuring out pricing

• Figuring out how long something is going to take

• Writing up the proposal to sell the service, but not sound too eager

• The amount of time you actually spend on all of the above

There have been times where I’ve spent an entire day working on a quote (proposal) to send to a customer. It felt like a day wasted.

If I had been able to create the quote faster, I would have had more time to work on completing client projects, meaning I would have earned more money.

To solve a problem that I and many other freelancers face, I’ve started this project…

Introducing Quote CLI 💰

Quote CLI is a simple command line-based tool used for generating project proposals and pricing quotes from client briefs.

Using the “quote” command, a user can instantly open the tool on their local computer, so there’s no need to visit any specific websites.

Originally this tool was built as a web interface using Streamlit and Python (https://github.com/IAmTomShaw/quotation-agent), however I wanted to explore building a CLI tool using TypeScript and Node.js that could be instantly run from the terminal at any time.

How it works 💻

Users can open the CLI tool at any time inside of their terminal by entering “quote” and pressing ENTER.

The user can create a new quote using “/create” and passing in the exact brief text from the client.

The user can discuss the quote with the chatbot and provide any additional information that the agent asks for.

When working on a quote, you can also use the “/close” function to generate a final quote text and save it to your local storage.

Tech Stack

• Language: TypeScript

• Runtime: Node.js

• Agent Framework: GitHub Copilot SDK

Third-Party Integrations

• Notion (via API) - for accessing the user’s service pricing information

• Exchange Rate API - for converting currencies automatically

Future ideas 💡

These are two of my most urgent ideas for improving the project

1. Making GitHub Copilot optional

Right now, the tool works best if you already have GitHub Copilot installed.

That’s great for some users, but not ideal for those that don’t use Copilot.

I’d love to make the AI layer pluggable, so you can choose:

• your own AI provider

• or a different agent framework entirely

2. Making integrations optional

At the moment, the tool assumes:

• your pricing/service info lives in Notion

• you want to use a specific exchange-rate API

That doesn’t exactly make this tool useful for everyone.

Making these integrations optional (or replaceable) is key to making Quote CLI usable by as many developers as possible.

Why I’ve chosen this project next.

I’ve had loads of great suggestions from the community:

Sim racing tools, generative AI projects, resume builders, even event operating systems.

All great ideas.

But since so many readers of this newsletter are freelancers or developers planning to start a business, this felt like the most useful place to start.

Build it with me 🤝

This project isn’t “done”. It’s a starting point.

If you’ve ever wanted to:

• contribute to open source but didn’t know where to start

• influence the direction of a real, practical tool

• or just ship something that people actually use

This is your invitation.

👉 Repo: https://github.com/IAmTomShaw/quote-cli

👉 Issues, ideas & PRs are all welcome.

Let’s build something genuinely useful together.

(also if you could give it a Star on GitHub, that would be great 😉)

As a programmer you’ve probably heard the following advice:

“Build real projects or contribute to open source”

It sounds great, but in practice, it often doesn’t work. Because so many programmers build a “real” project, and then it never gets used.

Or they try to get involved in open source projects, and their PR never even gets looked at.

So I think I’ve come up with a solution, and I hope you’re here for it.

The problem isn’t motivation or skill.

The problem is context.

People learn best when they’re:

• working on something that actually ships into the real world

• solving a problem they care about

• and building with other people, not alone

The idea (that I hope you’ll love it) 🧠

Since launching F1 Race Replay, over 130 features and bug fixes have been contributed by developers from all over the world.

And the reason it worked wasn’t luck.

It worked because:

• the project did something genuinely cool

• it was themed around an interest people already cared about

• and it was small enough that contributors could make a real impact

That experience changed how I think about building.

Let’s build something together! 🧑‍💻👩‍💻

So I want to try something.

I want to experiment with building open-source projects together, starting from day one.

Not as a Discord full of ideas, but as small, focused projects that actually ship.

This isn’t a course. It’s not a bootcamp. And it’s not about grinding for free.

Most people get involved in projects because of 2 reasons:

• The topic/mission of the project interests them

• The technologies that are being used are ones that they want to work with (and show other people that they can work with them)

I’ve built some cool projects that I’ve open-sourced before, so we could further develop some of these, or we could start from scratch?

To get this started, I’ve been thinking about a few problem spaces we could explore together.

We don’t have to work build in these categories though, this is just a starting point for ideas.

Categories we could look at 💡

1. Motorsport 🏎️

Perhaps a simulation tool? Or what about a sim racing pit wall? Think F1 Race Replay, but for Sim Racing (I’ve thought about this a lot, so we could definitely do this)

2. Developer Tools 💻

As developers, we’re perfectly positioned to build tools for other developers. We know what problems exist, and we have the ability to solve them. Whether it’s an extension for an IDE, a CLI tool, Database tool, etc, I’d love to know what we could do in this space.

3. Small Businesses 🛍️

Small businesses often struggle to find tools that are affordable and can meet their needs. I think every small business needs a bit of help, especially when it comes to the technical side of things.

Even though the project would be open-source, it could be a great opportunity for you and other developers to potentially earn some money helping these businesses to install the tool and start using it.

4. Local Software Tools 🗺️

Last year I had an idea which I never really actioned. It was called the “Manchester API”, a single API to give developers access to as much data as possible about things happening in the city that I live in.

Bus times, business listings, neighbourhood info, events, etc.

This API would be one a single trusted source for data across the city. Meaning that developers could easily build applications on top of the API, without having to worry too much about how to get the data.

I’d love to know your thoughts on this one…

How to get involved 🧑‍💻

You’re probably wondering, “Tom, what’s the point in this?”.

Part of what makes an open source project successful is the distribution it has and the ability to attract contributors. Without those two things (users and contributors), there isn’t much point in building an open source project.

So by doing this, my goal is to help programmers like you to get involved in projects that receive enough exposure that you can say “I’m a contributor to that project that everyone knows about”.

So what’s next? 👀

If you’re interested in getting involved, we need some ideas. I’m going to have a brainstorm, but I’d love to know what you’d like to build too! Hopefully then we can find some synergy between our ideas and build something that we’re all excited about!

What you can do to get started ⬇️

In the comments on this post, I want you to share one project idea you’d genuinely want to help build with other people.

Not a startup idea.

Not a massive platform.

Just a real problem you think is worth solving together.

Over the next week, I’ll look for patterns, overlap, and momentum… and then we’ll pick something and start building.

If this works, it won’t just be another Github repo… it’ll be a shared success story for everyone involved.

Leave a comment

A quick project recap 🏎️

I love going to the local karting track, I might not be the best, but it’s a fun day out.

As a tech nerd and F1 fan, I’ve always wondered what telemetry data from my driving would look like at different parts of the lap. Things like:

• Speed

• Steering angle

• G-force

• Where I’m using the throttle and the brakes

Having all of this information would effectively give me my own pit wall like the ones you see on TV.

A few weeks ago I made a start by messing around with an accelerometer and gyroscope module and figured out that I could use this to track how much I’m pressing down on the pedals.

If you’re wondering why I’m using a gyroscope to measure brake pressure, I explained this in the original post a few weeks ago:

Long story short, the sensor would need to be inside of my shoe and would measure the rotation of my foot to determine how much I’m pressing down on the throttle and brake pedals.

The problem 🤦‍♂️

Putting sensors inside of my shoe is no problem. It might be a little uncomfortable or require some 3D printed housing, but that’s easily doable.

Getting the data from the sensor, connecting it with any other sensors and saving the data is the main problem.

Initially I thought it would be a fantastic idea to run a cable from the sensor in my shoe to a Microcontroller that I’d keep in my pocket. Of course you can see how that’s a massive safety issue…

So it sounds like we need to remove the wires. But how?

The solution 💡

I know what you’re thinking “oh no, how’s he going to solve this?!? The project must be over now…”. Wrong. And, in proper “Tom Shaw style” I’m going to share the solution with you!

If I’m worried about cables, there is one really useful solution that comes to mind…

Bluetooth 🔵

I’m using Raspberry Pi Pico W’s for this project at the moment, and one of their features is that they carry built-in Bluetooth capabilities.

When the 2 Raspberry Pi Picos (a designated transmitter and a designated receiver) are turned on, the transmitter starts broadcasting its availability, with the receiver connecting to any transmitters that are available. Once connected, a start/stop button on the receiver can be used to start the data collection process which syncs the timeline and stores it onto a MicroSD card.

Updated Project Architecture

Some project architecture changes were needed to make this work, but I think we’ve got a pretty solid solution.

• All sensors in the kit will now transmit data to a single receiver.

• The receiver will merge all of the incoming data into a single timeline and save it to a MicroSD card

• There is an opportunity to add another sensor to the receiver’s hardware, which gives it dual purpose. Maybe tracking G-force?

Testing the Bluetooth telemetry

I’ve created this live telemetry viewer so that I can see the data coming off of each of the sensors in the kit.

The bottom chart displays the data coming from a sensor that is using a Bluetooth connection to communicate with the receiver.

The chart here shows some data that has been recorded by moving and rotating the sensor. For demo purposes, the orientation data and the acceleration data have been combined, which is why you might be wondering why the graph is titled “Acceleration”.

Remaining Issues 📋

Of course there are some issues with using Bluetooth as a method of transferring live telemetry data. Here are two that I am experiencing at the moment:

• Latency is causing some telemetry data to be out of sync by up to 100 milliseconds

• Minor drops in connection sometimes mean that data is patchy

These two issues may not be the end of the world, especially as this is a hobby project, but it would be nice to get them resolved.

The next focus is fixing a bigger issue…

I’m using the wrong sensors ❌

Since posting a video about this Bluetooth addition to the project, I’ve received feedback from some motorsport engineering experts (keeping names secret as I have not asked for permission to name them) who have informed me that the sensor I’m using isn’t good enough for the job.

They’ve suggested a better sensor module that can easily be put into the project, but I’ll have to test it before I talk about it in a newsletter post.

The analytics on Substack are the only way I know if you’ve enjoyed reading a specific post.

So if you want to see more like this, drop a like, comment and share it with a friend!

See you next week!

Why a spreadsheet doesn’t cut it anymore 🚫

I’ve been doing my best to keep track of things using spreadsheets, but the problem is that they get bulky and unorganised really quickly. If you try to keep it simple, you don’t get much functionality, and if you want detail, it breaks easily…

Duplicated rows. Broken formulas. The fear of accidentally deleting things. Ugh!!!

Spreadsheets work fine at the beginning, but as I’ve started to invest in different things, put my money to work and have the desire to keep track of it over time, a simple spreadsheet just isn’t cutting it anymore.

2025 was a big year for me, and I want 2026 to be even bigger! So it’s important that I have something to help me keep track of my finances.

I built something for myself (and open-sourced it) 💻

I wanted a single place where I could see everything, bank accounts, investments, assets, loans, without having to worry about whether I’d accidentally broken a spreadsheet formula six months ago.

Once I had a rough version working, I realised something interesting:

“this isn’t just useful to me”

So this week, I cleaned it up and launched it as an open-source project on GitHub: Personal Finance Tracker.

(image above doesn’t contain my personal finances btw 😉)

Honestly, it’s a simple web app for recording balances over time and visualising how your net worth changes. No budgeting gimmicks, no predictions… just a clear picture of where things stand.

Let me share with you how I built it.

Tech Stack 💻

• Frontend & Backend: Next.js

• Authentication: Auth0

• Database (if Cloud Sync is being used): MongoDB

• Hosting: Amazon Web Services (but can be hosted with any Next.js compatible host or hosted locally)

Features 🚀

• Personal Balance Sheet: Get an instant snapshot of what your finances look like.

• Manage Accounts: Create and manage multiple accounts (bank accounts, stock accounts, credit cards, etc).

• Record Balances: Quickly record periodic balances for accounts and assets.

• Net Worth & Charts: Visualise net worth over time with interactive charts going back weeks, months and years.

• Offline First: Local-only mode with optional cloud sync via the toggle.

• Download Backups: You can download a copy of your data at any time.

How I’ve built offline-mode 👀

Offline mode is a weird thing to build into a web app in 2026.

Most people would just assume everything lives in a database somewhere and move on.

But whenever I use any kind of personal finance tool, my first thought is always the same:

“Where is my data actually going?”

Even if I trust the company, I don’t necessarily trust the outcomes. Breaches happen, mistakes happen, and financial data is one of those things you can’t really take back once it’s out there.

So for this project, I wanted the default experience to be the safest one.

When you open the website for the first time, no financial data is sent to a server. No balances, no assets, no net worth history. All of your financial data is stored locally in the browser using local storage, and it never leaves your machine unless you explicitly opt into cloud sync.

Under the hood, the app’s data model is intentionally small. Right now, all finance data fits into just two interfaces, which makes it easy to store, version, and export without any hidden complexity. That simplicity is what makes offline-first possible without the app becoming fragile.

Cloud sync is there if you want it, and only if you want it. When enabled, balances are associated with your account and stored remotely so you can access them across devices. But offline mode isn’t a “limited” version of the app; it’s the baseline.

The community is already getting involved! ❤️

Since launching, two other developers have started building features for the project to help kickstart its growth and turn it into a fully comprehensive personal finance tool!

With one PR already being accepted!

There’s something really special about starting a new open-source project and seeing people contribute to it. The project is small enough that every developer can easily get a full picture of the project and instantly think “I know what’s missing” and then get to work building it!

These kind of open-source projects are exactly what I wish I’d had access to earlier in my career. Frankly, the big open-source projects scare me, so I never even thought about contributing to them. But this, a real tool in its infancy, that’s something I’d have loved to have been a part of.

If you’ve ever wanted to contribute to something practical, or just see how a project evolves in public, here’s a list of some of my favourite projects that I’ve open-sourced in the past few months that I’d love to see more people get involved in:

F1 Race Replay: https://github.com/IAmTomShaw/f1-race-replay 🏎️

Personal Finance Tracker: https://github.com/IAmTomShaw/personal-finance-tracker 💰

Stock Market Tracker Agent (via SMS): https://github.com/IAmTomShaw/stock-tracker-agent 🤖

My F1 Race Replay project has received a lot of positive feedback and recommendations over the past few weeks.

One thing that always keeps cropping up is adding a GUI menu to the project.

Before writing this, users could select a specific race weekend and insight type by specifying it when running the python project in the command line.

For example:

This would open the qualifying insight and display data from the 2025 British GP (round 12 of the 2025 season). Its a quick way to run the project, but only if you know the round number of the race weekend you want to view. Without it, you had to run another command:

So that’s 2 commands you have to run just to be able to view the data you want. Its slow and, if you’re new to Python, its also a bit complicated. So I decided it was time to build a menu that users could visually navigate.

Existing PRs from the community

The F1 Race Replay community is growing really strong. Over 18 contributors have had their code pushed to the main branch since launching the project, and there have been over 100 Pull Requests containing new features. A few of those PRs contain pretty awesome attempts at building a menu interface for selecting race weekends.

So you might be thinking:

“Tom, why aren’t you using any of those?” - you, probably

Unfortunately, it comes down to how those interfaces were built. A few used the GUI features of the Acrade package, which although lightweight for a simple menu system, aren’t that great when you’re trying to build an interface that needs to be able create the kind of user and developer experience that I want for this project.

Another developer also built a GUI menu using Electron, which (as they mentioned in the PR) is a great opportunity to get Web Developers involved in the project. However, this introduced complexity when creating a seamless transition between the menu and the menu and the Arcade interface.

The Python GUI Dilemma

Building an interface using Python is made possible using a variety of different frameworks and libraries, but choosing the right one depends on your exact requirements and the future of your project.

Here were my options primary options:

Dear PyGui

Pros: Very fast to iterate, minimal boilerplate, great for tool-style menus and controls.

Cons: UI leans more “developer tool” than native app without extra styling.

Toga

Pros: Aims for true native UI across platforms, clean high-level API.

Cons: Smaller ecosystem, slower iteration, more risk of hitting framework limitations.

Dear ImGui

Pros: Perfect for in-app tools and overlays, extremely responsive, pairs well with render loops.

Cons: Not native UI, more setup, can feel “game dev” if not styled carefully.

PySide6 (Qt)

Pros: Most polished and scalable option, huge ecosystem, professional desktop-app feel.

Cons: More boilerplate, steeper learning curve, heavier integration work.

My choice: PySide6

Based on my research findings, I’ve chosen PySide6 as the framework that we’re going to use to build and grow the menu interface for the project.

PySide6 is a bit complicated to work with compared to tools like Dear PyGui or building an interface using HTML and CSS, however, it does offer much more flexibility once you actually figure out how to implement it.

If you’re interested in viewing exactly how I’ve built the GUI using PySide6, you can view the code for it right here: https://github.com/IAmTomShaw/f1-race-replay/blob/main/src/gui/race_selection.py

So now users can start the project by using the “—gui” argument to see the new menu and select their chosen year and round from the interface.

On another note, I’m curious.

The F1 Race Replay project has received a lot of attention, but I want to make sure I’m still putting out the right amount of content that is related to other projects and topics.

If you can, please can you answer the below poll with your preferences? :)

Email Inbox Labeller 📧

My emails can get pretty hectic sometimes. A few months ago I decided I’d had enough of opening my inbox every morning and going through the same process of categorising emails from new contacts into their various categories (“new business”, “admin”, “invoices”, etc).

Every time I open my emails, the extension would check if an email has been categorised in the local storage and display its category. If it hasn’t been categorised, it would ask an AI Agent to categorise it.

Tech Stack

• Language: TypeScript

• Agent: OpenAI Agents SDK

• Database: SQLite

How it works

This Chrome Extension is built using TypeScript. It has a really simple HTML interface which runs the categorisation logic locally. So your OpenAI API key is only stored on your local computer, and there is no need to connect to or pay for any other service to host the backend.

It uses OpenAI’s Agents SDK to analyse the contents of the email subject, sender and preview snippet. The agent has the ability to query similar emails that have been categorised, in an attempt to make the categorisation functionality more intelligent without requiring any super complex sorting or data structures.

Code: https://github.com/IAmTomShaw/email-inbox-agent

Stock tracker Agent 📈

This SMS service notifies me if any of my investments go up or down more that a specified percentage over the course of a day, and (crucially) does the research to let me know why each stock has risen or fallen.

Tech Stack

• Language: Python

• Backend: FastAPI

• Hosting: Amazon Web Services

• SMS Service: Twilio

• Agents: OpenAI Agents SDK

How it works

This project runs as a small backend service and communicates entirely over SMS. It’s built with FastAPI and uses Twilio webhooks so you can text the system directly to add or remove stocks, or ask for current prices. Stock prices are pulled from public market data, and an automated background job checks tracked stocks on a schedule to see if anything has moved significantly.

When a stock crosses a defined threshold (for example, up or down 2%), the system uses OpenAI’s Agents SDK to kick off a research workflow. One agent gathers recent context from the web to understand why the price moved, and another agent summarises that information into a short explanation and sends it via SMS.

Code: https://github.com/IAmTomShaw/stock-tracker-agent

If you’d like to learn more about this project, you can read the newsletter post from last month.

Quotation Agent 💰

Sometimes I’ll spend all day sending out quotes for different project requests that I’ve received over the course of a week. Its a nice problem to have, but takes way too much time.

With the desire of automating as much of the boring bits of my work as possible, I built a chatbot tool that enabled me to submit the requirements that a client has sent me and generate a custom project quote/proposal based on my standard pricing for my services and industry standard rates.

I’m able to send and receive messages from the chatbot, so we can talk about the specifics of the project and come up with the final quote together before sending it to the client.

Tech Stack

• Language: Python

• Interface: Streamlit

• Backend: FastAPI

• Agents: OpenAI Agents SDK

• Knowledge: Notion API (to my pricing doc)

How it works

The project is powered using Python, with effectively two applications built into one. A frontend application to create the sleek looking interface you saw above (built using Streamlit) which uses a WebSocket connection via FastAPI to connect to the simple Python backend which runs the chatbot logic via OpenAI’s Agents SDK.

The Chatbot Agent has access to tools that enable it to retrieve my service pricing information from Notion page, and search the internet for information relating to industry standard pricing and terms.

Code: https://github.com/IAmTomShaw/quotation-agent

NFL Throwing Game 🏈

Earlier this year, I helped to build an activation for the AWS Summit in London. The idea was to build a target game which tests players accuracy and reaction time.

Players would be able to sign up with a staff member, have the game remotely started, have their score accurately measured and then view their results instantly on the digital leaderboard.

Tech Stack

• Leaderboard and Admin Platform: React

• Backend: TypeScript (with Express and Socket.io)

• Game Runner: Python (with dearpygui)

• Microcontroller Language: MicroPython

How it works

Using a set of Raspberry Pi Pico Microcontrollers, some break beam sensors and RGB LED light strips I was able to build the hardware for the project.

Each target hole used a break bean sensor to a ball passing through, and an LED light strip to indicate when a user should throw the ball at that hole (blue), if the user had scored (green flashes) and if the player had missed or ran out of time (red flashes).

Using a laptop stored inside of the structure (running a Python application), I was able to bridge the gap between the cloud-based backend service and the hardware inside of the structure.

Here’s a video explaining a bit more about how it works:

Code: Unfortunately I can’t share this one as its a project for a client.

(Just to be clear, I only built the tech for this project. The idea, construction of the structure and the branding was not handled by me. Only the software and hardware running the game)

F1 Race Replay 🏎️

This project went pretty viral over the past few weeks. If you haven’t heard about it, let me introduce you to F1 Race Replay, an interactive Formula 1 race visualisation and data analysis tool built with Python!

Using the tool, you can re-watch races play out on the track map, while viewing insights into things like weather, car telemetry, flags, safety cars, etc.

It also has the ability to view detailed telemetry from drivers’ qualifying laps and compare the data with another driver.

Tech Stack

• Language: Python

• Data Source: FastF1

• Interface: Arcade

How it works

Using the FastF1 library, all of the raw race data (positions, lap times, speeds, tyre info, etc) is gathered and then normalised onto a single, continuous timeline so every car can be replayed in sync. Because different cars report data at slightly different intervals, the system interpolates positions to ensure smooth, accurate movement throughout the race.

The replay itself is rendered using the Arcade game library, which acts as a lightweight 2D engine. Each car’s position is updated frame-by-frame based on the processed telemetry, while a separate data layer drives the live leaderboard, lap counters, tyre compounds, and race state.

Code: https://github.com/IAmTomShaw/f1-race-replay

If you’d like to learn more about this project, visit this post:

I hope you all have a great holiday period. One more newsletter post to go before the new year, let’s finish 2025 on a high! :)

These types of charts are without a doubt my favourite insight/visualisation of F1 data. I love how they allow us to really get an insight into how a driver is performing and driving the car, especially when the charts can be used to compare multiple laps or multiple drivers.

So I’ve had an idea…

“What if you could do this for go karting?”

Go karting is a huge sport, so of course there are devices and kits that you can buy to attach to your go kart to measure different metrics, however, there are two issues:

1. They’re really expensive.

   Which is not something that I can afford to purchase as someone who’s just interested in the data. Maybe if I was working on building a career as a driver, but I’m not.

2. You aren’t allowed to modify the Karts.

   Go karting centres won’t actually allow you to attach anything to their go karts. (Makes sense for safety reasons, and because they don’t want you to damage their equipment).

While go kart tracks may not allow you to modify or attach equipment to their cars, they do allow you to wear “wearables” such as Smart Watches, GoPros, etc. So as long as I keep whatever sensors and hardware that I need on my person, I should be all good right?

Testing out the idea

During the week, I started experimenting with a spare accelerometer module and a Raspberry Pi Pico.

Using MicroPython, I was able to measure the orientation and the movement of the module (I’m using an MPU-6050 which includes a Gyroscope) and display it on my screen.

How I’m going to build it

So here’s the plan. (It’s still a work in progress)

Based on my initial testing using the Raspberry Pi Pico board and the accelerometer, I’ve determined that by attaching one of these modules to each of my feet, I could use the rotation metrics to measure how far I’m pressing on the throttle and brake of the kart. And, by attaching a single accelerometer to a stable part of my body (jeans pocket for example), I should be able to get a fairly accurate measurement of the G-Forces that I experience as I go around the track.

Mounting the accelerometer to my chest would probably be the most ideal location, but I suspect safety policies might prohibit the use of a chest mount, even it it is under my clothes.

Now, you have to remember that these are consumer rental karts, they’re not going to be super fast, but they should be fast enough for me to at least be able to look at the telemetry and recognise the different corners, straights and ramps (if any) that are on the track.

Limitations (and how I plan to get past them)

It looks like getting the telemetry from the kart is going to be possible using the system that I’ve described above, but that’s only half of the job done.

With that system on it’s own, I have no indication of where I am on the circuit or how fast my lap times are. Two essential bits of information that I’ll need if I want to actually be able to understand the data that I’m collecting.

Unfortunately, the go kart tracks that I go to are usually inside of a building, so using GPS data isn’t a viable option.

In this situation, using Bluetooth Low Energy Beacons seems like a really good option for tracking indoor positioning, but I doubt the venue would let me setup beacons in the corners of the room, and I think that might be overkill for an MVP version. I think adding a GoPro and manually syncing it up with the data will be a much better option anyway.

Another limitation is measuring exact lap times. Usually karting tracks will use break beam sensors to detect cars crossing the start/finish line to accurately measure their lap times. Unfortunately I won’t be able to setup my own break beam sensors, but fortunately, the track I go to sends you an email that includes all of your lap times from the session. So with a bit of manual input, I could add this data into the telemetry.

The next steps.

The side-project is definitely in its early stages, but I thought that it would be really cool to share the idea with everyone in this community and keep you up to date on it’s progress (alongside the development of F1 Race Replay).

So far I’ve purchased the additional sensors and components that I’ll need to be able to start work on hacking this project together.

My hope is that the next time I’m at the go kart track, I’ll be able to take this kit with me and give it a try!

Unfortunately there’s no open-source code to share in this week’s newsletter, but I hope you’re as excited as I am to see how this side-project progresses!

I’ve also got some really cool additions to the F1 Race Replay project coming soon, so be ready for that!

In my previous newsletter post, I outlined what the future of the project looks like and the features that I’d like to prioritise.

So this week, I made a start by adding Qualifying telemetry analysis.

Now you may be thinking:

“Tom, why didn’t you just add the track map showing the cars going around the track during Qualifying?”

Two reasons:

1. I wanted to go the extra mile (pun intended). 😉

2. The real importance of qualifying isn’t about where everyone else is on the circuit, it’s about how each driver performs during their lap as they attempt to squeeze every millisecond of time out of the car.

So to make sure that the tool gives the best insight into the drivers’ laps, I wanted users to be able to view the telemetry that showcases their speed, where they change gear, where they use the throttle and brakes, all plotted to show every little adjustment throughout the lap.

Introducing the “Telemetry Trace” Charts

You’ve probably seen one of these before. They’re used by the engineers to understand how a driver is performing, often overlaid with another driver’s telemetry so that they can see where time is being gained or lost at different points around the track.

The concept is very simple, if you have a dataset which contains the distance that a car has travelled around the circuit, along with the parameters that you want to analyse, you’ll be able to plot the X axis with the distance and use the Y axis to plot any value in the telemetry.

Here’s an example of what that data could look like:

Adding this to F1 Race Replay

So how did this feature get introduced into the project?

Well first I had to do some cleaning up of the code. A little reorganising to make sure that it’s well kept and presentable for anyone that wants to download it and have a look at how it works.

The codebase now has the following structure:

f1-race-replay/
├── main.py                   # Entry point
├── requirements.txt          # Python dependencies
├── README.md                 # Project documentation
├── roadmap.md                # Planned features and project vision
├── resources/
│   └── preview.png           # Race replay preview image
├── src/
│   ├── f1_data.py            # Telemetry loading, processing, and frame generation
│   ├── arcade_replay.py      # UI starter logic
│   └── ui_components.py      # UI components like buttons and leaderboard
│   ├── interfaces/
│   │   └── qualifying.py     # Qualifying session interface (w/ chart)
│   │   └── race_replay.py    # Race replay interface
│   └── lib/
│       └── tyres.py          # Tyre formatting utilities
│       └── time.py           # Time formatting utilities
└── .fastf1-cache/            # FastF1 cache folder
└── computed_data/            # Computed telemetry data

The qualifying interface is completely separate from the race replay interface. So while they share some code similarities in terms of the UI, handling resizing, displaying the cars, etc, they’re very much separate features.

All of the data for this feature is sourced using the FastF1 Python package. And the interface is built using the Arcade Python package. Using a chart library probably would have been easier for this feature, however, embedding an interactive chart into an Arcade interface isn’t as easy… so I opted for creating the charts myself.

How to use the new feature

By passing the “—qualifying” argument when running the Python project, the application will process and display the qualifying data from the relevant race weekend that you select at runtime.

You will then be presented with a leaderboard screen where you can (using your mouse) select a driver and then select their lap telemetry from Q1, Q2 or Q3.

What’s next?

This feature is a really cool addition to the project, and I’m really excited to see the feedback that it gets from the community, but it’s definitely missing something… Comparison Tools.

As I mentioned earlier, these charts are often used to compare the performance of a driver with another driver. So without a doubt the next addition to this project has to be the ability to compare a driver’s telemetry with another driver.

For now though, you’ll have to wait for the comparison feature. In the meantime, check out the Qualifying Replay feature and have a think if there’s anything you’d like to add to the project. It’s open-source, so anyone can download it, add their own code and even submit a pull request to add their work into the main codebase for everyone to see!

You can access the code here: https://github.com/IAmTomShaw/f1-race-replay

Also, congratulations to Lando Norris on becoming the 2025 Formula 1 World Champion! 🏆

So in this week’s edition of Build Notes, you’re going to hear all about how I built this python-based project and what the future holds for it!

Project Idea 💡

F1 Race Replay is an interactive tool that let’s you watch replays of Formula 1 races from above, giving you a better view of everything that’s happening in the race!

Features 🏎️

• Race Replay Visualisation: Watch the race unfold with real-time driver positions on a rendered track.

• Leaderboard: See live driver positions and current tyre compounds.

• Lap & Time Display: Track the current lap and total race time.

• Driver Status: Drivers who retire or go out are marked as “OUT” on the leaderboard.

• Interactive Controls: Pause, rewind, fast forward, and adjust playback speed using keyboard shortcuts.

• Driver Telemetry Insights: View speed, gear, DRS status, and current lap for selected drivers when selected on the leaderboard.

How it’s built 💻

Tech Stack

Language: Python 🐍

Data Source: FastF1 🏎️

Interface: Arcade 🕹️

Data Processing: NumPy 📈

Data Source

All of the RAW data that is used inside of the project is sourced from the FastF1 python package!

FastF1 gives you access to F1 lap timing, car telemetry and position, tyre data, weather data, the event schedule and session results. - FastF1 Website

All of this data is taken in its raw form from FastF1 and put onto a normalised timeline for the entire race, which allows us to know the exact position, gear, speed, throttle pressure, etc of each driver at any given second in the race.

Interface

I decided that I wanted to use Python for the interface so that the entire project could be easily installed and run by users on their own device. Hosting it on a website and having separate applications to process and display data just didn’t feel like the optimal solution this project.

I chose Arcade, which is a python package that enables you to build 2D interfaces. It’s usually meant for games, but was a great option for creating a custom GUI (Graphical User Interface) that used animations and movement.

An alternative that I used in the initial version on my laptop was the animation features inside of Matplotlib, however I felt like Arcade offered more potential for the future features that I want to add in.

Based on the above, you can see why I needed to select a library that gave me a few more customisation options. With Arcade, I don’t think we’re going to be limited by what we can do with the interface, which is great for growing the project!

User Experience

Currently users must start the project by running ‘python main.py —year (year number) —round (round number) in their terminal. As I’ll mention in the next section, another developer has already started working on a feature to introduce a visual menu for selecting a race, so that’s going to be a great improvement for the project if that PR get’s finalised!

Community Response 📜

The response from the community since releasing this project has been MEGA! I made the code open-source to enable people to learn from it and hopefully commit their own features to the codebase… and that’s exactly what you’ve done!

Since launching, we’ve had a developer add a feature to enable users to resize the viewer window (now merged), another developer work on the first version of visual menu for selecting the race that you want to watch (awaiting code review) and another developer work on adding in the ability to view sprint races too (awaiting code review).

At the time of writing, I’m still in the process of reviewing these new submissions.

The future of F1 Race Replay 🚀

I’ve been asked a lot of questions about what the future of this project actually is. After launching something that’s received this much love, it would be silly to stop here.

In my mind, this project is a great opportunity for Developers, F1 Fans and Data-lovers to explore the data behind their favourite sport using their very own hands!

With that mission in mind, here are some feature ideas which I think would be great:

• Telemetry Charts: Showcasing speed, throttle, braking, etc

• Post-Race Reports: Telling the story of the race in a single chart

• Race Control Messages: Understanding exactly what decisions they’re making

• Qualifying Insights: A separate feature in itself, but could be really cool

There is a known issue where the leaderboard isn’t 100% accurate with the drivers’ positions on track. I’m currently looking into fixing this issue.

How you can get involved 🫵

If you’ve got an idea for a feature, make sure to submit it! If it’s cool enough, we can add it to the roadmap and you can even have a go at building it!

Make sure to check out the project on GitHub, and give it a star! ⭐

Link: https://github.com/IAmTomShaw/f1-race-replay

Disclaimer

No copyright infringement intended. Formula 1 and related trademarks are the property of their respective owners. All data used is sourced from publicly available APIs and is used for educational and non-commercial purposes only.

Have a great week. Keep building. See you in the next edition! 😀

Of course that takes up a lot of time.

The idea 💡

Instead of checking my app on a routine, I thought it would be a good idea to get notified every time the value of one of my investments changes significantly.

Now the app does have a feature to receive notifications, but they just tell you about the price change, not why it’s changed.

Ultimately if I’ve lost some money on something I want to know why… so tell me why!

Let’s build it!

Tech Stack 💻

SMS Service: Twilio 💬

Language: Python 🐍

Framework: FastAPI 🚀

Finance API: yfinance 💰

AI Agents Framework: OpenAI Agents SDK 🧠

The Two Functions 🔨

User Message Webhook

As a user, I want to be able to interact with the system to ask for pricing info on demand, or add new stocks to my tracking list. So to do this, I’ve created a webhook which is triggered whenever I send an SMS message from my phone to the system’s phone number.

Message Handler Agent

This agent uses the OpenAI Agents SDK to determine which tools to use based on the user’s instructions and generate a response message to send back to the user.

Here’s an example of what the user (me) sees when they send a message to the designated phone number.

The Automated Stock Price Checker

I’m using a CRON Job to automatically check the price of the stocks in my tracker list every hour.

If the price has changed (up or down) by 2%, we’ll pass the stock to the Stock Research Agent so that we can find out what caused the stock price change.

Stock Research Agent

This agent has the ability to search the web to find out more information on the stock’s sudden movement using the WebSearchTool().

It is instructed to respond with a 160 character message detailing the reason behind the movement.

Summariser Agent

This agent is used to attempt to shorten and format the message that is going to be sent to the user. Pretty simple.

Deployment 🚀

I’ve deployed this project onto a single ubuntu instance and configured it with a domain so that I can add it to the Twilio webhook settings. (instructions included in the GitHub repository.

Check out the code! 🧑‍💻

This project is open-source!

If you’d like to check out the code for this project, you can download the code from the public GitHub repository.

Please make sure you give it a star! ⭐

Check it out here!

The past year has been the year of many things. AI Agents. AI Automation. No Code Tools.

But there’s one thing that is definitely true… Developers don’t recognise this place anymore.

I know I’m not the only one who feels like this. Sometimes it really does feel like working in tech is becoming more like a rat race every day.

The constant need to keep up with the new technologies and stay up to date with the latest tools.

We thought it was hard when new JS frameworks were being released every month, try listening to a new company bang on about their “game-changing AI” which is just an LLM call every single day.

We shouldn’t feel like this.

The thing is, we shouldn’t feel like this, and I don’t actually think the problem is as bad as it seems.

All day every day, we’re being told that the job market is tough, AI is replacing programmers, it feels like constant negativity.

Unfortunately, negativity generates clicks.

Positivity doesn’t really have the same scroll stopping effect. Clicks = Ad views. Ad views = revenue. It’s a shame, but it’s true.

The reality is that the world of software development has changed, not as much as we think, but it has definitely changed. As developers we do need to figure out how to adapt, in the same way that we all did when we first started learning to code.

Falling out of love with coding.

I’m sure that computers (the profession - people who computed numbers) felt exactly the same when computers (the technology) came along, but actually, early computing machines needed people who understood mathematics and large-scale calculation workflows.

Anyone who’s met a vibe coder knows that using an AI coding assistant without having any coding knowledge usually results in either a poor quality product or a security issue.

I think a lot of this is just mental, at least in my head anyway. And it’s caused many of us to fall out of love with building things.

The Path Back to Loving Tech.

So how do we fall in love with this industry?

This answer will be different for some of you, but for me, I’m revisiting what first got me interested in learning to code (building things that make me think “Wow that’s cool” and “Wow I built that”).

Sounds lovely Tom… But practically, what does that mean?

It means:

• Tinkering with things for fun, not with the intention of making a profit

• Exploring new tools because they just might make my life easier or give me an idea

• Sharing my projects to hopefully receive positive feedback from other people

• Building for the sake of building

I’m going on a bit here. My point is that you need to go back to your roots, understand why you started in the first place.

2026 and beyond.

So I don’t think the year 2026 will be the year of AGI. It’ll be the year developers remember why we started building things in the first place. Not for productivity. Not for hype.

For curiosity. For joy. For the magic of turning an idea into something real.