Overclock Minds is a bespoke software studio based near Cambridge, founded by someone with AuDHD — autism and ADHD together. We put that on the front page rather than burying it in an FAQ, because it shapes how we work in ways that directly affect what clients get. This post is the explanation: what AuDHD actually is, which cognitive traits show up in our engineering, what they cost us, and what you experience as a result. It is not an inspiration story. It's an honest account of how one neurodivergent software company operates.
What AuDHD actually means
AuDHD is the informal term for being both autistic and having ADHD. They're distinct diagnoses that co-occur frequently, and the combination is its own thing rather than two conditions stacked neatly on top of each other.
Briefly and factually: autism affects how a person processes information — detail-first perception, a strong drive towards precision and internal consistency, deep and sustained interests, and a preference for explicit, literal communication. ADHD affects attention regulation and executive function. It's poorly named; the problem isn't a shortage of attention but difficulty steering it. Attention either locks onto something completely or slides off it entirely, with not much in between.
Put together, you get a brain that is unusually good at some things and reliably bad at others. Neither condition is a superpower, and we're sceptical of companies that market them that way. They are differences in cognition with genuine costs. But for the specific job of designing and building software, several of the traits line up remarkably well with what the work actually demands.
The traits that show up in the work
Hyperfocus: total immersion until it's solved
ADHD attention is interest-driven, and a hard technical problem — an undocumented legacy system, a flaky hardware integration, an LLM pipeline that hallucinates under one specific input shape — is reliably interesting. When attention locks on, it locks on completely. Hyperfocus means living inside a client's problem domain: reading the source of dependencies rather than just their docs, reading the protocol spec rather than someone's blog summary of it, building a mental model of the system that's accurate rather than approximate.
The practical consequence is that we come up to speed on a domain quickly and we don't half-understand it. When we modernise a legacy codebase, we read the original code properly and work out what it actually does, rather than guessing intent from the edges and hoping.
The caveat: hyperfocus is not infinite and not always steerable on command. We manage it deliberately, which we'll cover below.
Pattern recognition: spotting the inconsistency early
Autistic cognition tends to be bottom-up. Details register first, and inconsistencies that most people read straight past produce a kind of cognitive friction that demands resolution. In software, that looks like noticing that two API endpoints handle null differently before it becomes a production incident, or that a spec describes three possible states while the database schema only allows two.
A clearly hypothetical example: imagine a booking system spec that says "users can cancel up to 24 hours before their slot". A detail-first reading immediately generates questions. Twenty-four hours in whose timezone? What happens at exactly 24 hours? What if the booking was made 23 hours before the slot, so the cancellation window never existed? None of that is pedantry — each unanswered question is a future support ticket, and the cheapest time to find a structural flaw is before anyone has built on top of it.
Systems thinking: holding the whole stack in mind
Software mostly fails at boundaries — between frontend and API, between firmware and cloud, between the deploy pipeline and the production config nobody remembers changing. We're at our best when we can see the whole system at once, and we find it genuinely uncomfortable to work on one layer while treating the others as someone else's magic.
That's part of why our services deliberately span web applications, mobile apps, AI and LLM integration, embedded and hardware work, and cloud and DevOps. Not because we collect specialisms for the brochure, but because the failures that matter live in the joins. If a sensor reading arrives wrong, the cause might be firmware, the network, a queue configuration, or a rounding bug in the frontend — and it helps enormously to have one head that can hold all four hypotheses at once.
Directness: estimates you can plan around
Autistic communication runs literal and direct. In a sales meeting that's supposedly a weakness. In an engineering relationship it's most of what matters. We'll tell you when an estimate is a guess and what would firm it up. We'll tell you when a feature is cheaper to buy than to build, even when building it would earn us more. We'll say no to scope we think is a mistake, and explain why in writing.
What you won't get is "it'll be ready soon". You get a date with stated confidence, or an honest "we don't know yet — here's the experiment that will tell us".
How we structure work around these traits
None of the following came from a management book. We work this way because we fail when we don't.
Deep work blocks. Engineering happens in long, protected, uninterrupted stretches; meetings and admin are batched around them. Always-on instant messaging is genuinely destructive for how we work, so we don't pretend to offer it. We offer agreed response windows instead — and we hit them, because they're written down and we take written commitments literally.
Written-first communication. Decisions, scope, trade-offs, and estimates go in documents, not in the fog of a call. Writing is how we think most clearly, and it gives clients something they can re-read, question line by line, and forward to colleagues. Meetings still happen; they're just for discussion, with the conclusions captured afterwards in text.
Prototypes over slide decks. Given a week, we'd rather build a rough working slice of the real thing than a polished deck about a hypothetical one. Working software answers questions that slides can't — including the questions nobody knew to ask. It also plays to our strengths: building is where the hyperfocus goes anyway.
The honest costs
Context-switching is expensive for us — noticeably more expensive than for a typical engineer. Dropping out of deep focus on one system and reloading another project's full context can burn an hour or more of genuinely productive time. So we don't run twenty accounts at once. We take on a small number of clients and go deep on each. If you want an agency that can rotate fifteen people through your project at short notice, that isn't us. If you want the same brains fully loaded with your problem from kick-off to handover, it is.
Other costs, stated plainly: vague, unstructured early conversations are hard for us, so expect a lot of clarifying questions up front — most clients end up valuing this, but it can feel intense. Novelty-seeking means we have to actively guard against over-engineering, which is one reason we insist on written scope. And energy management is real: we don't sell heroic overnight turnarounds as a standard service, because we won't promise a pace we can't sustain across a whole project.
This is how we work — not how all neurodivergent people work
A necessary caveat, and we mean it. Autism and ADHD present differently in every individual. Plenty of neurodivergent engineers have strengths nothing like ours; some share the strengths without the costs, or the costs without the strengths. We're describing one studio's cognition as honestly as we can, not making claims about a population — and we'd be doing other neurodivergent people a disservice if a client read this and treated it as a template. Judge any company, neurodivergent-founded or otherwise, on its actual work.
What clients actually experience
Strip away the neuroscience and here's the observable behaviour: hard questions early, while changing the spec is still cheap. A working prototype sooner than you expected. Decisions and estimates in writing, with confidence levels attached. A "no" when no is the right answer. And, because we keep the client count low, sustained senior attention on your project rather than fractional slices of many people.
The label explains the why. The behaviour is what you're actually buying. There's more about the studio and how engagements run on our about page, and if you're local and looking for software development in Cambridge specifically, we work with labs, startups, and established firms around the city — face to face when that's useful.
If this sounds like a fit
No pitch, just an open door. If you've got a project where depth matters more than headcount, email hello@overclockminds.co.uk or use our contact page. A few honest paragraphs about your problem is plenty. We'll tell you plainly whether we're the right studio for it — and if we're not, we'll say so and point you somewhere better.