I’m Wayne George, a software engineer in London. I have spent more than a decade building bespoke control systems for large corporate clients, and in 2024 I founded Frontier Consulting to build custom software and AI systems for UK businesses (some of it is on the work page). What follows is the reframing I would rather we started with.

The questions everyone asks

“Write me a follow-up email.” “Summarise this contract.” “Draft a job advert.”

There is nothing wrong with any of these. They save minutes, and minutes add up. But look at what they have in common. In every case a person opens a tool, types a request, reads the answer, edits it and does something with it. The person is still the engine. The work still happens at the speed of one human’s attention, and it stops when they go on holiday.

That is AI as a slightly better keyboard. It makes your existing process a bit faster without changing its shape. If you run a business, the shape is the problem.

The question worth asking

The question I would rather you asked is this: which of our processes should not involve a human at all?

Not “how can AI help my team with their work?” That framing assumes every task deserves a person and just needs a bit of help. Most businesses are full of tasks that do not deserve a person. They got one because, at the time, a person was the only option.

Think about what a human is genuinely for in a business. Judgement. Relationships. Noticing that something is off. Deciding what to do when the rules run out. Those things are worth a salary. Re-keying numbers from one system into another is not; nor is reading forty near-identical enquiries to work out which ones deserve a quote.

The real value of AI, used alongside ordinary software, is that it lets you take whole processes off people’s desks rather than shaving minutes off each step. That only happens if you go looking for processes instead of prompts.

Start from the outcome, not the tool

Here is how I reframe it in practice. It is deliberately unglamorous.

Find the Friday spreadsheet

Every business has one. It is the report somebody compiles every Friday afternoon by copying figures out of three places into a fourth. It is the quote that takes three days because it queues behind the one person who knows how to price it. It is the invoice chase, the timesheet reconciliation, the supplier order that starts as a photo of a whiteboard.

You are looking for work with three properties. It has the same shape every time. The information it needs already exists somewhere, usually in an email, a PDF or another spreadsheet. And it spends most of its life waiting for a person rather than being worked on.

Do not start with “what could AI do here?” Start with “what do we do that nobody would miss doing?” Ask your team. They know exactly which jobs they resent, and resentment is a surprisingly good signal.

Map the inputs and outputs

Take one candidate and write it down, in plain words, as it happens today.

Where does the information come from, and in what form? An email with a PDF attached. A phone call scribbled on a pad. What comes out the other end, and who consumes it? A quote as a PDF. A row in a spreadsheet. What does “done” look like, and how would you know if it had gone wrong?

Then, crucially, list the exceptions. The enquiry with no measurements. The customer on stop. The supplier price that has changed since the list was last updated. Exceptions are where the humans currently earn their keep, and they tell you precisely where a human should stay.

Most people skip this step because it feels like admin. It is the whole job. Once the process is on paper, the technology decisions become almost obvious.

Decide where a model belongs and where plain software belongs

This is the part that gets muddled, because “AI” has become shorthand for all software. It is not, and the distinction matters for cost, reliability and how far you can trust the result.

Plain software is deterministic. Given the same input it produces the same output every time. It is cheap to run, easy to test, and it does arithmetic without ever being confidently wrong. If the input is already structured and you can write the rule down, that is what you want. Pricing a job from a rate card. Moving a row from one system to another. Generating a PDF from a template. None of that needs a language model, and using one for it makes the process slower, dearer and less predictable.

A language model earns its place at the messy edges. When the input is free text, a scanned document, a photo or a voice note. When the task is to read something written by a human and work out what they meant. When the output needs to be written in sentences rather than filled into fields. That is the part plain software has never been able to do.

So the shape of almost every good automation is a pipeline. A model at the front, turning messy human input into structured data. Plain software in the middle, applying the rules and doing the sums. Plain software at the back, producing the document or the message. And a person at the exceptions, looking only at the cases where judgement is needed.

I used the same split when I compiled Grin: A Brief Story, a history of a cryptocurrency assembled from forum archives spanning 2018 to 2025 (I wrote up how). Pulling the posts out through the forum’s API and scoring the topics was ordinary scripting. Reading the ones that scored well and drafting chapters was where the model did work no script could. And the judgement about what the score had missed came from me, and then from the people who had lived through it once the draft was published.

A worked example

Let me make this concrete with an imaginary firm. None of the details are real; the pattern is.

Imagine a twelve-person joinery business in Kent that makes fitted wardrobes and kitchens. Enquiries arrive by email: a few paragraphs of description, some rough measurements and a handful of phone photos. The owner reads each one, works out what is being asked for, checks sheet material prices in a supplier spreadsheet, applies labour rates that mostly live in his head, and types up a quote in Word. Because he also runs the workshop, a quote takes about three days, and a fair number of customers have gone elsewhere by then.

Map it. The inputs are an email (free text and photos), a supplier price list (a spreadsheet), the firm’s labour rates (undocumented, so the first job is to write them down) and a folder of past quotes. The outputs are a PDF quote, a reply email and a new row in the jobs spreadsheet. The exceptions are enquiries with missing measurements, unusual materials, and anything structural that needs a site visit.

Now decide. Reading the email and photos and turning them into a structured job description, with rooms, dimensions, materials, finish and deadline, is model work; nothing else can do it. Pricing that structured job against the price list and the labour rates is arithmetic, so it is plain software, and it will be right every time. Producing the PDF and the covering email is templating, plain software again.

Spotting that measurements are missing is a simple check, and drafting the polite email that asks for them is a small model task. The one place a person stays is at the end, reviewing the priced quote for a minute before it goes out. Is this a job we want? Is the margin right? That minute of judgement is what the owner is actually for.

In our imaginary firm, a quote is ready for review within the hour instead of three days, and the owner’s involvement drops to a few minutes per enquiry. Nobody asked a chatbot to write anything. The process changed shape.

Where it goes wrong

Three mistakes come up again and again.

Asking the model to do the sums. Language models are not calculators, and using them as one is how you end up with a confident, plausible, wrong quote. Do the maths in code and let the model do the reading.

Automating something nobody has written down. If the process only exists in one person’s head, the first deliverable is a description of it, not software.

Removing the human from the judgement step first. It is tempting to start with the interesting bit, the decision. Do the opposite. Take away the re-keying and the reading and leave the person the decision, at least to begin with. Trust in a system is earned by watching it get the boring parts right.

What to bring

The three steps above are the whole conversation, and none of them need a laptop open. Come with a process rather than a tool. Not “we are thinking about AI”, but “every Friday somebody spends two hours copying figures out of three systems into a fourth, and here is how they do it, step by step, including the bit where they have to ring someone”.

Twenty minutes of that is enough to get somewhere useful. What you want at the end is a short list of candidate processes, a rough view of which parts are plain software and which genuinely need a model, and a sense of which one to do first. The first one is almost never the most exciting. It is the one with the clearest inputs and outputs and the most people quietly furious about it. That is the one that pays for the next.

If you run a UK business and you recognise your own Friday spreadsheet in any of this, you can book a free 20-minute strategy session with Frontier Consulting: no obligation and no sales pitch. If you would rather start smaller, the free discovery test on the Frontier Consulting site is three questions and takes about two minutes. Either way, bring the process, not the prompt.

Originally published at https://www.waynegeorge.uk/writing/youre-asking-ai-the-wrong-questions/ by Wayne George.

Where I started

I’m Wayne George, a software engineer in London. I began my career at Row Seven, a company in the AV software industry, which merged with Lucid Partnership in 2016. I have been a software engineer at Lucid since April 2016, building bespoke control systems for corporate clients and working on Blueprint, the company’s control software platform. I also lead the QA team, which is where much of what follows was learnt.

Since January 2024 I have also run my own company, Frontier Consulting, doing custom software and AI work for UK businesses, and I publish iOS apps under my own name. The things I have built come out of the same habits, whatever the size of the room.

If you have never worked in AV, the short version is this. Modern meeting rooms, auditoriums and event spaces are full of equipment: displays, cameras, microphones, video conferencing codecs, audio processors, lighting, blinds, room booking panels. Somebody has to write the software that makes all of it behave as one system, so that a person walks in, taps “Start meeting” on a touch panel, and everything simply happens. For more than ten years, that somebody has been me.

The tools of that trade are specialised. Crestron processors are programmed in SIMPL and its extensions: SIMPL+, which will feel familiar to anyone who knows C, and SIMPL#, which bridges the processor to C# itself, because Crestron builds its control systems on the Microsoft .NET framework. Q-SYS audio and control platforms are scripted in Lua. I hold Crestron’s Certified Programmer (Masters) qualification from 2017, a Q-SYS advanced Lua scripting certification, and a Microsoft Certified Professional qualification in C# programming.

The clients I have built control systems for at Lucid include Google, Apple, UBS, JPMorgan Chase and Morgan Stanley. I will not go into specifics about any of them; that is not how this industry works. The point is what those environments demand.

Lesson one: the room is unforgiving

Software in most contexts gets a second chance. A web page can show a spinner. A mobile app can retry quietly in the background. A boardroom cannot. When the meeting starts at nine, the system either works at nine or it has failed, and the failure is public, immediate and expensive. There is no “refresh”. There is a room full of senior people looking at a facilities manager who is looking at you.

