Long before I ever tried to reach a room of disengaged students, I fell in love with science myself. I was eight years old, in my parents’ kitchen, with nothing more than a family cooker and a dish of soapy water.
I’d found that if you passed the gas from the pilot light through soapy water, it bubbled beautifully. Then I held a flame to the bubbles as they popped. To an eight-year-old, that was spectacular. I never forgot it.
Decades later, as a lab technician, I found a use for it I never expected.
The Disengaged Students Nobody Could Reach
One of the science teachers had a remedial group, five disengaged students who’d completely checked out. Noisy, rude, out of control, and utterly uninterested in anything science-related. He was frustrated, and he asked me what I could do to get them to at least settle down long enough to teach something.
I had a decent rapport with most students, and I thought back to that soapy water and that pilot light. If it had captured my imagination at eight, maybe it would do the same for a room of teenagers who’d given up caring.
So we recreated it, properly this time. A large trough of soapy water, a rubber hose run from a gas tap with the Bunsen burner itself removed, gas bubbling straight through the soap. I hadn’t accounted for one thing: the bubbles didn’t just sit on the surface. They rose into the air.
Someone put a flame to one, mid-air.
It was even more spectacular than I would have thought of.
It Worked. Perhaps Too Well.
It got their attention completely. For the first time, the teacher had a room quiet enough to actually explain what was happening. Why the gas burned the way it did, what was going on chemically while it happened, all of it finally landed. That part was exactly what we’d hoped for.
What I hadn’t planned for came afterwards, in three separate, escalating problems.
First, the lab ceiling started collecting soot. Those Victorian labs had ceilings high enough that the flames took a few seconds just to reach them, and once the soot was up there, it stayed. Too high to safely clean, it remained on that ceiling for years, right up until the building itself was demolished.
Second, that single lesson became the only thing those students wanted. Not science generally. Specifically “Mr Leader’s Great Gas Experiment,” repeatedly, whether it made sense for the lesson or not.
Third, and this is the one that actually caused real problems: the flames were visible from other labs, and from the humanities block. Lessons in those rooms had to stop. Students lost concentration, distracted by whatever was clearly happening next door. And when it was eventually their turn for a science lesson, they wanted the same thing too.
Questions got asked. We stopped doing it not long after.
What I’d Do Differently
Looking back, this is exactly the kind of moment a mastermind group would have caught before it became a problem. I didn’t run the idea past anyone. I had a good instinct, tried it, and it worked, brilliantly, in the room it was meant for. What I didn’t have was a second pair of eyes asking the obvious question: what happens to everyone else in the building while this is going on?
That’s the thing about solving a problem entirely on your own. You can be completely right about the solution and still miss the consequences sitting just outside the room you’re focused on. A room full of teachers critiquing each other’s experiments would probably have spotted it. Even just one colleague asked “what do you think might go wrong here” would likely have caught the soot, the distraction, and the flames visible next door, before any of it happened. If you want to see what that kind of critique structure actually looked like in practice, I’ve written about it elsewhere on this site.
I’d still do the experiment again. I’d just talk it through with someone first, and I’d probably check current CLEAPSS guidance before I did.
Hundreds of students must have looked up at that ceiling over the years without ever knowing why it was there. I saw it several times a day, for years. Every single time, it reminded me of that small group of disengaged students, and the moment they finally became teachable, if only for one afternoon.
Around 1990, long before I’d ever heard the phrase mastermind groups, a new national curriculum landed on every science department in the country at once. Somebody had to retrain the teachers who’d be delivering it in our borough. That somebody wasn’t me. It was the borough’s science adviser, a man who’d occasionally turned up on television science programmes and never once mentioned it himself. You’d never have known it from how he carried himself. He didn’t lead like someone with anything to prove.
He picked me to run the practical side of it.
I was a Senior Laboratory Technician at a school the authority had already scheduled for closure. That only mattered for one reason: it had lab space sitting available, so that’s where everyone met. The school had built its labs in Victorian times, and the benches were heavy English oak, varnished and stained. They carried decades of history in them.
Burns, scratches, old ink stains, carved graffiti here and there, someone’s initials, the odd declaration of love scratched in years before any of us arrived. I recognised some of those burns even then, an overturned tripod here, a Bunsen burner flame left too close there. Physics, chemistry, and biology all had their own labs like this. The newer labs never had quite the same character. I loved working in those labs. Every old bench had a story sitting under the varnish before you’d even switched anything on.
Every old bench had a story sitting under the varnish before you’d even switched anything on.
The teachers who turned up weren’t from my school at all. They came from right across the borough. All of them needed to get to grips with practical work under the new curriculum before it landed in their own classrooms.
The Mastermind Groups I Had to Build Before I Could Run One
Here’s the bit that doesn’t get mentioned when people talk about mastermind groups: sometimes you need one just to organise the one you’re actually trying to hold.
I had a handful of my own lab techs working under me. Before a single teacher walked into a lab, we had to mastermind the logistics ourselves. What equipment across how many benches. What materials would actually get used versus what would sit untouched. How resources would flow from a request at a bench, through me, down to whoever on my team could source it in time.
None of that existed until we sat down together and worked it out. It’s the same way any mastermind works. Several people bring what they know, argue it into shape, and land somewhere better than any one of them would have got to alone.
Sometimes you need a mastermind just to organise the one you’re actually trying to hold.
A Week of Circuses, Rotating Through Every Lab
The whole thing ran across a full week. We set up experiments in circus format, several stations running at once across three or four labs. Each lab had about fifteen benches, with small groups of three or four teachers apiece. Teachers worked through an experiment, discussed it as a group once it finished, then rotated to the next station. Once one lab’s circuit was complete, the rotation continued to the next lab.
Nobody appointed a leader at each bench. One emerged anyway, every time. That’s simply what happens when a handful of capable people are given a real problem and left to get on with it. Each lab also had its own leader, someone who moved from bench to bench rather than staying fixed to one group. They checked in on how each discussion was going and fed anything urgent back to me directly.
Resetting equipment between rotations was an enormous amount of work for my lab techs and me. Keeping several simultaneous experiments running and properly stocked, repeatedly, across an entire week- that’s the part of the story nobody sees. The teachers experienced a single afternoon’s rotation. We reset the whole thing behind them, over and over, for five days straight.
The Right Answer Didn’t Come From Science
One afternoon I was walking past a bench on my way to have a quick word with the adviser. I overheard a group stuck on something. They had a piece of apparatus hanging from a length of string, and partway through the experiment the string kept unwinding. It was throwing off their results. They were still working out how to fix it when I stopped.
Before I worked in schools, I’d been an electronics wireman. I built wiring harnesses held together with lacing cord, a nylon cord with a rubberised coating that doesn’t unwind under tension. I happened to have some in stock, left over from reworking Victorian equipment for other schools taking kit from the closing building. It was safe to pass on. I suggested it for their string problem. It solved it outright. These days, cable ties do that same job in a wiring harness, but back then, lacing cord was exactly what a wobbling piece of suspended apparatus needed too.
Why the Structure Mattered More Than the Chemistry
The actual science being critiqued mattered; obviously, that was the entire point of the exercise. But looking back, the structure is the part that’s stayed with me. Nobody designed it to be a mastermind. Nobody in that lab would have called it one. It was simply the most sensible way to get a room full of teachers through a genuine skills gap. Trying to personally retrain every one of them myself was never going to work at that scale.
That’s the thing about mastermind groups that I keep coming back to. They don’t need a name, a manifesto, or anyone in the room deciding “right, this is a mastermind now.” They just need a real problem, the right-sized group, and a structure that lets useful information move in more than one direction. A handful of people at a bench, a lab leader circulating between them, or three lab techs working out logistics before any of it starts. The shape holds at every size.
Looking back, I don’t remember much about the official training materials. I remember the conversations. I remember teachers solving problems together, lab technicians quietly keeping everything moving, and expertise turning up from places nobody expected. That’s what stayed with me. Years later, I realised I’d spent a week watching mastermind groups form without any of us calling them that.
If you want the fuller story of how I built my own mastermind group from scratch, I’ve written about that elsewhere on this site. The practical guide to running one that lasts is there too. Napoleon Hill wrote about the same underlying principle decades before any of us in that lab had heard of it.
I’ve been twisting, spinning, and torturing plain text files for years. Keyword lists, in particular, drove me half mad long before I built anything to fix it: paste a hundred phrases into a spreadsheet, discover forty of them were duplicates with different capitalisation, spend twenty minutes cleaning it by hand, then do the exact same thing again a week later on a different list.
That’s the whole reason PhraseFoundry exists. Not a business plan, not a gap-in-the-market spreadsheet exercise. Just years of doing the same fiddly text work by hand, deciding I was done doing it manually, and building tools that actually solve the specific problems I kept running into.
Why Build Your Own Tools Rather Than Just Using What Exists
I’ve actually done this before, properly. Years ago I built and sold a keyword tool called Keyword Evolution for $97, and it sold several hundred times over. It did a lot of what PhraseFoundry does now, but it was wizard-driven: you followed a set sequence of steps in a fixed order, because that’s how the tool was built.
PhraseFoundry does most of the same jobs, for free, and does them better. There’s no wizard forcing you down one path. Clean a list, then group it, then check the word count, in whatever order actually suits the job in front of you, or skip steps entirely if you don’t need them. That’s the difference between a tool built to walk a customer through a process, and a tool built purely to get the job done.
Plenty of keyword and SEO tools already exist, and many are excellent. Most, though, are built around subscriptions, so the genuinely useful features sit behind a paywall. That’s a perfectly reasonable business model. It just wasn’t the one I wanted for the repetitive jobs I found myself doing every week. Cleaning a keyword list, generating URL slugs, checking a word count against a readability score, these aren’t things that need an account, a login, or a monthly fee. They need a page that does the job properly and gets out of your way. So PhraseFoundry runs on a simple rule: no accounts, no feature gates, no premium tier hiding the useful functionality. Your data stays in your browser and isn’t stored anywhere. If a tool’s genuinely useful, it should just work, not tempt you into upgrading to get the version that actually solves your problem.
If a tool’s genuinely useful, it should just work, not tempt you into upgrading to get the version that actually solves your problem.
The Toolkit So Far
Everything currently on PhraseFoundry grew out of a real problem I’d hit while doing actual keyword or content work, not a feature list someone brainstormed in a meeting.
Keyword Scrubber cleans and deduplicates keyword lists using seventeen configurable rules. Empty lines, stray metadata, inconsistent casing, straightforward duplicates, all handled in seconds rather than by hand.
Keyword Bloom takes seed keywords and expands them into variations, useful for building out ad groups or a content plan from a handful of starting phrases rather than staring at a blank page trying to think of every angle yourself.
Keyword Combiner generates permutations from multiple word lists, handy for ad variations, product name brainstorming, or working out domain ideas from a set of building blocks.
Keyword Grouper clusters keywords automatically by shared terms, word count, or custom rules, turning a big unsorted dump of keywords into something you can actually organise a campaign around.
Word Counter Pro gives you the full picture on a piece of text: characters, words, sentences, paragraphs, reading time, and readability scores including Flesch-Kincaid and Gunning Fog, in one place rather than four different sites.
Case Chameleon converts text between capitalisation styles, lowercase, UPPERCASE, Title Case, Sentence case, camelCase, snake_case, whatever the job in front of you actually needs.
Slug Generator turns any text into a clean, URL-friendly slug, handling accented characters and stripping anything that doesn’t belong in a permalink.
Who Actually Uses These
I didn’t build these for four different audiences. I built them because I kept hitting the same repetitive text-processing problems myself. Over time I realised those same jobs crop up whether you’re doing SEO, writing content, managing PPC campaigns, or developing software.
SEO specialists cleaning up keyword exports, expanding variations, and getting data ready for campaigns without the manual tidy-up first.
Content writers checking word counts and readability, generating slugs, and reformatting text without switching between half a dozen browser tabs to do it.
PPC managers building keyword combinations for ad groups and organising bulk lists pulled from multiple sources.
Developers handling the string manipulation and text processing tasks that turn up constantly and rarely justify writing a script from scratch.
What’s Coming
The toolkit keeps growing, and the next addition is one I’m genuinely looking forward to: a tool that takes a large keyword list, batches it into groups of five, and generates a direct Google Trends comparison link for each group. Paste in a hundred keywords, get twenty links back, and you can work through them checking which keywords actually show real search interest and which are dead weight. No manual copy-pasting into Trends over and over.
Beyond that, there’s a SERP Simulator on the way, for previewing how titles and meta descriptions will actually look in Google’s results, along with a proper Find and Replace tool with regex support, a List Comparer for spotting what’s unique or shared between two lists, a Text Splitter for breaking content into chunks, and an HTML Stripper for pulling clean text out of markup.
I’ll also be writing longer explainers here on the mechanics behind some of this, things like how Google Trends actually works under the hood, and practical ways to gauge real keyword competition across Google and other search engines, rather than just trusting a single difficulty score. Those are proper topics in their own right, so they’ll get their own dedicated write-ups rather than a rushed paragraph here.
Why This Matters More Than It Sounds
None of this is complicated engineering. That’s rather the point. I build these tools using vibe coding, describing what I want to an AI assistant and reviewing what comes back, the same workflow I’ve written about elsewhere on this site. It works here because I can describe exactly what a tool needs to do in plain English before I ever start prompting. After twenty-odd years writing PHP, I already know the shape of the problem; the AI just gets me there faster than typing every line myself would.
When something breaks while I’m building one of these tools, I don’t reach for elaborate debugging tools first. I drop numbered debug points through the code, log statements that just say “reached point 12,” “reached point 15,” and so on. If point 11 shows up in the log but point 12 never does, I know exactly where to start looking. It’s not clever. It’s just fast, and fast is what you want when you’re the only one who has to understand the code six months later.
None of this is complicated engineering. That’s rather the point.
Every tool here started small. I build a handful of core features first, use it properly on real work, and only add more once I know the basics genuinely hold up. Some tools are done, they do their one job and don’t need anything else. Others are still growing, based on what I run into myself or what people tell me they’re missing.
The value isn’t in doing something nobody else has thought of, it’s in doing the boring, repetitive part of the job properly, for free, without the usual friction of accounts and upsells and feature walls. I built these because I needed them on real projects, and I still use every one of them myself, which is usually the best test of whether a tool’s actually worth keeping around.
If there’s a specific text-processing headache you keep running into, I’d genuinely like to hear about it. The tools that end up here are the ones that solve a problem someone’s actually had, not the ones that look good on a roadmap.
Every “how to research a niche” guide tells you the same thing: check search volume, look at competitors, find a gap. I’ve done this dozens of times over the years running my own portfolio of niche sites, and here’s what those guides don’t tell you about niche research: the research isn’t the hard part. Knowing when to walk away from a niche that looks good on paper but won’t actually make you money is the hard part.
I’ll show you how I actually approach niche research, mistakes included.
Start With What You’d Still Write About in a Year
Forget passion for a second. That word gets thrown around too easily. What matters is whether you’ll still want to be writing about this topic in twelve months, when the novelty’s worn off and you’re on article forty rather than article four. I’ve abandoned niches I thought I’d love because it turned out I only liked the idea of them, not the actual day-to-day of researching and writing about them.
Pick something you already know a fair bit about, or something you’re happy to spend the next year learning properly. That’s not motivational advice. It’s just self-preservation, because burning out on a niche six months in wastes far more time than picking carefully at the start.
Doing Proper Niche Research on the Market
Once you’ve got a shortlist, this is where the actual work starts.
The tool matters less than what you’re looking for. Whether you’re using Google Keyword Planner, SEMrush, Ahrefs, or my own PhraseFoundry, you’re trying to answer the same question: is there enough demand, and are the existing answers genuinely good? I’ve written more about the specific tools and approach I use in my SEO and tools section. Look for the gap between demand and decent existing content. High volume with weak competitors is the sweet spot, but don’t stop there.
Google Trends tells you whether a niche is growing, flat, or dying. I’ve seen niches with brilliant keyword numbers that were actually in slow decline. The historical volume looked great; the trend line told the real story.
Check what your competitors are actually doing, not just that they exist. Read their content properly. Look at the questions people are still asking after reading the article, whether that’s in the comments, on Reddit, on YouTube, or in forums. That’s usually where the opportunity is.
Validate It Before You Build Anything
This is the step people skip, and it’s the one that saves you the most time.
Go to Reddit, niche forums, or wherever your audience actually hangs out, and read what real people say when nobody’s trying to sell them anything. Their language, their specific frustrations, their exact wording, is worth more than any keyword tool. I’ve rewritten entire content plans based on a single forum thread that told me what people actually wanted rather than what I’d assumed.
Before committing months to a niche, put something small in front of real people. A landing page, a short survey, or even a handful of honest conversations will tell you more than weeks of spreadsheet work.
Work Out If It’s Actually Profitable, Not Just Popular
Traffic isn’t money. I’ve built sites that got decent visitors and made almost nothing, because the niche didn’t lend itself to any real monetisation.
Traffic isn’t money. Profit is.
Look at what people are actually willing to pay for in this space, not just what they’ll click on. Work out your realistic costs, whether that’s your own time, tools, or content production. And be honest about market size: a niche can be genuinely underserved and still too small to be worth your time.
Headache racks was one of my earliest niches, built using Traffic Equalizer back when that was the tool everyone was using. It started pulling in decent traffic and, more importantly, decent money. Then I hit my hosting’s bandwidth cap, mid-month, and the site went down.
I didn’t know how to move a website to a new host at the time, and it turned out I couldn’t even if I had. My domains were registered with the same company as my hosting, and once I was locked out, I lost access to both together. By the time I understood what had happened, that site, and several others on the same setup, were gone for good.
That wasn’t a niche research mistake. The research was fine; the site was earning. It was an infrastructure mistake that undid all the research anyway. It taught me a rule I still follow: never keep your domains and hosting with the same company. Since then I’ve always kept my domains separate from my hosting. I happen to use Namecheap these days, but the important part is keeping those two services independent.
Decide How You’ll Actually Make Money Before You Start
Affiliate income, your own product, ads, a subscription: decide this early, because it changes what content you should be writing from day one. I’ve made the mistake of building out a site’s worth of content before I’d properly worked out the monetisation angle, and had to go back and retrofit it. Save yourself that step.
Work out what makes your site worth visiting over the twenty others already covering this niche. If you can’t answer that clearly, that’s worth solving before you write a single post.
What Years of Niche Research Actually Taught Me
Here’s what I’ve learned the hard way, more than once: a niche that ticks every box on paper can still fail if you don’t actually enjoy doing the work. And a niche that looks mediocre on a spreadsheet can quietly become one of your best earners, because you understood the audience better than anyone else writing about it.
A niche that ticks every box on paper can still fail if you don’t actually enjoy doing the work.
The niche research above will get you a shortlist of genuinely viable options. Which one you actually pick still comes down to judgement, not just numbers. That’s the bit the spreadsheet can’t do for you.
People ask me how I learned to set up mastermind groups as if there was a master plan from day one. There wasn’t. I built my first one because a problem kept showing up, and nobody was solving it.
I was a Senior Laboratory Technician for the London Borough of Waltham Forest. Science technicians in schools are an odd professional group. Every school has one or two, tucked away in a prep room, solving problems that nobody else in the building understands. Broken equipment, awkward risk assessments, exam board quirks. Each of us figured it out alone, in isolation, and as a result we were often re-solving a problem that a technician two miles away had already cracked the year before.
That waste bothered me. So I decided to set up a network of my own. Nothing grand. I simply asked around to find out who else was doing this job in the borough, and started getting us in a room together once a term.
How I Set Up Mastermind Groups, Step by Step
I should point out at this stage that none of this was clever. It was simply persistent.
I found the other technicians. There was no list. Waltham Forest had around 200 schools, so contacting all of them myself would have been a massive job. Instead, I asked a handful of volunteers to each take on a handful of schools themselves. That one decision was a huge time saver, and as a result the network started life as something built by several people, not just me.
I picked a low-pressure first meeting. No agenda beyond seeing if this would be useful. I didn’t want anyone feeling obligated to attend a second one.
I made the value obvious early. I came with a genuine problem I was wrestling with, and consequently others did too once they saw it wasn’t a trap. That’s the bit people skip when they try to set up mastermind groups of their own: it only works if the first session proves its worth, rather than just promising it.
I kept the rhythm light. Once a term. Often enough that people remembered why they came, but infrequently enough that it never felt like a burden on top of an already full job.
I let it grow on its own terms. Word spread, and the network reached around 250 members eventually, which is a huge number for what started as a handful of people in a prep room comparing notes.
Where It Got Interesting
Here’s where it gets interesting. Once the network had numbers, equipment suppliers noticed. They wanted access to 250 technicians as a sales opportunity, but I saw it differently: as free training.
I turned their product demonstrations into proper training sessions. The supplier provided the trainer and covered the cost of lunch, so we got hands-on time with the latest scientific equipment, in our own laboratories, at no cost to anyone. Not every school could release staff for it, but twenty or so technicians would turn up each time, and the knowledge spread from there through the rest of the network.
It wasn’t all supplier-led, either. Some technicians had specialised knowledge of their own and were happy to share it, leading training sessions for the rest of the network on whatever they knew best. I led several of these myself. That’s the bit that made it a proper mastermind rather than just a training calendar, because the expertise was coming from inside the group, not only from outside suppliers.
We also ran an annual group purchase of science equipment. By aggregating everyone’s individual orders into one collective buy, I negotiated a discount that none of us could have got alone. It’s a simple idea, but it’s only possible because the group existed and was organised enough to act together.
My manager backed the whole thing from the start, and the department benefited directly, with better-trained technicians, fewer repeated mistakes, and faster fixes. Eventually the borough’s Design and Technology departments asked me to come in and advise on setting up something similar for them. That worked too.
Sometimes One Session Is Enough
Not every mastermind needs 250 members or years to prove its worth. One of the most useful I ever took part in lasted about twenty minutes, solved a real problem, and never happened again.
It was activities week, just before the summer break, when the curriculum gets suspended so students can dig into whatever they’re actually interested in. I loved those weeks. We’d set up drop-in sessions for experiments, and two students wanted to design their own, looking at photosynthesis in Elodea. It wasn’t scheduled or planned, just an ad hoc conversation that happened because the problem needed solving there and then.
Good idea, but I could see a problem coming before they could. They wanted a constant light source, which meant the lab’s old-style bulbs, and those bulbs heat water.
So I pulled in the head of science, and the head of physics, and the five of us worked through it with the students there and then. The fix turned out to be simple: a second tank of water acting as a heat buffer between the lamp and the students’ tank.
Solved on the spot, by exactly the right five people being in the room together. My head of department reckoned it was one of the most useful discussions he’d sat in on that year, and the students got more out of it than the experiment alone would ever have taught them. Sometimes a mastermind doesn’t need a name or a membership list. It just needs the right people noticing the same problem at the same time.
The Bit Nobody Talks About
There was something else going on underneath the training and the discounts. One of the technicians once described her own role to me as ancillary, as if she were an afterthought to the school’s real work. That word stuck with me, and for the record, it’s wrong. These were skilled professionals, and the network gave them a forum that proved it. Some of them went on to train teachers on the equipment they’d once felt apologetic about handling.
I didn’t set out to fix anyone’s sense of professional worth. That happened as a side effect of giving people a room where their knowledge mattered, and it’s a huge part of why I think masterminds work, beyond the practical wins.
What I’d Do Differently If I Were to Set Up Mastermind Groups Again
This beggars belief, looking back, but I built the entire thing around myself without ever planning for what happened when I moved on. I didn’t rotate the organiser role, and I didn’t keep a shared record of contacts and notes that lived anywhere other than in my own head. When I eventually left that role, the network didn’t have a clean handover plan, so a lot of momentum that had taken years to build relied on no one else stepping up.
If I were starting again, I’d build succession in from month one. I’d rotate who organises each term, and keep a shared document rather than a personal inbox. A group that depends entirely on one person is fragile, no matter how well that person runs it. I cover this properly in the build one that lasts article, and it’s the single thing I’d change about how I ran the Technicians’ Network.
The Looser Version: Martin Avis’s Lunches
Not every mastermind needs that much structure. The most informal version I’ve taken part in was a series of business lunches in London, organised by my good friend Martin Avis, who has a knack for getting the right people into the same room.
We met roughly every two months, and Martin charged a modest fee that covered only the food. The lunch itself was structured enough, but the real value happened afterwards, in the hotel bar, when people hopped between tables and the conversations got specific. Martin steered the first few gatherings gently, and then it took on a life of its own, which, in hindsight, is exactly the succession point I missed with the Technicians’ Network. He built it to survive without him steering every session.
Several joint ventures came out of those lunches. A handful of the people I met there are now very well known, and a few are self-made millionaires. I was even approached by a well-known online author to write software converting old websites into what was then a brand-new platform called WordPress. I didn’t have the bandwidth to take it on, but the fact that the ask happened at all tells you something about the calibre of people in that room, and the trust that builds when a group like that runs for long enough.
If you want to go back to where this idea originally came from, Napoleon Hill’s foundation still maintains a good archive of his original writing on the mastermind principle at naphill.org. It’s worth a read once you’ve got the practical side sorted.
What It Actually Takes to Set Up Mastermind Groups
Looking back across both groups, the pattern is the same. Find people who genuinely understand your world, and give them a reason to show up that has nothing to do with politeness. Keep the rhythm light enough that it survives busy working lives, and build it so it doesn’t depend entirely on you.
You don’t need permission, a budget, or a grand plan to set up mastermind groups of your own. I certainly didn’t have one. You simply need a handful of people willing to contribute, and somewhere to put the next meeting in the diary. Once you’ve got that sorted, the rest tends to build itself, so just make sure someone other than you knows how to keep it going.
Not a hypothetical. This is the actual back-and-forth that went into an AI code review of the JSON Importer plugin I use to bulk-publish posts to my own WordPress sites (the same tool, as it happens, that imported a recent batch of content for this site). I asked AI to review the existing code, took its findings seriously, made my own calls on what to act on, tested each fix on its own before moving to the next, and still hit a snag that taught me more about the limits of an AI code review than the review itself did.
I write a fair bit about vibe coding in general terms elsewhere: what it’s good for, where it falls down, and how I work with it day-to-day. If you want that broader argument, it’s in my vibe coding overview. This post is the proof, not the theory.
Why This Is the AI Code Review Example I Keep Coming Back To
I already had a working plugin. Simple enough on the surface: paste a JSON array into a textarea, hit import, and it creates WordPress posts from it, pulling in Yoast SEO fields, categories, and tags along the way. It did the job. I hadn’t looked at it critically in a while.
So I handed over the code and asked for exactly that: dig through it, flag anything wrong, and tell me where it could be better.
One thing worth saying up front, because it matters for how this whole exercise went: I didn’t take a list of fixes and bolt them all on at once. Each one went in, was tested properly on its own, and only then was the next one added. That’s not an AI habit. That’s just how you avoid ending up with three half-working changes and no idea which one broke things.
Where the AI Code Review Earned Its Keep
The first thing it spotted was the missing nonce. No CSRF protection on the form. Nothing stopped a forged request from outside WordPress tricking a logged-in user into running an import they never intended. The fix is a standard WordPress nonce, checked on submission:
Three checks, all required, none of them optional. That’s the kind of thing that’s easy to half-implement (add the nonce field but forget to verify it, say), and a careful pass catches that.
That’s exactly the sort of work AI is surprisingly good at: a security review of your own code, even code you wrote yourself a while back, is a bounded, verifiable task. There’s a finite list of known WordPress vulnerability patterns (missing nonces, unsanitised content, capability mismatches), and checking code against that list is mechanical work, not judgement work.
post_content going into the database raw was the next one. Titles were being sanitised. Content wasn’t. That’s a stored XSS route, wide open to anyone who can get content into the import. The fix uses the right function for the job, not a blunt one:
wp_kses_post() strips anything that shouldn’t be in post content, things like script tags and on* attributes, while leaving normal HTML markup intact. Using sanitize_text_field() here instead would have stripped all the HTML, which isn’t what anyone publishing a formatted post wants.
Those were fairly mechanical security issues. The next one wasn’t.
The Capability Gap That Took Real WordPress Experience to Spot
A capability gap that only shows up if you follow the consequence all the way through. The plugin deliberately allows Authors and Contributors to use the importer, not just Editors and Admins. Fine in principle. But nothing in the original code stopped a Contributor’s JSON from setting status to publish directly, which is exactly the kind of thing the Contributor role exists to prevent. The fix checks the actual capability for the post type rather than trusting the JSON:
I like this fix more than a flat rejection would have been. It doesn’t fail the whole import because someone aimed too high. It just quietly puts the post into the queue an Editor would expect to review, which is what should have happened anyway.
My Own Role in Getting This Right
That capability gap is the clearest example of AI earning its keep here. I’d loosened the restriction for a reasonable-sounding reason (letting more roles use a handy tool) and hadn’t followed the consequence all the way through to what a Contributor could actually do with it. The review caught the gap I’d left.
I want to be straight about my own part in all this too. The list wasn’t something I took and blindly implemented. Every point was read, its importance understood, and judged on its own merits, including which behaviours stayed exactly as I wanted them (categories are created automatically if they don’t already exist, which was my instruction from the start, not something the review suggested).
Where It Quietly Went Wrong
Here’s the part that matters most, because it happened to me, not to some hypothetical careless beginner.
I’d documented my own JSON format separately: posts should use a title field and a status field. Standard stuff for me, second nature, written down in my own notes.
The plugin’s older code was still checking for post_title and post_status, the field names from an earlier version, not my documented spec. Nobody flagged the mismatch during the review, because the review was looking at whether the code was secure and sensible, not whether it matched a specification it had never been shown. Despite all that, the code looked complete, ran without errors, and would have passed a quick glance with no trouble at all.
It failed the first time I actually used it on a real file. Every single record came back “skipped, no post_title,” because the file used title, exactly as I’d specified, and the code was looking for the wrong key entirely.
Why a Clean-Looking Result Isn’t the Same as a Correct One
This is precisely the failure mode I’d point to if someone asked me what’s actually risky about vibe coding. Nothing crashed, and no error message pointed at the real problem. The plugin did exactly what it was told, which simply wasn’t what I needed it to do. If I hadn’t tested it against a real file in my real format, it would have sat there looking finished while quietly doing nothing useful at all.
The plugin did exactly what it was told, which simply wasn’t what I needed it to do.
Worth noting too: my own first guess at the cause, before I’d looked at the actual JSON, was wrong. I assumed the array was nested oddly. It wasn’t. The fix only happened once I stopped guessing and looked at the real file.
The Fix the AI Code Review Missed Until Real Data Caught It
Once the actual JSON was in front of me, the fix was straightforward. Check the documented field name first, then fall back to the old one for anything still in that format:
Two lines, and both old and new JSON formats work from here on. It’s quick once you know what’s actually wrong; the finding-out is the part that took the testing.
The lesson isn’t really about JSON keys. It’s about where the actual risk sits in this way of working. The security review (judging code against known, documented vulnerability patterns) was reliable and saved me real time. Matching code against my own specific intent, the bit that only existed in my own notes and never made it into the conversation, was where things slipped through. Vibe coding can tell you your code is insecure against a known checklist, but it can’t tell you your code doesn’t match a spec it was never shown, or wasn’t told to check against in the first place.
Useful for the bounded, checkable work, blind to the context that lives only in your head.
What I’d Do Differently in My Next AI Code Review
If you’re working this way yourself, here’s what this particular case actually changes about how I’ll prompt next time:
State the spec explicitly, every time, even when it feels obvious. I assumed “my JSON format” was implicit context that would carry forward. It wasn’t, because it was never actually given the current spec, only the old code, which had drifted from it.
Paste the real data alongside the real code. A genuine sample of the JSON file would have caught the field name mismatch within seconds, just as it eventually did once I stopped guessing and showed the actual file.
Treat “looks complete and runs without errors” as a status report, not a result. The plugin satisfied both of those and still did nothing useful. Running it against real data is the only test that counts.
Test each fix on its own before adding the next. This is the habit that kept the rest of this project sane. Bundling several changes together and testing once at the end means that when something breaks, you’re hunting through all of them to find out which one did it.
Use vibe coding hardest for work with a checklist, and lightest for work that depends on what’s in your head. The security review worked because there’s a known list of WordPress vulnerability patterns to check against. Matching my undocumented intent had no such list, and that’s exactly where it slipped.
None of this is a reason to avoid an AI code review for something like this. The plugin works, it’s in daily use, and it’s measurably more secure than before the review. It’s a reason to know which part of the job you’re still doing yourself.
I’ve been writing PHP for the best part of twenty years. So when people started throwing the phrase “vibe coding” around, I’ll admit my first reaction wasn’t excitement. It was suspicion.
If you haven’t come across the term, vibe coding is what happens when you describe what you want to an AI in plain English and let it write the code. Often that means doing it without checking the output line by line. It was coined by Andrej Karpathy on X back in February 2025. Some call it the biggest productivity shift in software development since version control. Others call it a slow-motion car crash for anyone who doesn’t already know what good code looks like.
Here’s where it gets interesting. Both of those things are true. It depends entirely on who’s doing the vibe coding.
I should point out at this stage that I’m not writing this as someone who’s scared AI is coming for my job. I’m not writing it as a cheerleader either. I’m writing it as a developer who’s spent years building things in PHP and WordPress (you can read more about that background on my about page). I’ve also spent the last while working out how to use AI properly rather than just using it.
That distinction matters more than anything else in this post. Let me explain why.
Why My Opinion on This Is Worth Anything
Here’s the thing nobody talks about when they’re hyping up vibe coding: the AI doesn’t know if the code it just wrote actually works. Not properly. It knows if the syntax is valid. It knows if the code resembles the millions of examples it learned from. What it doesn’t know is whether that WP_Query call is going to behave itself in your specific theme. It doesn’t know whether that database call is sanitised properly. It doesn’t know whether the “working” demo it just produced is one edge case away from falling over in production.
I know those things because I’ve been doing this for years. I’ve made the mistakes already, the hard way, before AI was around to make them for me. That’s the entire reason I can sit down with an AI assistant and get something useful out of it. I can tell the difference between code that works and code that merely looks like it works.
That’s not a dig at anyone learning to code with AI for the first time. It’s just an honest statement of where the value is. If you can’t read the output, you’re not vibe coding. You’re gambling. You won’t know you’ve lost until the site’s down or the database is full of garbage.
f you can’t read the output, you’re not vibe coding. You’re gambling
What Vibe Coding Is Actually Good For
Let’s start with the positive, because there’s plenty of it.
Boilerplate and scaffolding. If I need a new WordPress plugin skeleton, a custom post type registered, or a settings page wired up, AI does this faster than I can type it myself. This is the stuff that’s mechanical, repetitive, and well documented. The AI has seen ten thousand examples of exactly this pattern. It reproduces it reliably.
A second pair of eyes on logic. Sometimes I’ll have a function that’s nearly right, but something’s nagging at me. Describing the problem to an AI and asking it to spot the issue is often faster than staring at my own code for twenty minutes. It’s not always right. But it’s right often enough to be worth the thirty seconds it takes to ask.
Translating between languages and frameworks. I know PHP inside out. I don’t know every JavaScript framework that’s come along in the last five years. When I need a bit of vanilla JS for the front end, AI gets me a working first draft far more quickly than hunting through documentation for syntax I use only twice a year.
Explaining other people’s code. Picking up someone else’s undocumented PHP code from three years ago used to mean a slow read-through over coffee. Now I can paste the function in and get a plain-English explanation of what it’s doing. I still verify it myself rather than take it on faith.
The Tasks Where the Judgement Call Is Already Made
Writing the dull stuff. Comments, docblocks, README files, and basic error-handling boilerplate. None of this requires creative thought. All of it benefits from being done well rather than skipped. That’s exactly the kind of task AI doesn’t get bored of.
Generating test data and edge cases I wouldn’t think to write myself. Ask for fifty rows of realistic-looking dummy content. Or a list of every weird string that might break a form field: empty, massive, full of emoji, full of SQL-looking nonsense. You get a genuinely useful list in seconds. I’d normally write three or four examples and call it done. AI gives me twenty, and a couple are always things I hadn’t considered.
Refactoring with a clear before-and-after. When I know exactly what I want the code to look like after the change, AI is a huge time-saver for getting there. “Take this function and split it into three smaller ones, each with a single responsibility” is a task it handles well. The judgement call (deciding it should be split, and how) was already made by me. It’s just doing the typing.
Notice the theme. Every one of these is a task where I can verify the result quickly, and where being wrong is cheap. That’s not an accident. The moment a task requires judgement I can’t verify in thirty seconds, my approach to vibe coding changes completely. Which brings us to the next bit.
Where Vibe Coding Falls Down
Now the bit that doesn’t get said enough, because nobody selling AI tools wants to say it.
It doesn’t know your system. WordPress code in general is familiar territory, but your specific setup isn’t. That one quirky function in your theme from 2019 is invisible to it. So is the database structure you inherited from a previous developer, and the three other plugins running on the site that’ll happily clash with whatever it’s just suggested. Every piece of AI-generated code needs to be read with your actual environment in mind, not just trusted because it compiles.
It’s confidently wrong, often. This is the one that catches people out. AI doesn’t hedge the way an inexperienced human developer would. It doesn’t say “I’m not sure this is right.” It writes the wrong code with exactly the same confidence as the right code. If you don’t already know enough to spot the difference, you’ve got no way of telling which one you’re looking at.
Security is an afterthought unless you ask. I’ve seen AI happily generate a form handler with no input sanitisation and no nonce verification. Ask it to fix that and it will, instantly. That tells you the knowledge is in there. But it doesn’t volunteer it. You have to know to ask, which means you have to already know it matters.
Judgement Calls AI Can’t Make for You
It struggles with anything that needs real architectural judgement. Should this be a custom post type or a custom table? Should this logic live in a plugin or the theme? Is this the right moment to refactor, or should we live with the mess for now? These aren’t syntax questions. They’re judgement calls based on years of seeing what goes wrong six months down the line. AI has no skin in that game. It’ll answer either way confidently.
Long-running, complex builds drift. For a quick function, fine. For something that spans multiple files and grows over several sessions, I’ve watched AI lose track of decisions made twenty minutes earlier in the same conversation. It quietly contradicts itself. You have to be the one holding the whole shape of the project in your head, because it isn’t.
A Real Example of Vibe Coding Going Quietly Wrong
Here’s a real example, not a hypothetical. I built a JSON import plugin for WordPress and asked AI to review and rewrite parts of it. The result ran without a single error. It looked complete. It still quietly failed the first time I used it on a real file. The rewritten code was checking for the wrong field names, ones I’d never actually specified. Nothing crashed. Nothing logged an error. It just didn’t do what I needed, and only testing against real data caught it. I’ve written up the full story, mistakes and all, in a dedicated case study, because it’s worth more as a complete example than a paragraph here.
That’s the danger in one sentence. AI-generated code fails silently far more often than it fails loudly. It’s optimising for “looks right” rather than “is right.” Those two things only reliably overlap when someone who knows the difference is checking.
The pattern across all of these: vibe coding is excellent within a narrow, well-bounded task. It gets progressively less reliable the more judgement, context, or architectural thinking the task demands. That’s exactly the part of the job that took me years to get good at.
My Actual Workflow
Right, enough theory. Here’s what vibe coding actually looks like in practice when I sit down to build something.
1. I describe the task precisely, including constraints. Not “build me a contact form,” but the specific plugin or theme it needs to sit in, the fields required, and what should happen on submission. Include any existing functions or hooks it needs to play nicely with. The vaguer the prompt, the more generic and wrong the output. This is the single biggest factor in getting usable code back.
2. I ask for the boring stuff up front. Sanitisation, validation, error handling, nonces if it’s WordPress. Asking for it properly the first time beats waiting to be shown an insecure version and fixing it after the fact.
3. I read every line before it goes anywhere near a live site. Not skim. Read. If there’s a function I don’t immediately understand, I ask the AI to explain its own reasoning. I check that explanation against what I know rather than just accepting it.
The Habits That Keep the Process Honest
4. I test the edge cases myself. What happens with an empty field? A massive input? A user without the expected permissions? AI tests the happy path by default unless you push it. Pushing it is my job.
5. I keep sessions focused. One function, one feature, one fix at a time. Not one sprawling conversation trying to build an entire plugin from scratch. Shorter sessions mean less drift and a lower chance that the AI has quietly forgotten a decision from ten messages back.
6. I treat it like a fast junior developer, not an oracle. A genuinely good junior developer who can type at the speed of light, has read every PHP tutorial ever written, and has zero experience of what happens when code meets the real world. I wouldn’t deploy a junior’s first draft unsupervised. I don’t deploy AI’s either.
I treat it like a fast junior developer, not an oracle
That last point is the one I’d want anyone reading this to take away above all the others.
A Few Vibe Coding Habits That Make a Real Difference
Beyond the broad workflow, there are some smaller habits that consistently improve what comes back. None of this is complicated. All of it gets skipped by people who are new to working this way.
Give it the existing code, not just a description. If I’m adding a feature to an existing function, I paste the function in rather than describing what it does from memory. AI matches the style, naming conventions, and structure already in use far better when it can see them. Otherwise it guesses, and often produces something that clashes with the rest of the file.
State what shouldn’t change. “Add validation to this form handler, but don’t change how the data gets saved to the database” heads off a whole class of unwanted rewrites. Left unconstrained, AI will sometimes “improve” things you didn’t ask it to touch. You won’t always notice until something downstream breaks.
Ask it to flag its own assumptions. “Tell me anywhere you’ve guessed at something rather than knowing it” is a simple line that comes up surprisingly often. AI will often quietly assume a database table structure, a function that exists elsewhere, or a value passed in from somewhere else. Most of the time those assumptions are wrong. Most of the time it’ll tell you, if you ask.
Use it to review your own code, not just generate new code. Pasting in something I’ve written myself and asking “what would you flag in a code review here” catches things I’ve gone blind to after staring at the same function for an hour. It’s not infallible. But it’s a genuinely useful extra pair of eyes, going both directions.
What I Use
For the record, I’m not precious about which AI assistant does the work. The underlying skill (reading the output properly) matters far more than the brand on the tin. What matters more is an editor or terminal setup that lets me move quickly between writing the prompt, reviewing the output, and testing it in a real environment. The faster that loop runs, the more I get out of the process. It’s also less tempting to skip the reviewing step out of impatience. That temptation, by the way, is the actual risk in vibe coding. Not the AI being wrong. Us being in a hurry.
If You Want to Try This Properly
If you’re a PHP or WordPress developer wanting to try vibe coding properly, here’s where I’d point you, without diving straight into something critical.
Pick a task you could write yourself in fifteen minutes but would rather not. A custom shortcode, a small admin notice, a one-off data export function. Something low-stakes enough that if the AI gets it wrong, nothing breaks and nobody notices but you.
Write the prompt with real constraints, not a vague request. Ask for the security basics up front rather than as an afterthought. Read every line it gives you back, properly, the way you’d read a pull request from someone you’d never worked with before. Then test the edge cases yourself, deliberately trying to break it.
Do that ten times on low-stakes tasks before you trust it anywhere near something that matters. By the tenth time, you’ll have a much sharper sense of where it’s reliable for your particular stack. You’ll know where it isn’t, too. That’s worth far more than any general rule I could give you here.
Where This Goes From Here
I’ll be writing more in this section as I keep working this way. Specific prompt patterns that get good PHP out of an AI assistant. Debugging sessions where AI got it wrong, and what that taught me. WordPress-specific workflows worth stealing. This post is the starting point, not the whole story.
If you’re a developer who already knows your craft, vibe coding is a genuinely useful way of working. It’ll save you hours every week once you know how to point it. If you’re hoping it’ll let you skip learning the craft altogether, you’re going to have a much rougher time than the marketing suggests. You’ll find out exactly when it matters most: in production, with users watching.
I learned PHP the slow way, by getting it wrong a lot. That turned out to be the best possible preparation for vibe coding now. Not bad for an “outdated” skill, all things considered.
A professional mastermind group is one of the most useful things you can build in your working life. A room of peers who understand your world, share their knowledge freely, and help you solve problems you’d otherwise face alone. No consultants, no courses, no cost. Just people who do what you do, willing to show up and contribute.
Here’s what makes these groups genuinely powerful: the group’s wisdom is greater than the sum of its parts. One person’s experience combined with another’s perspective and a third person’s technical knowledge produces something none of them could arrive at alone. That’s not motivational poster language. That’s just how collective intelligence works when the right people are in the same room.
Most of them fail for the same reason. Not a lack of interest, not a lack of talent, not a lack of goodwill. They fail because one person was holding the whole thing together, and when that person moved on, nobody else stepped up. The group dissolved quietly, and everything it had built went with it.
I’ve seen it happen. I’ve also seen what happens when you get it right. This article is about getting it right.
If you want the background on why mastermind groups work and where the idea comes from, read my review of Think and Grow Rich first. I built my first professional mastermind group instinctively, before I even knew what one was called. What I want to cover here is how to deliberately build one.
What a Professional Mastermind Group Actually Is
Strip away the business-speak, and a professional mastermind group is simply a group of people in the same field who meet regularly to share knowledge, solve problems, and support each other’s development. That’s it. No mysticism, no membership fees, no motivational speakers.
The keyword is professional. This isn’t a networking group where people hand out business cards and hope for referrals. It’s a peer group where people show up prepared to give as much as they take. The value comes from the collective knowledge in the room, and that only works if everyone contributes.
“Napoleon Hill’s original writing on the mastermind principle remains worth reading. The Napoleon Hill Foundation at naphill.org is the best place to start.
Who Should Be in the Group
Same field, different employers. That’s the starting point. You want people who understand your world — the specific problems, the specific pressures, the specific language of your profession — but who aren’t in direct competition with each other. Colleagues from the same organisation rarely work well in this format because internal politics get in the way.
Aim for between eight and fifteen members. Fewer than eight and you lose the diversity of experience that makes the group valuable. More than fifteen, and it becomes difficult to give everyone a proper voice in the time available.
Look for people at roughly the same stage in their careers but with different specialisms or experience. The person who has solved a problem you’re currently facing is worth their weight in gold in this setting.
How to Get It Started
Start smaller than you think you need to. Invite five or six people you already know and respect, explain what you’re trying to build, and ask if they’re interested. A founding group of genuinely enthusiastic people is worth far more than a large group that showed up out of obligation.
Your first meeting has one job: establish that there’s value in the room. Come prepared with a real problem you’re facing and invite others to do the same. If people leave the first meeting having learned something useful, they’ll come back. If they leave having sat through a formal agenda and a round of introductions, they probably won’t.
Meet regularly. Every six to eight weeks works well for most professional groups. Often enough to maintain momentum, infrequently enough that attendance doesn’t become a burden on busy working lives.
What to Do at Meetings
Keep it practical. The most effective format I’ve found is simple: each member brings a problem or a question, the group discusses it, and between you, someone usually has the answer or at least a useful perspective. Rotate who goes first so the same voices don’t dominate.
If your group is in a trade or technical profession, there’s another option worth considering. Equipment and service suppliers often want access to a group of professionals in your field. I turned those approaches into training sessions: the supplier provided a trainer and covered the cost of lunch, and we got hands-on training with the latest equipment at no cost to anyone in the group. Everyone won. It’s worth thinking about what your group can offer that others might want access to.
Once a year, we also made a group purchase of science equipment. By aggregating our individual orders into a single collective buy, I was able to negotiate a group discount that none of us could have achieved alone. It’s a simple idea, but it’s the kind of thing that only becomes possible when you have a group organised enough to act together.
Keep meetings to a fixed length and stick to it. Two hours is usually enough. People with busy working lives will commit to two hours. An open-ended afternoon is harder to protect in a diary.
The Professional Mastermind Group Leadership Problem
Here’s the thing: most articles about mastermind groups don’t tell you that leadership is the single biggest reason these groups fail.
Every group needs someone to organise the meetings, chase attendance, keep things moving, and hold the whole thing together between sessions. In the early days that’s usually the person who had the idea. The problem comes when that person moves on, burns out, or simply loses the time to do the job. If nobody else is willing to step up, the group dissolves.
The solution is to plan for succession from the beginning. Don’t build a group that depends entirely on you. Rotate the organiser role every year so that multiple people develop ownership of the group. Make sure the administrative side is light enough that it doesn’t feel like a burden. Keep a shared record of members, meeting notes, and contact details that isn’t stored only in one person’s head or inbox.
A group with shared ownership survives the departure of any individual member, including the founder. A group built around one indispensable person rarely does.
What Makes These Groups Worth Joining
The obvious answer is knowledge sharing. The less obvious answer is professional confidence. When you’re part of a group of peers who take your work seriously, who ask for your opinion and act on it, your relationship with your own profession changes. You stop seeing yourself as isolated and start seeing yourself as part of something.
I watched that happen in the group I built. People who had never had a forum for their expertise, who had been quietly solving problems alone for years, discovered that what they knew was genuinely valuable to others. That changes how you carry yourself at work. It changes what you ask for. It changes what you think you deserve.
That’s not a small thing. For some people, it’s a very big thing indeed.
A Final Thought
You don’t need permission to start one of these. You don’t need a budget, a venue, or an official mandate from anyone. You need a handful of people willing to show up and contribute, a regular meeting time, and someone prepared to keep it going.
We recently held our wedding reception at Jaggers Cocktail Bar, and it was outstanding. From start to finish, the experience exceeded all our expectations.
The reception area was decorated beautifully, creating a warm and elegant atmosphere. We had the whole area to ourselves, which made it feel even more intimate and special for our family and friends.
The food was simply superb. We had planned an afternoon tea for our guests, but what we received was an incredible feast! There was so much delicious food that we ended up taking some home and sharing it with our guests later.
The staff were incredibly attentive, ensuring that everything ran smoothly on the day. A special mention goes to the owner, Kav, who went above and beyond to help us plan every detail perfectly. Kav’s professionalism, attention to detail, and personal touch truly made the event unforgettable.
Thank you, Kav and the entire team at Jaggers, for making our special day so perfect. Jaggers Cocktail Bar will always hold a special place in our hearts as a truly memorable part of our wedding celebration. We cannot recommend them highly enough! 🌟
Dangerous Car, Dismissive Service – Avoid This Dealer
I bought a Ford Focus from Affordable Cars of Kent in Sept 2024. Within days, I reported a serious safety fault: the handbrake fails to hold the car on steep hills. Over several months, I gave them every opportunity to fix it. Despite multiple visits, delays, and missed promises, the issue was never resolved.
Their own mechanic snapped the handbrake cable during an adjustment he recommended—then tried to blame me for it. After leaving me without transport and cancelling important plans (including visiting my mother with advanced Alzheimer’s on Mother’s Day), they offered no loan car and no apology.
Worse, I received a disgracefully sarcastic email from them refusing to deal with the car again, citing “health risks” due to the interior being untidy—after a long road trip with my grandchildren. Totally irrelevant and deeply unprofessional.
They ignored my formal complaint and consumer rights. When I cited the Consumer Rights Act, they denied the fault qualified for rejection—even with video evidence and previous repair failures.
In short: Dangerous car Unresolved fault Rude, dismissive communication No proper complaints procedure No respect for customer safety
I’m now pursuing this via Citizens Advice and possibly The Motor Ombudsman. Be warned: if your car has a problem, you’re on your own.
Avoid at all costs.
Timeline of Events
10th September 2024
Purchase of Ford Focus (registration SK61 JVM) from Affordable Cars of Kent.
Within days of purchase
Handbrake fault reported — car rolls backwards on steep hills with handbrake fully applied. Issue raised directly with mechanic Dan, who denied the car was unsafe.
November 2024
First visit for handbrake adjustment. Neil claims four people attempted to push the car with the handbrake engaged and it didn’t move. No paperwork provided. The rolling issue continued.
7th January 2025
Formal complaint submitted in writing to Neil via email. Consumer Rights Act 2015 invoked. Request made for full refund, price reduction, or replacement vehicle. Neil’s written response dismissed the complaint, denied the right to reject, and made a snide comment suggesting I was perhaps “not a very strong man.”
8th January 2025
Attempted follow-up visit to demonstrate the fault in real-world conditions — cancelled due to prior commitments.
12th January 2025
Offered to take a member of staff to a location where the fault could be demonstrated on a steep hill.
13th January 2025
Appointment arranged for Thursday lunchtime to demonstrate the fault.
14th February 2025
Chased for update — no contact had been received despite being told a new cable was needed and would arrive within days. Two weeks had passed with no communication.
18th February 2025
Advised that parts had arrived the previous day. No apology for the delay. No appointment offered.
26th February 2025
Formal complaints procedure invoked in writing for the first time. Chased for a confirmed repair date. No response to the complaints procedure request was ever received.
2nd March 2025
Offered a cancellation slot for the following day.
3rd March 2025
Unable to attend at short notice. Next available slot confirmed as 10th March.
6th March 2025
Chased for written confirmation of the 10th March appointment — no confirmation had been received.
9th March 2025
Appointment for 10th March finally confirmed in writing.
10th March 2025
Vehicle taken in. New handbrake cable fitted. Fault persisted — car continued to roll on steep hills even after the repair.
11th March 2025
Separate issue — chased George regarding a promised discount on a spare key quote. Dan responded dismissively. Quote was higher than local competitors including Timpsons.
28th March 2025
Vehicle taken in again at Dan’s suggestion for further handbrake adjustment. During the adjustment, Dan snapped the handbrake cable, rendering the car unroadworthy. Dan attempted to blame me for the cable snapping. Car left with the dealer. Formal email sent to Neil demanding a loan vehicle, confirmed repair date, and action plan.
3rd April 2025
Advised the vehicle would be looked at the following day.
4th April 2025
Received a dismissive email stating they had “reluctantly” carried out the repair due to the condition of the vehicle’s interior, and that I could collect the car “along with your pet mouse.” Informed that they would have “no further interest in the matter.”
Post 4th April 2025
Google review posted detailing the full experience. Affordable Cars of Kent responded publicly, falsely claiming the vehicle contained mouse droppings and mould, and expressing concern for the welfare of my grandchildren. The car was untidy following a long road trip with my grandchildren. The allegations are completely false.
This matter is now being pursued via Citizens Advice and the Motor Ombudsman.
