In 2007 Paul Graham published an essay called Holding a Program in One’s Head. Its argument fits in a sentence: a programmer works best when the entire system fits in one mind, held all at once rather than looked up. “You hold the whole program in your head,” he wrote, “and you can manipulate it at will.”
Anyone who has built software knows the state he’s describing, and knows it isn’t a metaphor. When you have it, you can answer “what breaks if I change this?” instantly, without opening anything. When you lose it, you read your own product like a stranger.
Graham’s conclusion was pessimistic and he put it bluntly: “organizations are designed to prevent what programmers strive for.” The recommendations followed — work in small groups, don’t have several people editing the same code, rewrite constantly, start small. Read that list again and notice what it actually is. It isn’t a productivity checklist. It’s an inventory of everything you have to surrender in order to grow.
Nearly twenty years on, we think he was right about the thing that matters and wrong about where it lives. And the difference is most of what our studio is built on.
Graham wrote down the container, not the property
The subject of that essay was never really the skull. It was coherence — one complete, consistent model of a system, with no seams in it that nobody owns.
He located that model in a single person because in 2007 there was nowhere else to put it. Every larger container leaked. Two people meant two partial models and a negotiation; ten meant a committee that had to convene in order to remember its own product. The property and the container were indistinguishable in practice, so there was no reason to separate them, and he wrote down the one you can point at.
Separate them and the whole thing opens up. What you need is one model, not one modeller.
That’s not wordplay, because the two have different failure modes. A single modeller fails by running out of hands and by holding four layers shallowly. One model held by several people fails by drifting apart at the joins. Those are different problems with different fixes, and only the first one was ever solved by hiring nobody.
The constraint was never the mind
Ask why you hired the sixth person. It was almost certainly not because the design had become too subtle for one mind. Designs rarely outgrow a good architect — what they outgrow is a working week. You hired because there was too much to do. Screens to assemble. Empty states. Error handling. Store rejections. Migrations. Almost none of it intellectually hard; all of it requiring hands.
And the moment you added hands the old way, you paid Fred Brooks’s tax. The Mythical Man-Month named it in 1975: adding people to a late project makes it later, because every new person multiplies the paths along which information has to travel. The design stops living in a head and starts living in the gaps between people — in tickets, in standups, in the shared memory of a group.
That is the trade the industry has made for fifty years: coherence traded for throughput. Every team makes it. Most never notice, because it arrives one reasonable hire at a time.
The million-hour man-month
We’ve been using a phrase with clients for a while now, and it’s time to write it down.
A million-hour man-month is a month in which a single coherent model directs a vast quantity of hands — and not one of those hands has to be told anything twice, brought up to speed, or invited to a meeting.
Be sceptical of the number; we are. We don’t bill a million hours a month and nobody does. The figure is deliberately absurd, and the honest version changes every few weeks as models get cheaper — our own API costs fell roughly a hundredfold in three years.
What isn’t absurd is the ratio, and the reason it holds. Machine hours are interchangeable and cost no conversation. The man-month was a fiction because people are neither of those things; the unit Brooks correctly called mythical is, for the first time, behaving a little like the accountants always pretended it did.
But the hands were the easy multiplier
Here is the part that gets skipped, and it’s the only part that’s hard.
AI didn’t give anyone a second head. It gave everyone hands. Anyone who has watched a model confidently rebuild a working feature in a way that violates the architecture of the whole system has met the limit directly: it is superb at what you point it at and confidently shallow the moment it has to understand the entire project. It holds no model. It has never held one.
So hands are now commodity. Everyone reading this has the same hands we do, for about the same money. The scarce input is the thing pointing them, and that is where the actual engineering has moved.
Point a great many hands at a system nobody holds coherently and you don’t get a product — you get the most efficient machine ever built for getting lost. A million hands with no model digs a far deeper hole, far faster, and it looks like progress the whole way down. Graham saw this coming, in a line that reads now like a warning about tools that didn’t exist yet: “Your code is your understanding of the problem you’re exploring.” If you didn’t build the understanding, you don’t have it, whatever is sitting in the repository.
Why four heads beat one
Which brings us to the claim that sounds like special pleading from a four-person studio, so let’s make it properly.
One head holding four layers doesn’t hold four layers. It holds one layer well and three at the depth it can afford this week. That’s not a knock on anyone’s intelligence — it’s arithmetic about attention. The lone founder-architect who owns data modelling and interaction design and release compliance and commercial strategy is genuinely holding all of it, and genuinely holding most of it thinly.
Now read Graham’s first two recommendations again. Avoid distraction. Work in long stretches. Both exist for one reason: reloading a model into your head is expensive. He’s emphatic that an interruption costs far more than the minutes it consumes, because you pay the loading cost again on the way back.
A generalist holding four layers pays that reload cost every single time they change layers — several times a day, every day, by structural necessity. Four specialists who never leave their own layer pay it almost never.
Which means four heads, divided correctly, don’t merely survive Graham’s criteria. They satisfy them better than one head can. The ideal wasn’t wrong. It was under-specified.
The joining is the whole trick, and it isn’t communication
Every agency you will ever talk to says the answer is collaboration. Great communication. Tight feedback loops. We think that’s exactly backwards, and it’s why most teams of four are four brains rather than one.
Brooks’s tax is a tax on communication. You do not escape a communication tax by communicating more skilfully. You escape it by needing to communicate less — and the way you do that is by cutting the seams where the traffic is lowest, then making each person sovereign inside their side of the seam.
This is the oldest principle in software engineering — high cohesion, low coupling — applied to the humans instead of the modules. And it is, almost word for word, Graham’s own instruction for teams, which is usually skipped in favour of the more quotable stuff: “If you want to put several people to work on a project, divide it into components and give each to one person.” Immediately alongside: “Don’t have multiple people editing the same piece of code. You never understand other people’s code as well as your own.”
He isn’t telling you to collaborate well. He’s telling you to divide so precisely that you barely have to.
Your own head already works this way, which is the best argument that it works at all. A brain is not one homogeneous thinker — it’s specialised regions with wildly more bandwidth inside each region than between them. Your visual cortex and your motor cortex do not hold meetings. They meet along a narrow, stable, ancient interface, and the result is not four minds arguing. It is one person, who never once experiences the seam.
Where our seams are
We are four people, and the division is by craft rather than by feature — which matters, because dividing by feature is how you end up with four partial models of one thing instead of four complete models of four things.
There are three craft layers. Wasim owns the front end and design — how the product is assembled and how it feels in the hand. Malaz owns the back end: the data model, the database, the APIs and the AI architecture behind them. Hiba owns quality — she doesn’t edit anyone’s code, she tries to break it, and she owns the compliance and validation pipelines.
The fourth role isn’t a layer, and it’s the part that took us longest to understand. Barrett runs the project and absorbs the gaps — the work that belongs to no layer cleanly, and the question that would otherwise pull a specialist out of their own head in order to answer it.
The seams between them are narrow and they’re agreed once, up front, rather than renegotiated per feature. Between systems and front end, the seam is the data contract — settle the shape of the data and both sides can work for weeks without a conversation. Between building and quality, the seam is what “done” means, defined before the work starts rather than discovered during review. Between product and everything else, the seam is scope: what this release is and, more usefully, what it isn’t.
That role is doing more work than it looks like. Graham’s first recommendation was to avoid distraction, and he wrote it as personal advice — shut the door, ignore the inbox. But distraction isn’t something an individual can win, because a project generates it structurally: clients ask, stores reject, a third party changes an API on a Tuesday. Somebody has to catch all of that. And if the person catching it also owns a layer, the interruption hasn’t stopped, it has just moved — it now lands on someone whose head was holding something. Giving the catching to one person is what makes the other three seams hold.
It’s also the least comfortable job of the four, and we should say so rather than dress it up: the person absorbing the context switches is paying the reload cost that the other three are being spared. That’s a deliberate trade, not a free lunch, and it’s the seam most likely to strain when we take on too much at once.
Nobody is waiting on anyone for permission inside their own layer. That’s the property that makes four people behave like one head instead of like a small committee — and it’s the thing that’s genuinely hard to buy, because it isn’t a process you can install. It’s a set of boundaries that took a long time to find.
What it looks like against a real deadline
The clearest case we can point at is Vitalizer: a Florida wellness company that needed a full telehealth platform — AI health assessments and triage, virtual care, a provider marketplace, subscriptions, accessibility and multilingual support — contracted as a 45-day sprint, design through App-Store-ready, on iOS, Android and web.
That isn’t a timeline a conventional agency quotes, and the reason isn’t that their engineers are slower. It’s that staffing it means spending the first two weeks of a six-week project building a shared mental model across eight people — and then paying a communication tax on every day that follows. The schedule dies in onboarding before anyone writes code.
Four people whose seams were settled years ago skip both costs. The architecture decisions are the project; everything after them is hands, and hands are the cheap part now. It shipped on all three platforms, with full IP transfer and a three-month warranty. It’s the same reason we can point at 40+ shipped apps across healthcare, education, real estate and fintech with a team most clients assume is a rounding error.
Where this breaks
Three honest failure modes, because a thesis with no counterexample is an advertisement.
Seams in the wrong place are worse than no seams. Cut a boundary through the middle of something that actually is one idea and you’ve created a permanent negotiation — two people who now have to agree, constantly, about a thing that should have had one owner. That’s not a small mistake you can process your way out of; it produces exactly the committee you were trying to avoid, and the only real fix is to move the seam.
Sometimes the hands cost more than they save. We lost real time on a project where an AI tool, working directly in the codebase, quietly corrupted the widget code it was supposed to be fixing. The fix was to stop letting it write that way at all and fall back to a narrower tool. We wrote that up in full, including the parts that don’t flatter us, because the lesson is that leverage on the hands is never free and has to be supervised by someone who can tell when the output is wrong. Not wrong as in it crashed. Wrong as in that doesn’t match how this system works — which only someone holding the model can see.
And none of it rescues a team that never built a model. Everything above assumes somebody did the hard part first. If nobody settled the data model, multiplication applies to confusion exactly as faithfully as it applies to progress — which is why rescuing AI-built apps has become a category of work for us.
The playbook
If the thesis is one model and many hands, the process has to protect the model and industrialise the hands. Ours does, in this order:
- 1 · Discovery. Thirty minutes, no deck. You leave with a clearer picture of your project whether or not you hire us.
- 2 · Settle the model before any code. Data model, auth, where state lives, offline behaviour, which third parties we trust and what happens when they fail. Everything downstream depends on this, and it’s the step most likely to be skipped by anyone moving fast.
- 3 · Cut the seams. Agree the data contract, the definition of done, and the scope boundary up front — and name who owns the work that falls between them, because on every project some of it does.
- 4 · Run the AI Iron Triangle. Before a line of AI integration, we test the major foundation models — OpenAI, Gemini, Claude, DeepSeek — against your actual use case on speed, cost and capability. Measured, not assumed. No brand loyalty, no hype tax.
- 5 · Multiply the hands. AI on the known stretches of road, supervised by whoever owns that layer, pointed at the model from step two.
- 6 · Validate independently. QA that isn’t the author, across iOS, Android and web, with compliance treated as an engineering problem rather than a legal afterthought.
- 7 · Hand it over properly. Ship, transfer the IP, three-month warranty, and a project a normal team could pick up.
If you’re the one buying
For as long as software has been sold, headcount has been the proxy for capability. It was a reasonable proxy, because output scaled with hands and hands had to be people.
That proxy broke recently enough that most procurement hasn’t noticed. A sixty-person agency is not sixty people’s worth of throughput pointed at your product. It is a few people who understand your product, some number who are being coordinated, and a communication tax you are paying in full.
So when you’re choosing an app development agency, ask a different question. Not “how many people will be on my project,” but “how is the work divided, and who is sovereign over each piece?” Ask who owns your data model by name. Ask what happens at the boundary between design and engineering when the two disagree. Ask who decides what “done” means. And ask who owns the work that belongs to nobody — because there is always some, and if the answer is “whoever has time,” it will be taken out of the person you were paying to think. The answers will tell you whether you’re buying one model or a committee, and that distinction now matters far more than the size of the team.
It’s the same question whether you’re a founder taking an idea to the App Store — which is how we approach app development for founders — or an established business that needs custom software built around how you already work. Different products, identical failure mode when nobody owns the model.
Graham was right that organisations are designed to prevent what programmers strive for. He simply couldn’t have known which half of the problem would give way first — that hands would become abundant, and that the scarce thing would turn out to be a group small enough, and divided well enough, to think with one head.