That shaped a habit I have never lost: I assume the worst moment is the one that will happen. The network will drop mid-call. A display will be switched off at the wall. Someone will press three buttons in an order nobody anticipated. If the system cannot survive that, it is not finished.

AI systems for businesses are the same, except that the failure is quieter and therefore more dangerous. A language model that invents a figure in a customer email, or confidently approves something it should have flagged, does not go black. It carries on. The people relying on it may not notice for weeks. So the discipline is the same: assume the worst input will arrive, and build for it before it does.

Lesson two: deterministic behaviour is the whole product

The most valuable property a control system can have is that pressing the same button produces the same result, every time, in every room. Not most of the time. Every time. Most of the engineering effort in a serious control system goes into exactly that: no way to drive the system into a state that should not exist, sequences that always complete or roll back cleanly, and interfaces that report what the equipment is actually doing rather than what we hope it is doing.

Large language models are, by design, not deterministic. The same prompt can produce a different answer on a different day. That is fine for brainstorming and a real problem for a business process. So the way I build AI systems now looks a lot like the way I build control systems: a deterministic shell around a probabilistic core.

The model does the part only a model can do, such as reading an unstructured document or drafting a reply. Ordinary, testable code does everything else. Validation, business rules, permissions, and anything that touches money or a customer record live in plain code, where they behave the same way every time. In AI circles these are called guardrails. To me they are simply the control layer, and the model is one more device on the network that cannot be fully trusted to report its own state.

Lesson three: test as if the room is full

Leading QA in AV has taught me that testing is not a phase; it is a protocol. Commissioning a room properly means exercising every function against a written plan: every source to every display, every failure path, power loss and recovery, what happens when a device is unplugged mid-sequence. You do not sign off because it worked when you tried it. You sign off because a documented set of checks passed and somebody put their name to it.

For AI systems the equivalent is an evaluation suite: a fixed set of realistic inputs, including the awkward ones, each with an expected outcome, run every time the prompt, the model or the surrounding code changes. Model providers update their models. A system that passed in March can drift by June without anyone touching it. If you cannot re-run your checks in an afternoon, you do not really know what you have shipped.

Lesson four: fail gracefully, and out loud

When a control system loses contact with a device, the wrong response is to pretend nothing happened, and the next-worst is to lock up entirely. The right response is to degrade: keep the parts that still work working, tell the user clearly what has failed, and give them a way forward, even if that way forward is “call this number”. A blank screen with no explanation is the worst outcome, because it leaves people guessing.

I apply the same rule to AI. Every step that calls a model needs a defined fallback. If the model is slow, unavailable, or returns something that fails validation, what happens next? Sometimes the answer is to retry with a stricter prompt. Sometimes it is to fall back to a simpler, rules-based path. Very often it is to stop and hand the item to a person, with the context they need to finish the job in seconds rather than minutes.

Keeping a human in the loop is not an admission of failure. It is the same instinct as putting a physical help button on a touch panel. The system should know the limits of its own competence and act on them.

Lesson five: if it is not written down, it does not exist

A control system can run for years. The person who maintains it in year four is rarely the person who wrote it. In AV, documentation is not a nicety; it is how a room gets fixed at seven in the morning by somebody who has never seen it before. Drawings, address schedules, the reasoning behind odd decisions, the exact order of a start-up routine: all of it needs to live somewhere other than one engineer’s head.

AI systems have an extra documentation problem. Much of the behaviour lives in prompts, which are easy to edit and easy to lose. I treat prompts as source code: versioned, reviewed, and tied to the tests that prove they work.

I also insist on observability. Every model call wants a record of its input, output, latency and cost, so that when someone asks “why did the system do that?” there is an answer. In a control room the equivalent is the device log that tells you the codec dropped at three minutes past nine. In AI it is the trace that tells you which document the model was actually looking at when it produced the wrong figure. That need only grows when several models are working at once, which is a subject in its own right and one I have written about separately.

Lesson six: “the touch of a button” is a promise you have to keep

The phrase every AV brochure uses is “at the touch of a button”. It is true, and it hides an enormous amount of work. Behind one button on a panel might sit a dozen devices from a dozen manufacturers, a handful of edge cases nobody documented, and a room design that changed twice during the build. The user experiences none of that, which is exactly the point. Simplicity on the surface is bought with complexity underneath, and somebody has to own the complexity.

AI has its own version: “just ask it”. Behind a genuinely useful business assistant sits retrieval from the right documents, permissions so that the model only sees what that user is allowed to see, integration with the systems that hold the real data, and the guardrails, fallbacks and logging described above. Anyone who tells you the model is the hard part has not shipped one. The model is the display. The integration is the control system.

What this means if you are buying an AI system

If you are weighing up AI for your business, here is the practical version of everything above. Ask the supplier what happens when the model is wrong. Ask how the system is tested when the model changes. Ask what you will be able to see when something goes wrong, and who gets told. Ask where a person can step in. If the answers are vague, you are being sold a demo, not a product.

That is the standard I hold myself to at Frontier Consulting, and it is the standard I learnt in rooms where there was no hiding from a failure. The tools have broadened: alongside SIMPL+ and Lua I now work in Swift, TypeScript and Python, and the devices include models and APIs. The job has not changed. Make it work every time, make it fail well when it cannot, and make sure somebody can understand it later.

Originally published at https://www.waynegeorge.uk/writing/from-control-rooms-to-ai/ by Wayne George.

I’m Wayne George, a software engineer in London. By day I build control systems, and through Frontier Consulting I build custom software and AI systems for UK businesses. Mood Share is one of the two apps I publish on the App Store; it went up in May 2024, it is free, and its source is public on GitHub, so nothing here has to be taken on trust. Public to read, that is: there is no licence file in the repository, so it is source available rather than open source.

What the app actually does

A check-in is a card, and filling one in takes three screens. The first is the score: a wheel from one to ten, each number paired with a face. The second is headed “Select words” and offers a list of twenty-eight, running from Happy, Hopeful and Calm through to Anxious, Lonely and Overwhelmed; you tap as many as fit. The third asks for the “Reason for your score”, in your own words. The finished card shows the score, the words and the reason, and the card is what you share. Cards collect on the Home tab, are charted over the past 7 or 30 days under Analytics, and are kept in an Archive you can scroll back through. A daily reminder nudges you if you have not logged anything.

That is the whole feature set. The app has two jobs: letting a partner or a family member know your mood before you get home, and tracking patterns you might want to reflect on or take to a therapist.

Why on-device only

Start with the data. The app records how a person feels, every day, in their own words. That is about as personal as data gets, and the honest question is not “how do I protect this on my server?” but “why is it on my server at all?”

I could not find a reason. Neither of the app’s jobs needs a copy of the data anywhere except the phone, and once I accepted that, a great deal of work simply disappeared: no user database, no password reset flow, no data subject access requests, no breach that could ever include Mood Share, no server bill, and no privacy policy that needs a lawyer. The policy is a few lines saying the app collects no personal data, because it does not.

Apple’s rules push the same way. Guideline 5.1.1 of the App Store Review Guidelines says: “If your app doesn’t include significant account-based features, let people use it without a login.” Most apps treat that as a hurdle to argue past. I treated it as the design.

An account is also a promise: that data will follow someone to a new phone, survive a reinstall and be recoverable when they forget a password. Each of those is a system you have to build and then operate for years. No account, no promise.

SwiftData instead of a backend

The app is written in SwiftUI with SwiftData for storage, which is why it requires iOS 17 or later. SwiftData sits on top of Core Data’s persistence and lets you declare your model layer with macros, which removes most of the boilerplate that used to make local storage feel like more effort than calling a REST API.

The entire schema for Mood Share is one class. The initialiser, which only supplies defaults, is omitted here:

@Model
class Card: Identifiable {
    var date: Date
    var complete: Bool
    var score: Int
    var words: [String]
    var positives: String
    var liked: String
    var toShare: String
}

The reason you type on the third screen lands in toShare. Two of the other fields, positives and liked, appear only in the model and in the sample data used for previews; no screen in the app reads them. An unused column in a local store costs nothing, so they stay.

The app attaches a container at the root with .modelContainer(for: Card.self), views read cards with @Query, and a new check-in is a modelContext.insert(...). There is no repository layer, no networking code and no cache invalidation: the store is the source of truth, and it lives in the app’s own sandboxed container on the phone.

Two things about that store matter. The first is that being on the device buys you encryption you did not have to write. In Apple’s own description, “every time a file on the data volume is created, Data Protection creates a new 256-bit key (the per-file key) and gives it to the hardware AES Engine, which uses the key to encrypt the file as it’s being written to flash storage” (Apple Platform Security). The second is that a SwiftData store can be synced through iCloud, but only if you opt in: the framework “requires two separate capabilities to perform automatic iCloud sync: the iCloud capability, which lets you configure CloudKit, and the Background Modes capability, which lets your app receive remote notifications from CloudKit” (Syncing model data across a person’s devices). Mood Share adds neither; the project has no entitlements file at all. That was a choice, and I come back to it below.

The reminders follow the same pattern: local notifications scheduled on the device with a calendar trigger (UserNotifications), so there is no push server and no device token to store. The only other persistent state is two values in UserDefaults: the appearance setting and the date you last logged a mood.

What “sharing” means without a server

The name sounds as though it needs a network: accounts, a contacts list, and a server that pushes your mood to your partner’s phone. That design would have needed everything I had just avoided.

Instead, sharing in Mood Share is an image. When you tap Share, the app takes a snapshot of the card as it appears on screen and hands it to the standard iOS share sheet, UIActivityViewController. From there it goes wherever you already talk to that person: Messages, Mail, or any messaging app you have installed. The social network destinations are excluded from the sheet, because a mood card is meant for one person, not a feed. The recipient does not need the app or an account, and nothing passes through anything I run. Showing a therapist how a month has gone works the same way: you show them the phone, or you send them the cards.

Rendering the card is the least glamorous code in the project: a small UIView extension that opens an image context and calls UIKit’s drawHierarchy(in:afterScreenUpdates:) to snapshot the view into it. SwiftUI’s ImageRenderer has been in the framework since iOS 16, so it was there from the first line of an app that requires iOS 17; it would have done the same job without dropping into UIKit, and I reached for the UIKit route out of habit. The lesson is that “sharing” is very often just “export in a format the other person can already open”; you do not need a protocol when a picture will do. The one bug fix I shipped after launch was to this flow. Version 1.0.2 went out four days after release, and its release note is the whole story: “Bug fix: Initial share attempt failure now fixed.”

The App Store privacy label

Every app on the App Store carries a privacy section, and Mood Share’s is the shortest kind there is: “The developer does not collect any data from this app.” Both of the apps I publish carry that line, NVR Companion as well. It is worth being clear about what it does and does not say.

What it says turns on Apple’s definition of “collect”, which “refers to transmitting data off the device in a way that allows you and/or your third-party partners to access it for a period longer than what is necessary to service the transmitted request in real time”; by the same definition, “data that is processed only on device is not ‘collected’ and does not need to be disclosed in your answers” (App privacy details). So an app can handle deeply personal data and still truthfully carry that line, as long as the data never leaves the phone. That is where Mood Share stays.

What it does not say is that anyone has checked. The information is self-reported, and Apple says so directly: it “is self-reported by the developer” (About privacy information on the App Store). That is one reason the source is public. If you want to know whether the claim is honest, you can read the code and search it for a networking call: every import across the app’s Swift files is an Apple framework, and the Xcode project does not declare a single package dependency. For a mood app, that is a better promise than any policy.

The trade-offs

None of this is free, and the costs deserve stating plainly.

There is no sync. Your cards live on one phone. If you get a new one and do not restore from a backup, the app starts empty.

There is no recovery I can offer. Delete the app and the cards go with it. Lose the phone and the only route back is your own device backup: “iCloud Backup includes app data for the apps you’ve downloaded on your device” (What does iCloud back up?), so a restore brings the store back with it. That is Apple’s mechanism rather than mine, and it depends on backups being switched on. Nobody can email me for their history, because I have never had it.

There is no telemetry. Nothing in the app reports back, so I only find out what is wrong when someone tells me at hello@waynegeorge.uk or leaves an App Store review. That slows improvement down, and I accept it.

Sharing is one-way and manual. Nobody learns you are having a bad day unless you choose to tell them. Some people would prefer that to be automatic; I think manual is healthier, but it is a real difference.

Most of these could be solved with iCloud sync, which SwiftData makes fairly painless and which would keep the data in the user’s own Apple account rather than on a server of mine. I may still add it. But it would have to be opt-in, it would turn a one-sentence privacy answer into something that needs explaining, and it would introduce the first class of bug I cannot reproduce on my own phone. For version one, the simpler promise was worth more than the feature.

Why this should be the default

I am not arguing that every app should work like Mood Share. Plenty are genuinely about collaboration, or about data that only makes sense on a server. I am arguing that for apps whose data is about one person, “on the device, no account, nothing collected” should be where you start, and the burden of proof should sit with every feature that wants to move away from it.

Three reasons. First, the platform now makes it the easy path: SwiftData for storage, Data Protection for encryption, local notifications for reminders, the share sheet for getting things to other people. The convenience used to live on the backend; for personal data it no longer does.

Second, you cannot lose what you do not hold. Every breach notice you have ever received was for data that somebody decided to keep. Not keeping it is the only mitigation that works every time.

Third, trust. A mood tracker asks people for the most honest thing they have. If the truthful answer to “where does this go?” is “nowhere”, they will tell it the truth, which is what makes the app worth using.

Originally published at https://www.waynegeorge.uk/writing/ios-app-with-no-accounts-and-no-data-collection/ by Wayne George.

I’m Wayne George, a software engineer in London. I wrote an open-source Grin wallet for iOS, so this was a project I cared about rather than a demo, and you can read the result at /grin-a-brief-story.html. The grin-book repository on GitHub holds the finished book as Markdown, EPUB and HTML, the ten chapters beside the raw source files they were drafted from, the two scoring files, the attribution notice and the script that builds the EPUB. It does not hold the fetching and scoring code itself, so what follows is a description of the method rather than a tour of the repository.

Why a book

Grin is the first implementation of the Mimblewimble protocol (I have written a plain-English explainer if the name means nothing to you). The whitepaper was shared in the #bitcoin-wizards IRC channel on 1 August 2016 by a pseudonymous user; the genesis block was mined on 15 January 2019; and Ignotus Peverell, the developer who started the project, “disappeared and has yet to return”. The community has run it ever since.

Projects like that do not write their own histories. When contributors drift away the context goes with them, leaving thousands of threads that only make sense if you were there. I wanted one narrative someone could read on a Kindle in an evening.

My first attempt was a retrieval system: index every post, then ask it questions. It worked, but it only ever answered what I thought to ask. A book forces a decision about what matters, and that decision turned out to be the hard part.

Getting the posts out of Discourse

The forum runs on Discourse, which describes itself plainly: “Discourse is backed by a complete JSON api. Anything you can do on the site you can also do using the JSON api.” Every topic page has a JSON twin — append .json to its URL and the posts come back as structured data, with no key needed for public content.

With Claude Code I wrote a fetcher that walked the topic listings year by year, pulled every post for every topic and saved one JSON file per topic in a folder per year. That gave me 2,930 topics from 2018 to 2025 and 33,658 posts between them. The launch year, 2019, was by far the loudest, with 1,064 topics on its own. Those fetched files are not in the repository, but the scoring output is, and it still records the per-year path each topic was saved to.

Scoring topics for significance

Thirty-three thousand posts will not fit in any model’s working memory, and they should not: most are price chatter, mining questions and broken wallets. I needed a way to find the threads where something actually happened.

The scoring pass gives each topic a single number, and the file it writes records what went into it: views, replies and likes; which of the project’s core contributors posted; and keyword matches across nine themes — wallets, privacy, governance, proof-of-work, launch, emission, the protocol itself, hard forks and conferences. The full output is all_topic_scores.json. The 150 topics that made the cut are in selected_topics.json, spread across ten chapters running from “MimbleWimble Origins” to “Legacy & Future”.

It is worth being honest about how crude this is. The highest-scoring topic in the whole forum is a 1,061-post market shitposting thread, which matched none of the nine themes and got there on engagement alone. Engagement measures heat, not importance, and no formula was going to know that a quiet two-post announcement mattered more than a hundred-post argument. That is a judgement, and judgement is exactly the thing you cannot outsource.

Drafting with Claude Code

For each of the ten chapters the pipeline produced a raw file: the selected topics in date order, each under a header giving the forum link and its score, with every post reproduced under its author and date. The raw material for the governance chapter runs to about 300 KB; the finished chapter is 6 KB.

Claude Code is Anthropic’s agentic coding tool, which by its own documentation “reads your codebase, edits files, runs commands, and integrates with your development tools”. I used it with Claude Opus 4.5, released two months earlier. Every chapter had the same job to do: turn the raw file into narrative non-fiction, quote the forum verbatim where the original words beat a paraphrase, and credit every quote to the username that wrote it. The raw files sit beside the final chapters in the repository (01_raw.md next to 01_final.md, and so on), so anyone can check a claim against its source.

I also asked for the book to be concise, and that is where the trouble started. As I put it on the forum afterwards: “I did ask for it to make it concise and it clearly didn’t make the best choices in terms of what to leave out.” My first pass had no mention of the two anonymous 50 BTC coinbase donations to the project, which anyone around at the time would remember. I put them back before publishing. I did not catch everything, as you will see.

Building the EPUB

The book had to work on an e-reader, so create_epub.py stitches the ten final chapters into an EPUB with the Python ebooklib library. It converts the Markdown to HTML with a deliberately small set of regular expressions, adds an introduction page and the attribution notice, applies some Kindle-friendly CSS and writes out the file. I wrote it with Claude Code. It is 247 lines of boring, well-specified plumbing: the kind of work an AI assistant is unambiguously good at, and the kind I no longer want to type myself.

Licensing: the forum decided for me

Before publishing, I read the forum’s terms. The Grin forum’s Terms of Service state that “User contributions are licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.” That licence carries through to anything built on the posts, so the book is CC BY-NC-SA 3.0 too. In plain terms: anyone may share and adapt it; they must give credit; they may not use it commercially; and anything built from it must carry the same licence.

That suits the project. The book cannot be sold, by me or by anyone else, and the attribution notice on its last page sets out how quotes are credited — beside the excerpt, naming the author’s username, the source thread and a link to it, and at section, chapter or appendix level where material has been summarised. The original words still belong to the forum’s contributors.

What the community caught

I posted the book to the forum on 27 January 2026 and invited forks and pull requests. The thread turned into the best review process I could have asked for.

John Tromp, who designed the Cuckoo Cycle proof-of-work that Grin is built on, replied within two hours, generous about the writing and precise about the gaps. Grin’s ASIC-resistant proof-of-work was modified at each of the first three six-monthly hard forks to “interrupt possible ASIC development for it”; the fourth, in January 2021, brought no new algorithm. The book, Tromp wrote, “leaves out mention of the 3rd member of the cuckaroo family. In between cuckarood and cuckarooz there was room for cuckaroom:-)” Cuckaroom was unveiled at GrinCon1 in November 2019 for the second hard fork, and as he put it at the time, its graph “is no longer bipartite, with the ‘M’ standing for ‘Monopartite’”.

He also pointed out, fairly, that the book had cast him as the proof-of-work person when he had “co-architected and worked on several parts of the consensus code besides cuckoo”: the emission, the Merkle Mountain Ranges the chain stores its data in, difficulty adjustment, the transitions between proof-of-work algorithms and the fee system. “I consider myself a core developer as well.” The draft had reduced a core developer to his best-known invention, and I had not noticed.

Two days later another member said the book was missing the inflation bug, “since that also tells something about how the project is run.” They were right. On 18 March 2021 an attacker got a malicious output into block 1,136,081 by exploiting a flaw in the rangeproof verification cache: affected versions would “skip verification of a rangeproof for an output commitment if that rangeproof had recently been verified, even if the earlier verification was for a different output commitment” (Grin security disclosure).

Grin++, the independent C++ implementation, had the validation the Rust node lacked and rejected the block; hotfixes removed the caching, and the attack “was ultimately mitigated with a longer proof-of-work chain with proper validation”. A history of Grin cannot leave out an incident that shows both the risk of hidden amounts and the value of two independent implementations. I added a section on it and pushed the change the same day. The current version covers Cuckaroom properly too.

One more thing came out of the thread. A reader could not reach GitHub from where they were, so I now keep an HTML version on this site, the copy linked above, updated as the book changes.

What AI is good at here, and what it is not

Having done this once, I would split the work three ways.

The mechanical work

The model does this better and faster than I would: fetching thousands of topics, structuring them, writing the scoring and EPUB scripts, converting formats. There is no reason for a person to type any of that.

The reading

It does this at a scale a person cannot match. Given all 150 selected topics, 10,842 posts between them, it produced a draft with a consistent voice that quotes accurately from the source. By hand I would have skimmed, and missed more than it did.

The judgement

It does not do this, and it does not know that it does not. Told to be concise, it cut things it had no way of weighing. It could not see anything that happened away from the forum: GitHub threads, chat rooms, conference corridors. It tends to reduce a person to the one thing they are best known for, which is how the early draft treated John Tromp. Its prose is confident whether or not the record underneath it is. And the significance score it worked from was my design, with my blind spots built into it.

What fixed those problems was not a better prompt. It was the people who lived the history reading the draft and saying what was wrong, and the forum thread did in two days what no amount of re-running the model would have done. If you try this for your own community, publish early, in the open, under a licence that lets people correct it, and treat the first version as a question rather than an answer.

Where to find it

The book is at /grin-a-brief-story.html, there is an EPUB for e-readers, and the Markdown and the working files are in the repository. It will keep being wrong in places until someone tells me where; pull requests are welcome. If the tooling interests you more than the history, a public data source, a scoring pass, a drafting pass and a person checking the result is the same shape of work I build for clients at Frontier Consulting.

Originally published at https://www.waynegeorge.uk/writing/compiling-a-book-from-eight-years-of-forum-posts-with-claude-code/ by Wayne George.

One caution first: I am an engineer, not an accountant. Everything below comes from HMRC’s published guidance, with links so you can check it, but it is not tax advice.

What Making Tax Digital for Income Tax is

Making Tax Digital for Income Tax (often shortened to MTD ITSA) does not change how much tax you pay. It changes how you keep records and how often you tell HMRC about them. Instead of one Self Assessment return in January, you keep records digitally, send HMRC a summary four times a year through software, and finish with a tax return, also through software.

HMRC’s guide Use Making Tax Digital for Income Tax covers the four core stages: create digital records, send quarterly updates, adjust your self-employment and property income, and submit your tax return. I’ll take each in turn, but first the question most people ask: does this apply to me, and when?

Who is affected, and when

The rollout is phased by “qualifying income”: your total income from self-employment and property combined, before expenses, taken from the tax return you submitted for the earlier year. PAYE employment income, dividends (including from your own company), the State Pension and private pensions do not count. The details are on the qualifying income page.

The timetable, as set out on the eligibility page, is:

• Qualifying income over £50,000 in the 2024/25 tax year: you should have started from 6 April 2026.
• Over £30,000 in 2025/26: you start from 6 April 2027.
• Over £20,000 in 2026/27: you start from 6 April 2028.

So if your gross income from self-employment and property together was over £50,000 in 2024/25, you are in the first cohort and your first quarterly update was due on 7 August 2026. If you have not done anything yet, HMRC has said that from September 2026 it will start signing up anyone who needs to use the service for 2026/27 and has not signed themselves up. It only uses the information it already holds, so if your circumstances have changed since your last return you will need to correct them.

Some people can be exempt, for example if they are digitally excluded, and there is a process to apply for an exemption. If you are exempt you still file a Self Assessment return as normal.

The four things you have to do

Keep digital records

Every transaction needs three things in your software: the amount, the date the income was received or the expense incurred, and a category that mirrors the Self Assessment return. There are some sensible simplifications. If you make retail sales you can record daily gross takings rather than every individual sale, and if turnover from a source is under £90,000 you can use simpler categorisation and record only whether each transaction is income or an expense. Full details are on the digital records page.

Spreadsheets still count, as long as data moves into your submission software through digital links (linked cells, CSV import and export, an emailed spreadsheet, an API) rather than by retyping. Once a record has been sent to HMRC in a quarterly update you must not move it by hand. Records have to be kept for at least five years after the 31 January deadline for that tax year.

Send quarterly updates

By default the update periods follow the tax year, and each one runs from 6 April rather than from the end of the previous quarter, with these deadlines:

• 6 April to 5 July, due 7 August
• 6 April to 5 October, due 7 November
• 6 April to 5 January, due 7 February
• 6 April to 5 April, due 7 May the following tax year

If your accounting period runs from 1 April to 31 March you can use calendar quarters instead (1 April to 30 June, and so on), with the same deadlines. Notice that updates are cumulative, covering the year to date rather than the last three months. That is a good design decision, because a mistake in an earlier quarter is corrected simply by sending the next update with the right totals. HMRC receives only the totals for each income and expense category, not your individual receipts and invoices. The quarterly updates page has the full list.

Adjust and submit your tax return

After the fourth update you make any year-end adjustments to your self-employment and property figures, add every other source of income and gains, review HMRC’s tax calculation, and submit the return through your software, declaring that it is correct and complete. The deadline is unchanged: 31 January following the end of the tax year. Elsewhere you may see this stage called the “final declaration”; HMRC’s current guidance simply calls it submitting your tax return.

Use compatible software

All of this has to go through software that talks to HMRC. HMRC distinguishes between software that creates and stores your records (by linking to a bank account, scanning receipts or manual entry) and “bridging” software that connects to records you already keep in a spreadsheet. Free products exist for people with simple affairs, though they may cap the number of transactions. The compatible software page links to HMRC’s finder tool, which is the list you should trust.

Penalties

There is a soft landing. HMRC’s penalties page says there are no penalties for missing a quarterly update deadline in the 2026/27 tax year. From 2027/28, each missed quarterly update or tax return deadline earns a penalty point, and at four points you get a £200 penalty, then £200 for each further missed deadline.

Late payment is treated separately and applies from the start. For 2026/27, tax paid up to 15 days late attracts no penalty; from day 16 it is 3% of what was owed at day 15 (waived in your first year); after 30 days a further 3% of what was owed at day 30 is added, plus an annual rate of 10%, charged daily from day 31 until you pay or for up to two years. For 2027/28 the two percentages rise to 4%.

Why I built my own tool

I run a small consultancy, Frontier Consulting, and I write iOS apps in my own time; some of them are on the work page. The best way I know to understand a system is to build against its API, and this one is about to touch a great many small businesses. So one of my side projects is a Making Tax Digital app for UK self-employed submissions: income and expense tracking, quarterly HMRC integration, and tax estimates.

I should be blunt about what that is. It is a personal project, still in progress, not a product. HMRC has said it is no longer accepting production credential access requests for new 2026/27 quarterly update products, because the market window for those products has closed, so no new tool can be recognised for this tax year in any case. If you need something for your own return, use the finder tool above.

What the developer documentation tells you

The developer documentation is worth knowing about even if you never write a line of code, because it shows how the pieces are meant to fit together, and HMRC’s developer hub is unusually good at explaining itself. The end-to-end service guide walks through the whole process, from signing a user up to submitting their return, and the Self Employment Business API (version 5.0 at the time of writing) carries the quarterly and annual submissions.

Authorisation is standard OAuth 2.0 with the authorisation code grant. HMRC’s page is admirably terse about the timings: “An access token lasts 4 hours”, and “After 18 months, refresh tokens stop working. At this point, you must go through the authorisation process again.” That is worth knowing as a user and not only as a developer. You sign in to HMRC, not to your bookkeeping software, and the permission you give it is not permanent. There is also a sandbox at test-api.service.hmrc.gov.uk, where a Gov-Test-Scenario header makes the service return a chosen outcome, so the awkward paths can be exercised without going anywhere near a real tax record.

Two features of the design shape anything built on top of it. The first is the cumulative model. Because every update covers the year to date, MTD software is not really a submission tool at all; it is a ledger that has to be right at every point in the year, from which a submission falls out almost as a by-product. A tool in this space has to answer three questions at any moment: what has come in, what has gone out and under which category, and what those two imply for the eventual bill. The third is cheap once the first two are accurate, which is why tax estimates are such a common feature, mine included.

The second is the fraud prevention headers. HMRC is direct about this: “You are required by law to submit header data for the VAT (MTD) and Income Tax Self Assessment (MTD) APIs.” The headers carry audit data about the device and connection a submission came from, and which ones you must send depends on how your software connects — a desktop application talking straight to HMRC has fourteen of them to supply, covering everything from local IP addresses and MAC addresses to screen sizes and whether multi-factor authentication was used. HMRC runs a whole separate Test Fraud Prevention Headers API for checking them, which “checks the value and format and gives you feedback on any issues”. When a specification comes with its own validation service, that tells you something about how easy it is to get wrong. This is a proper piece of work, not a tick-box exercise.

There is one more thing I keep coming back to, and it is about behaviour rather than code. Whether or not HMRC planned it this way, a system that makes you total up your year four times is also a system that makes you look at your likely bill four times, and I suspect that will change more about how sole traders run their finances than any of the filing mechanics.

A practical checklist for 2026/27

If you are a sole trader in the first cohort, or think you might be, here is what I would do this month.

1. Work out your qualifying income for 2024/25 from the return you submitted: self-employment turnover plus property income, before expenses. Over £50,000 means you are in.
2. Sign up for Making Tax Digital for Income Tax if you have not already. If HMRC signs you up automatically, check that the business details it holds are still right.
3. Pick compatible software from HMRC’s finder tool. If you already keep a spreadsheet you are happy with, bridging software may be the least disruptive route.
4. Get your records from 6 April 2026 onwards into it, with amount, date and category for each transaction. If turnover from the source is under £90,000, income-or-expense is enough.
5. Send the first update now if you missed 7 August. There is no penalty this year, and because updates are cumulative one update covers the year so far.
6. Put 7 November 2026, 7 February 2027, 7 May 2027 and 31 January 2028 in your calendar.
7. Set money aside for the tax as you go. Late payment penalties still apply this year: only the first 3% is waived in your first year, and the day-30 penalty and the 10% annual rate build up from there.
8. If you use an accountant, ask them now how they want to handle the updates. They can sign you up and submit on your behalf.

Where to go from here

The rules are less frightening than the acronym. Keep digital records, send four cumulative updates, file the return through software, and pay on time.

What the deadline really exposes is how much bookkeeping is still done by hand in small firms, which is a much older problem than MTD; I have written separately about where automation pays off first in a small firm. If you would like to talk about the record-keeping side of it for your own business, the about page has ways to get in touch.

Originally published at https://www.waynegeorge.uk/writing/making-tax-digital-for-the-self-employed/ by Wayne George.

Mission Control is the dashboard I built for that. It is a real-time view of multi-agent work with six things on the page: project heat-maps, agent orchestration, service health, a document viewer, interactive to-dos and usage tracking. The server is Express, the front end is plain HTML, CSS and JavaScript, and it is a personal tool rather than a product.

I’m Wayne George, a software engineer in London. I build custom software and AI systems for UK businesses through Frontier Consulting, and I use agents heavily in my own work; Mission Control sits with my other projects on the Work page. What follows is not a tour of the code. It is the problem the tool exists to solve, the questions any dashboard of this kind has to answer, and what I would tell you if you were about to build your own.

Why a single chat window stops working

A chat window is designed for one conversation with one participant who waits for you. Run several agents and it fails in three ways.

First, you lose the thread. Each transcript is a linear scroll, so switching between three of them means re-reading the tail of each to work out where it got to. The reading is not the work, and it grows with every agent you add.

Second, you lose track of side effects. An agent that can write files, run commands and make commits is changing things, and in a transcript those changes arrive as a line of prose: “I’ve updated the config.” Which config, in which project, and did something else touch the same file twenty minutes later? The window cannot tell you, because it only knows about itself.

Third, you lose sight of cost. Every exchange is a bill you cannot see while you are running it up, and a long task against a large codebase is a very different bill from a chat about wording.

The interface is the problem, not the agents. So the fix is a different interface.

The three questions

The temptation with a dashboard is to show everything, which produces a wall you stop reading by Wednesday. The discipline is to decide what you would want to know if you glanced at the screen for four seconds while making tea. For me that comes down to three questions per agent: what is it doing, what has it touched, and what is it costing me? The six things on the page are there because each answers part of one of those.

What is it doing: agent orchestration

The orchestration view answers the first question, and the point of it is that it is not a transcript. A transcript tells you what an agent said. A status tells you whether it is working, whether it has finished, and whether it is stuck waiting for a human — and that last state is the one worth building a whole screen for. An agent blocked on a question it needs answering is achieving nothing while the meter runs, and it is exactly the state a row of terminal tabs hides best. If a dashboard like this does nothing else, it should make “waiting on you” impossible to miss.

Where is the effort going: project heat-maps

A heat-map is a crude instrument and that is its virtue. Projects as tiles, warm where there has been activity and cold where there has not, and you can see at a glance that three agents have piled into one repository while the project you promised somebody you would look at has been grey all day. There is no fact on that screen you could not get from a list, but nobody reads the list. Attention is the scarce resource in this kind of work, and a picture of where it went beats an accurate table of where it went.

What did it produce: the document viewer

Agents generate a lot of Markdown — plans, notes, reports, summaries of what they have just done. That output is the main artefact of a research or planning agent, and if reading it means hunting for a file path and squinting at raw text in a terminal, you will skim it. Skimming is how you end up three steps down a road nobody chose. Rendering documents in the same place you watch the agents removes the friction from the one task you should never rush: actually reading the thing before you act on it.

Is the ground solid: service health

Agents lean on other software — a database, a git host, a model endpoint, whatever API the job is really about. When one of those goes down you rarely get a clean failure. You get an agent that retries politely, or one that carries on with stale information and produces confident nonsense. A service health panel is the least clever part of a dashboard like this and probably the biggest time-saver in it, because “the thing it depends on is down” should be a ten-second diagnosis on a screen rather than a twenty-minute one in a log.

What is it costing: usage tracking

Cost has to be visible while it is being incurred, because that is the only point at which seeing it changes anything. A figure you meet at the end of the month is trivia; a figure you can watch climb against a task that is plainly going nowhere is a decision. The roll-ups worth having are by project and by day — by project, so you can see which piece of work is eating the budget, and by day, so a bad afternoon shows up as a bad afternoon. Treat any figure your own tooling produces as an estimate, incidentally, and reconcile it against what the provider actually bills you.

Where the human’s turn lives: interactive to-dos

The easiest mistake with several agents running is to remove yourself from the loop entirely. Watching a chain of them work unattended is enormously satisfying, right up to the moment you discover that step two was wrong and everything since has been built on it.

So a dashboard like this needs somewhere for the human’s turn to live, and a to-do list is the honest form of it: a short queue of the things only you can decide, in the same place as everything else, rather than a decision buried in a transcript you have not opened since lunch. My rule for what belongs there is simple enough to apply while tired. Anything expensive, anything irreversible, and anything visible to somebody else — deleting, pushing to a shared branch, spending real money, sending work to a client — is a person’s call. The rest can run.

It is the same question I put to businesses in You’re asking AI the wrong questions: which steps genuinely need a human, and which involve one only out of habit? Running several agents forces you to answer it, because you cannot supervise everything, and pretending otherwise just means supervising nothing properly.

Keep the record on hardware you control

A dashboard like this accumulates a detailed account of what your agents have been doing, which by extension is an account of what you have been doing and which projects and clients you have been doing it for. That is not something I want sitting on a service I do not control, and it is the same instinct that has me running a private Tailscale network and my own Git host rather than putting everything on somebody else’s box. If you build one, treat it as internal-only from the first commit: retrofitting privacy onto something you have already exposed is a far worse afternoon than starting there.

If you are thinking of building one

Do not start with the dashboard. Start with a log: have every agent write what it is doing, what it touched and what it cost to one place, in whatever crude format takes ten minutes, and live with that for a week. You will find you keep going back for two or three things and ignoring the rest, and those two or three things are your dashboard. The version you would have designed on day one is always prettier and always wrong.

Then build it boring. This kind of tool is scaffolding, not product, so choose something you can fix in ten minutes at eleven at night over something that is elegant on a Tuesday. Every hour spent on the dashboard is an hour not spent on the work it is meant to be watching.

And whatever else you do, keep a step in it that a human has to click. The point of running several agents at once is to get more done, not to find out later what got done to you.

Originally published at https://www.waynegeorge.uk/writing/mission-control-running-several-ai-agents-at-once/ by Wayne George.

I’m Wayne George, a software engineer in London. I have spent more than a decade building bespoke control systems for large corporate clients, which is still my day job, and in 2024 I founded Frontier Consulting to build custom software and AI systems for UK businesses.

Where automation pays off first

The best candidates share three traits: the work happens often, the steps are broadly the same each time, and somebody already knows what a correct result looks like. Five areas pass that test in most owner-managed firms.

Document handling

Supplier invoices, delivery notes and signed forms arrive as PDFs and photographs. Reading them, pulling out the fields that matter and typing them into your accounts package is work a language model does well and a person does badly at four o’clock on a Friday. It is also easy to check: a total matches the invoice or it does not.

Quoting

Most firms quote from a handful of patterns: read the enquiry, pick the pattern, adjust a few numbers, send a document. A system drafts the quote from the enquiry and your price list; a person approves it. The gain is speed, and the first sensible quote often wins the job.

Scheduling

Bookings, site visits and rotas are mostly plain rules that software you already own may cover. A model earns its place at the messy edge: turning “any afternoon next week except Thursday” into a booking request a person can confirm with one click.

Customer replies

Not a website chatbot, but drafting replies to the emails you already receive, using your own past replies as the reference, with a person pressing send. Sorting the inbox is the same job: “where is my order” and “can you quote for a new roof” should not land in the same pile.

Reporting

Two hours every Monday pulling figures from three systems into a spreadsheet is an obvious payoff, and most of it does not need AI at all. A model adds the two paragraphs on top that explain what changed.

Where it does not pay off

Rare work comes first: automating a task that happens twice a year costs more than it saves. Next is work where nobody can say what “correct” looks like; if two people would give different answers and defend them both, a model will not settle it.

Then there is anything where a wrong answer is expensive and hard to reverse: pricing a large tender, a safety decision, a regulatory filing. AI can help prepare; it should not decide. And the phone call to the client who has been with you for fifteen years is not a process at all. Leave it alone.

Finally, do not automate a broken process. Automating chaos gives you faster chaos.

AI features versus systems that do the work

Nearly every product you pay for has grown an “AI” button. That is a feature: it helps the person doing the task go a little faster, it is cheap, and it is worth switching on. But it does not change who does the work.

A system that does the work is different. It watches the inbox, reads the attachment, extracts the fields, checks them against your rules, posts the result into your accounts package, and raises the ones it is unsure about for a person. The person’s job shifts from doing the task to handling exceptions. That is where the return is, and the engineering: connecting to the tools you actually use, coping with odd cases, failing safely.

I wrote about this in You’re asking AI the wrong questions. The useful question is not “how can AI help me write this email?” but “why does a person need to be involved at all?”

How to run a discovery exercise

Discovery should take a week or two of part-time effort, not a quarter.

Follow the work, not the org chart. Ask each person to list, over five working days, every task that is repetitive, dull and involves moving information from one place to another. Do not ask what AI could do; ask what they would be glad never to do again.

For each candidate, note how often it happens, how long it takes, which systems it touches, what “done” looks like and what happens if it goes wrong. Then check where the data lives: a system with an export or an API is good; people’s heads and paper mean the first job is not AI but getting it into a system at all. Rank by frequency, time and how easy the result is to check, and pick one. Not three.

Imagine a twelve-person accountancy practice where clients send receipts by email and as WhatsApp photographs, and a junior spends part of each day re-keying them into the bookkeeping software. Frequent, unambiguous, already digital: it would top almost any list.

For an outside view, Frontier Consulting runs a free discovery test: a couple of minutes, no sign-up to start, and then, if you want it, an emailed PDF with “your score, category, and recommended next steps”. Treat it as a prompt for the five-day list, not a substitute.

Data protection basics

UK GDPR applies as soon as the automation touches personal data, which means anything that identifies a person: customer emails, employee records, the contact name on a supplier invoice. I am an engineer, not a lawyer, so I will point you at the Information Commissioner’s Office rather than paraphrase it. Several of the pages below now carry an ICO banner saying: “Due to changes made by the Data (Use and Access) Act, this guidance is under review and may be subject to change”, so read the live version rather than a printout from last year.

You need a lawful basis for the processing: the ICO’s guide to lawful basis lists seven, and says you “must determine your lawful basis before you start using the personal information and you must document it”.

You will probably need a data protection impact assessment. The ICO’s AI guidance says that “in the vast majority of cases, the use of AI will involve a type of processing likely to result in a high risk to individuals’ rights and freedoms, and will therefore trigger the legal requirement for you to undertake a DPIA”, and that if you decide otherwise you still have to document how you reached that view. Its DPIA guidance recommends doing one whenever you are in any doubt. For a small first project this is a few pages: what data, why, what could go wrong, and what you are doing about it.

You decide what data is processed and why, so you are the controller; the model provider and anyone building for you are usually processors, and the ICO is clear that “every time a controller uses a processor to process personal data, there must be a written contract” (ICO guidance on contracts). Read the provider’s data processing terms and check whether your data trains their models.

Keep a person in significant decisions. The rules on solely automated decisions with a “legal or similarly significant effect” now sit in Article 22A of the UK GDPR, and the ICO’s guidance on automated decision-making was updated on 31 March 2026 to reflect the Data (Use and Access) Act 2025. That update is still marked draft: the consultation on it closed on 29 May 2026, and the ICO says it will withdraw the older version “when we’ve finalised the updated guidance after the consultation”, so check which version is live before you rely on the detail. The principle is not in doubt. A hiring, credit or dismissal decision needs meaningful human involvement and a route to contest it. An invoice queue does not raise this; screening job applicants does.

Finally, organisations that use personal information, including sole traders, must pay the ICO’s data protection fee unless exempt, and its advice for small and medium organisations hub is worth an hour of your time.

Build or buy

Buy when the task is generic, a product already fits your systems, and the monthly cost is clearly less than the time it saves: transcription, document scanning, meeting notes, drafting inside your email client.

Build when the value lies in the join between your systems, when the product would make the business change to suit it, or when the configuration effort is so large you are building anyway. A “build” at this size is rarely a product; it is usually a modest amount of code around a model, connected to your accounts package and inbox, with a queue for a person to check.

Most projects are a mixture: buy the components, build the workflow that joins them. Either way, insist that your data stays yours and exportable, that the system can switch models without a rewrite, and that someone other than the original builder can understand it.

What a good first project looks like

Small, measurable and reversible.

Small means one process, one team, one kind of input, one kind of output. Measurable means you record a baseline (hours per week, or turnaround time) and measure again six weeks later with the same ruler. Reversible means the old way still works: the new system runs alongside it, a person checks every result until the error rate is known, and you can switch it off on a Tuesday afternoon without anyone noticing.

It should also be a little boring. Picture a building services firm with eight engineers and an office of three: supplier invoices go from the inbox into the accounts package, anything uncertain lands in a check queue, and the office manager records how many hours a week the re-keying used to take. That is a first project. A customer-facing chatbot is not.

How Frontier Consulting works

Frontier Consulting takes UK businesses from discovery to deployment, and its site puts that in three words: “Discover, deploy, thrive.”

It is a sequence, and the order is the point. Discovery is the cheap part and the part that decides everything else, which is why it starts with a free discovery test or a 20-minute strategy session, with, as the site says, “No obligation. No sales pitch.” Deployment means one small, measured, reversible project of the kind described above, rather than a platform. Thrive is the part that usually gets cut: documentation, handover and training, so the system belongs to the business rather than to whoever built it.

Where to start this week

Ask your team to keep the five-day list. Take the discovery test if you want a second opinion in a couple of minutes, or book a strategy session if you already know which process is eating your week. And if you would rather see what I build when I am my own client, that is what the work page is for.

Then choose one process, and choose the dull one. The firms that get real value from this in the next year will not be the ones with the cleverest model. They will be the ones that picked a frequent, checkable, thoroughly boring job, handed it to a machine, and kept somebody watching the queue.

Originally published at https://www.waynegeorge.uk/writing/ai-automation-playbook-for-uk-small-businesses/ by Wayne George.

I’m Wayne George, a software engineer in London. I wrote an open-source Grin wallet for iOS, compiled a short history called Grin: A Brief Story out of the project’s forum archives, and take part in the community that runs it. I am not neutral, but I will try to be fair, and nothing here is advice about what to buy.

A whitepaper from nowhere

The Grin documentation tells the origin story straight: “On Mon Aug 01 2016 a user named majorplayer logged into the #bitcoin-wizards IRC channel, dropped a text file hosted on a Tor server and then disappeared.” The message was almost apologetic — “hi, i have an idea for improving privacy in bitcoin. my friend who knows technology says this channel would have interest” — and the file behind the link was dated 19 July 2016, titled MIMBLEWIMBLE and signed “Tom Elvis Jedusor”, which is Voldemort’s name in the French editions of Harry Potter. Mimblewimble is a tongue-tying curse from the same books. The author never came back (the story of Grin).

The paper described a blockchain that keeps amounts hidden and can throw away most of the data it accumulates. Andrew Poelstra published a refined treatment on 10 October 2016, and ten days later another pseudonymous developer, Ignotus Peverell, told the same channel: “I have a minimal implementation of MimbleWimble available.” That became Grin, and its repository still describes itself in exactly those terms: “Minimal implementation of the Mimblewimble protocol.”

What Mimblewimble actually does

Three ideas carry the design. Grin’s documentation has the maths; here is the intuition.

The amounts are hidden but still add up

Bitcoin checks a transaction the obvious way: add up the coins going in, add up the coins going out, and refuse anything that creates money from nothing. Mimblewimble does the same check on sealed envelopes. Each amount is wrapped in a Pedersen commitment, a construction that hides the number while still letting you add and subtract commitments as if they were numbers, so the network can confirm that inputs minus outputs come to zero without seeing the values. Because hiding a number invites the trick of hiding a negative one, “a rangeproof is therefore attached to every output and proves that its value isn’t negative and that its size is restricted so it doesn’t overflow”.

There are no addresses

A Bitcoin address is a reusable label, and reuse is how transactions get tied to people. Grin has none. Every output is a fresh commitment that shares no data with any earlier one, so there is nothing to look up and nothing to link. The price, in the documentation’s own words, is that “transactions have to be built interactively, with two (or more) wallets exchanging data with one another” (Grin for Bitcoiners). More on that shortly.

The chain forgets

Because the ledger only needs to know that everything balances, “matching inputs and outputs can be eliminated, as their contribution to the overall sum cancels out”. If I pay you and you pay someone else, the output in the middle cancels and can be deleted. This is called cut-through, and it means a new node can verify the whole history without storing it. What survives from each transaction is a kernel, “at around 100 bytes”, and the documentation reckons that a Mimblewimble chain therefore “grows at roughly one quarter the rate of a bitcoin blockchain, while offering much better privacy”.

What Grin is

Grin offers itself in one line: “Electronic transactions for all. Without censorship or restrictions.” Its first block was mined on 15 January 2019, and the launch was deliberately plain: no initial coin offering, no pre-mine, no founder’s reward, no company or foundation. Development is paid for by donations, and the project says it “will attempt to rely 100% on community donations for its funding needs” (funding principles). The homepage still carries the warning it has always carried: “It’s very young and experimental. Use at your own risk!”

One grin a second, for ever

Bitcoin’s supply is capped at 21 million and its block reward halves roughly every four years. Grin emits one new grin every second, indefinitely, with no cap — sixty a block on a one-minute target. New supply as a share of the total falls as the total grows: “After 10 years, it falls below 10%. After 20, below 5%.” And for its first four years Grin’s inflation curve tracked Bitcoin’s exactly, because both paid a full, unchanging reward until year four (emission). The number of coins is nothing like the same; the shape of the curve is.

The stated reason is that Grin is meant to be spent rather than hoarded. It was the most argued-over decision in the project’s history, and it has never changed.

Cuckoo Cycle

Bitcoin miners race to find a hash. Grin miners search enormous graphs for closed loops of 42 links, a puzzle called Cuckoo Cycle designed by John Tromp. It is “primarily a memory bound algorithm, which (at least in theory) means that solving performance is bound by memory bandwidth rather than raw computational speed” — chosen partly because “eventual ASICs should run much cooler than hashing chips” (Cuckoo Cycle). ASICs are the specialised chips that get built for any proof-of-work worth mining, and the bet was that it is better to shape the chips than to pretend they will not arrive.

So two variants ran side by side for the first two years: an ASIC-friendly one that began at ten per cent of rewards and rose to all of them, and ASIC-resistant Cuckaroo29, which fell from ninety per cent to nothing and was modified at scheduled hard forks — compulsory network upgrades — every six months, “in order to interrupt possible ASIC development for it”. The ASIC-friendly side started as Cuckatoo31+, which the documentation notes “was initially the primary PoW but was phased out completely after 18 months”. Cuckatoo32+ is what remains today (proof-of-work).

Interactive transactions and slatepacks

This is what surprises people coming from other coins. Because both parties contribute to the cryptography, sending grin is a short conversation: the sender starts the transaction, the receiver adds their part and signs, and the sender finishes it and broadcasts. The wallets need not be online at the same time, but the data has to make the round trip.

The standard for that round trip is the slatepack. A slatepack address is “a bech32 encoded ed25519 public key”; the sending wallet derives an onion address from it and tries to deliver over Tor, and if that fails the transaction falls back to a block of encrypted text between BEGINSLATEPACK and ENDSLATEPACK markers that you can paste into a chat, an email or anything else that carries words. My own iOS wallet works this way. Its README also lists peer-to-peer transfers over local Wi-Fi and Bluetooth, so two phones can hand a transaction between them with no internet connection at all.

Why privacy in money matters

Your bank statement is private by default. The bank can see it, and so can the law with a warrant, but the corner shop cannot and neither can your neighbour. A public blockchain turns that inside out: anyone who has ever paid you can see the balance you hold, what you spent it on next and who with, for as long as the chain exists.

That is not abstract. It matters to the person whose employer can see what they donate to, to the small business whose supplier can read its margins, and to anyone whose coins are refused because someone further up the history did something wrong. That last one is fungibility, the property that one pound is as good as any other, and a transparent ledger quietly loses it. Mimblewimble’s answer is not to bolt privacy on afterwards but to leave the identifying data out in the first place.

The trade-offs

None of this is free.

The interactive model is the biggest cost. A transaction that needs a reply is harder for exchanges, payment processors and ordinary people than one that needs only an address, and it has held back adoption. There is no “send it here and walk away”.

There is no scripting language. Bitcoin’s small programmable contracts do not exist here, so multi-signature wallets, which need more than one key to authorise a spend, and atomic swaps, which trade grin for another coin without a middleman, have to be built out of the elliptic-curve maths instead. Some of that has proved harder than hoped: multisig in particular ran into unsolved problems around threshold range proofs.

Hidden amounts raise the stakes on correctness. On 18 March 2021, Grin++, David Burkett’s independent C++ implementation, refused to accept block 1,136,081. A caching bug in the main implementation meant a range proof that had already been verified for one output could be accepted for a different one — which is precisely how you would create coins out of nothing on a chain where nobody can see the amounts. A fix shipped within hours and the invalid block was rewound. It remains the best argument I know for a network having more than one implementation of its rules.

Then there is the emission. Perpetual issuance is defensible as monetary policy and hard to love as a story. And the project is small, funded by nobody with a marketing budget, and run by volunteers, which is a strength in some lights and a limitation in others.

From a core team to a governance council

Grin has been governed in public from the start. I read most of that record while compiling the history from the forum archives, and the shape of the thing has changed more than once.

In August 2018, before launch, contributors with commit rights formed a technocratic council to hold a multi-signature wallet for the project’s funds. Ignotus Peverell — Igno to everyone — called the arrangement the “technomity”: “a type of meritocracy, where a technocratic council makes decisions, and a leader (Igno) has the right to exercise final say, but hardly ever has the need to do so.” They looked hard at incorporating and left it open rather than settling it. The governance summary of the time reads: “While no one has completely ruled out the need for a foundation, many of us seem to think it may not be needed or required.” Part of the argument was that “anonymity can be an asset to help shelter this project somewhat”. When Igno left a few months after launch, that unincorporated structure had to carry on without its founder.

In 2020 the project formalised things through RFCs, its written proposals. RFC 0016, begun on 11 September 2020, dissolved the core team because “all critical decision making became centralized around the core team”, and narrowed what was left to almost nothing: “The main purpose of the council is to manage the keys to the Grin General Fund and have final say in spending decisions.” Everything else would self-organise.

In March 2021 John Tromp posted that “the Council has expressed a willingness to share funding control with people from the wider Grin community”, and a call went out for candidates from outside it (forum thread).

By 2025 that arrangement had worn thin, for the dullest and most human of reasons. A thread opened on 6 May 2025 put it plainly: “increasingly it has become difficult to a) get sufficient CC members to join meetings and b) get CC key-holders to sign transactions in a timely fashion.” The proposal was a reset — new volunteers, a new multi-signature wallet — and that is what happened. The older council merged into the new one, the funds were consolidated into “a single 4/7 MultiSig”, and the body took the name Grin Governance Council (forum thread).

My name is in that record. The 6 May 2025 post listed me among the proposed members — “@waynegeorge (software engineer, who long followed Grin)” — and the thread introducing the new council later that month names me as one of its six (forum thread).

For a project with no legal entity, that is a strange kind of appointment. There is no letter, no register, no induction. The treasury is a wallet, the boardroom is a forum thread, and all of it is visible.

Originally published at https://www.waynegeorge.uk/writing/grin-and-mimblewimble-in-plain-english/ by Wayne George.

What Non-Violent Resistance is

NVR grew out of the work of Professor Haim Omer and his colleagues at Tel Aviv University. PartnershipProjects, who say they were the first to use the approach in Britain, describe it as “an innovative form of systemic family therapy, which has been developed for aggressive, violent, controlling and self-destructive behaviour in young people”. Oxford Health’s CAMHS service puts it more plainly: it is an approach that “helps to raise the presence of adults in a young person’s life in order to foster positive relationships”. The same page traces the idea back to Gandhi, Martin Luther King and Nelson Mandela, who used the principles “to bring about peaceful political difference”.

The behaviours it is used for are the ones parents rarely mention at the school gate. Oxford Health lists hitting, kicking, spitting and threatening behaviour, but also violence turned inward, such as self-harm and disrupted eating, and children who isolate themselves.

What sets NVR apart from most parenting programmes is where it points its attention. It does not set out to change the child. It asks the parent to change how they respond: to stop escalating, to stop struggling in secret, and to become a calm, persistent presence the child cannot ignore. Omer’s own site says the approach goes by two names, NVR and “the new authority”, and describes the work as showing parents “how to regain their place, voice and influence”, so that they can “become an anchor for their children”.

The tools parents learn

A parent going through an NVR programme, whether with an NHS CAMHS team, a local authority or a private practitioner, will meet a fairly consistent set of ideas. What follows is my summary of the East London and Oxford NHS factsheets and PartnershipProjects’ introduction to NVR, and the links are there if you would rather read the originals.

De-escalation comes first. East London NHS Foundation Trust’s NVR factsheets call it “the first tool in the NVR toolbox” and reverse the familiar saying: in NVR you “strike when the iron is cold”. You do not meet fire with fire, and you come back to the issue at a neutral time, when everyone can think again.

Baskets are how you choose your battles. You cannot resist everything at once, so behaviours are sorted, and only a small number are actively resisted while the rest are set aside for now. A parent quoted on PartnershipProjects’ introduction to NVR describes still trying to remember “the basics, the grounding, the choosing of my battles and only dealing with the small basket issues”.

An announcement is a short written statement, read or handed to the child, naming the behaviours the family will no longer accept and committing the parents to resisting them without violence. ELFT’s third factsheet explains the point of putting it on paper: “Each carefully pre-planned written statement is designed to increase the presence of the parent in the child’s mind.”

A sit-in is an act of resistance carried out calmly in the child’s own space rather than as an argument, and ELFT is careful to say that parental presence shows just as robustly in the quieter, connecting version as in the traditional one.

Supporters matter because NVR rejects the idea that a family should cope alone. Relatives, friends and teachers are recruited openly, which makes behaviour that has often been kept secret visible to more people than the parents carrying it. One of the parents quoted on PartnershipProjects’ site puts it better than a factsheet can: “It is also acceptable to ask others for help and not feel ashamed.”

Reconciliation gestures run alongside all of this. ELFT names four kinds, quality time, reflective listening, connecting comments and connecting actions, and they are unconditional rather than a reward for good behaviour.

And self-care is built in from the start. ELFT is blunt about why: it “is not optional, but vital, to help prevent parental burnout”.

Another parent on that same page sums the whole thing up in a line I keep coming back to: “NVR is not a marathon nor is it a sprint. It is a lifelong change in parenting approach.”

Why an app

I’m Wayne George, a software engineer in London. I am not a therapist, and I want to be clear about that from the outset. What I bring is a habit: when I meet a structured method, I want to build the thing that makes it easier to follow.

When I looked at how NVR is taught, the gap was obvious. The programme happens in sessions. The hard moments happen between them. The materials are handouts, worksheets and a couple of good books. The announcement drafted so carefully in week six is in a folder somewhere. The list of supporters is on the back of an envelope. How the last fortnight actually felt, which a practitioner will ask about, is a blur by Thursday. And at half past ten on a Tuesday night, with a door slammed and your heart going, the thing in your hand is not a folder. It is a phone.

So the brief I set myself was narrow: put the core ideas, the planning tools and the trackers in one calm place on the phone, and then get out of the way.

I had built one app before with the same stance on privacy. Mood Share keeps everything on the device, with no accounts and no data collection, and I have written separately about how that works. Shipping it convinced me that this is the only sensible approach for anything genuinely personal.

What is in it

An app for a programme like this has three jobs, and they pull against each other. It has to explain the ideas well enough to be useful at eleven at night. It has to hold the writing a parent does, the baskets and the supporters and the announcement, somewhere steadier than a notes app. And it has to stay out of the way, because nobody opens an app like this for entertainment.

The listing describes five sections. Learn is free and covers the core concepts: “what NVR is, the baskets, de-escalation, the announcement, sit-ins, and reconciliation gestures”. If you only ever use this part, it still does the job of a well-organised set of handouts that cannot get lost.

Growth and Connect are named after the shorter ideas a practitioner would sketch on a whiteboard, and none of them are mine. The parent line is ELFT’s picture of parenting styles, permissive at one end, authoritarian at the other, with the ground worth standing on in the middle. The shield is the imaginary armour ELFT suggests a parent picture, “to help protect them when the child makes hurtful comments”. Connection before correction is the observation that a parent has more influence over a connected child than a disconnected one. The seesaw, the Goldilocks zone, the stress position and the magnifying glass sit alongside them. Connect is headed, in the listing’s own words, “Stand against the behaviour, never against the child”, which is close to the whole approach in a sentence.

Planning is where the writing happens: sorting behaviours into baskets, building a supporter network, drafting an announcement. Wellbeing is the part for you rather than your child, with daily mood check-ins, a compassionate letter to yourself and a self-care tracker, because a parent running on empty cannot hold a calm presence for long. There is also a Crisis section with helpline numbers, kept deliberately simple so it is reachable in a hurry.

Learn costs nothing. The other four sections, along with a set of deeper interactive planners and trackers, are opened by a one-time unlock called NVR Companion Pro. It comes in three tiers, Small, Standard and Generous, at £1.99, £4.99 and £9.99, and the listing is explicit that they “all unlock exactly the same content”, so you pay what fits your circumstances. There is no subscription and nothing recurring.

The app needs iOS 18 or later. Version 1.0 went live on 2 June 2026 and a small maintenance update followed on 12 June.

Private by design

The App Store description says it in five short sentences: “Your data stays on your device. No accounts. No cloud. No analytics. No tracking.” The privacy label on the listing reads “Data Not Collected”, and that label is a literal statement rather than a marketing flourish: under Apple’s definition, data processed only on the device is not collected, because collecting means transmitting it off the device where the developer or a third party can reach it. The Mood Share article goes through that definition in more detail. Both of the apps I publish carry the same line.

I made that choice because of what a parent writes in an app like this. An announcement is, in effect, a list of the worst moments in your house. A record of your mood is a fortnight of how you really felt. A compassionate letter to yourself is exactly as private as it sounds. None of that should sit on a server I run, and the simplest way to guarantee it does not is to have no server at all. There is nothing to breach, nothing to sell and nothing to hand over.

The trade-offs are real and I would rather name them than hide them. No cloud means no sync between devices and no web version. No account means there is nothing to recover, so the app lives and dies with your phone and whatever backup you keep of it. And no analytics means no dashboard telling me how many people use it or which screens they linger on; the only feedback is what someone chooses to send me. I am comfortable with all of that.

A companion, not a substitute

The name is deliberate. The listing says it directly: NVR Companion “is an educational and self-help companion. It is not a medical device, and it does not replace professional advice from a clinician, therapist, or NVR practitioner.”

NVR is normally learnt with a practitioner or in a group of other parents, and that is where the judgement, the tailoring to your family and the week-by-week support come from. The app assumes you have that, or are looking for it, and tries to make the time between sessions more useful. If you are not yet connected to a programme, a GP or your local CAMHS service is a reasonable place to start, and organisations such as PartnershipProjects offer training and information.

If your child is in immediate danger, or you are, the Crisis section has helpline numbers, and 999 is always the right call.

Where I want to take it

What I want is for the app to be worth a practitioner’s recommendation: something an NVR team in the NHS, or someone in private practice, can point a parent towards between sessions in the knowledge that it will not harvest anything from them. That is an aim rather than an arrangement, and it is what I would like the app to earn.

If you are a practitioner and you have opinions about what is missing, what is wrong or what would make it easier to recommend, I want to hear them. The same goes for parents using it now.

Try it

NVR Companion is on the App Store for iPhone, and it runs on Apple silicon Macs too. Download it, read through Learn, and if you are already on a programme, try drafting your next announcement in it before your next session. If it helps, or if it does not, email me at hello@waynegeorge.uk and tell me why.

Originally published at https://www.waynegeorge.uk/writing/why-i-built-nvr-companion/ by Wayne George.