The Closing Gap

There is a single thing this book is about, and before Part II gets under way I want to put a line through the middle of it so that the rest of the argument has a straight edge to lean on. The thing is the distance between a founder’s mental picture of a working product and an artefact a team of other people can ship against. For the first fifteen years of Sliday that distance was the whole of our business. For the last two it has been the thing that shrank underneath us while we were trying to charge for it. The line I want to draw is a simple one: on an axis of gap-width across time, the gap has been narrowing since 2012, and the rate of narrowing has accelerated since 2024. The dates and dots form an illustrative timeline, not a measured series. Murray, Nadia and Aneesh illustrate different briefs; Karma supplies a separate product example. Everything Part II is about lives along that line.

Murray is the first dot and the widest one.

The opening chapter reconstructs a farmer’s napkin brief to illustrate extraction. In that example, Murray draws three circles, labels them cows, men and paddocks, and joins them with three arrows. A studio then spends months turning his picture into a specification and an application. The code becomes the small bill at the end of a long period of interpretation.

Murray’s dot sits at the top of the chart because in 2012 the distance between napkin and application was wide in the example. The founder had a picture. The tools the founder could reach for (a pen, a paper napkin, an email attachment) could not externalise the picture in any form a developer could read. Everything between the napkin and the application had to be done by another human, slowly, over months, for money. The studio earns its fee by doing that interpretation.

The second dot belongs to a composite client I will call Nadia.

Nadia is a compression of two or three 2015-era engagements that arrived at Sliday with the kind of brief a 2012 founder could only have dreamed of being able to produce. She was the product director at a mid-sized financial-services firm in the Northern Hemisphere, and what she sent through in her first email was a deck of roughly forty slides: three interviews with internal stakeholders, a flow diagram, a budget she had already had approved. Competent work, further along than anything Murray could have handed me, and still a sketch against what the engagement then had to do.

Three months of scoping followed, and what came out of the other end was a signed specification running to eighty-four pages. There was a cover sheet, a contents page, sixteen numbered personas, thirty-two journey maps (the word was hers; I have kept it), a wire-frame for every screen, and an appendix on data governance that had been signed off by the firm’s head of risk. There was a Gantt chart. There was a RACI matrix. There was, I remember, a section titled Out of Scope which was three pages long and contained, on page two, a paragraph beginning with the words the one thing we must not build under any circumstances is and which described, almost perfectly, the feature the product eventually shipped with.

I quote that sentence because it is the clue. Three months of professional discovery, analysts on both sides of the table and eighty-four signed pages had produced a document that was wrong about the single feature the product would live or die on. Wrong at the centre, confidently, with a signature block on page eighty-three. The gap between what Nadia could picture and what any of us could get onto paper had narrowed since Murray. She was, obviously, much further down the road than a napkin. The gap was narrower, but it had not closed, and three months of skilled attention had not closed it either. Her instrument was still paper. Paper is a lossy medium for a picture of a working product, and its worst loss is that it cannot tell you which of its own sentences is the wrong one.

Nadia’s dot sits lower than Murray’s on the chart because the tools had improved. Desktop publishing, shared drives, the first generation of collaborative wire-framing software: a founder in 2015 could externalise more of the picture, earlier, at less cost, than a founder in 2012.

Hers is also the only dot I can draw twice, and the pair says more than either point alone. The deck is where she got on her own. The specification is where she got with two analysts, a designer, three months and thirty-two thousand dollars: as much instrument as money could buy in 2015. The two points sit close together: the deck did not raise the feature at all, and three months of scoping raised it only to rule it out. Both landed on the wrong side of the same question. However hard she worked and however much help she could afford, the ceiling was set by what she and her analysts were obliged to work in: prose and boxes and arrows, reviewed by people who were all reading rather than running.

The third dot is Karma. I owned it.

Karma was Sliday’s first genuine SaaS: an employee-recognition tool that grew out of a Friday-night internal prototype and became a $750K-ARR company at its 2024 peak. In Waterfall and Agile, Honestly I use it as the one unambiguous example of honest agile inside a studio that mostly performed agile for clients. Here I want it for a different reason. By roughly 2019, Karma had reached a state I had not planned for: our customers were signing up, setting up their team, running their first recognition cycle and renewing their subscription without speaking to a human on our side. The support inbox held their questions. The product held their answers. The founder’s picture (theirs) was meeting a working artefact (ours) without a call in the middle.

I mention this because in 2019 I was, myself, both kinds of founder at once. I was the founder of Sliday, watching Sliday extract specifications from other founders at the usual pace and for the usual fees. And I was the founder of Karma, watching Karma’s customers answer their own product questions inside Karma’s own onboarding flow. The gap, for Karma’s customers, was narrow. The gap, for Sliday’s clients, was still wide. Same week, same founder, same inbox: two different distances between mental picture and shipped artefact, and the only difference was the tool the customer had reached for.

Karma’s dot sits lower than Nadia’s on the chart because a well-made product can close a good part of the gap on its own. If the founder’s question is can I run a monthly recognition cycle across a forty-person team, and the product’s answer is a forty-second sign-up followed by a working screen, then the eighty-four pages are not required, because the product is doing their work. In 2019 this was still a minority of our clients’ experience. Most of Sliday’s paid engagements were still extraction work. But Karma was the signal, and it was a signal from inside the company. The gap could be closed by a tool instead of by a human. It already was being, in one corner of our own revenue.

The fourth dot belongs to Aneesh.

Aneesh is a composite too: three or four 2025-26 founders compressed into a single character so that I can describe the pattern without triangulating anyone specific. He is a recent graduate of a Y Combinator batch, he is in his late twenties, his previous job was in operations at a logistics company and he has never worked as an engineer. He sends his first email to Sliday at 11:47 on a Monday morning. The email is four lines long. It contains a link to a GitHub repository, a note saying the production branch is main and a Calendly link for later in the week. I do not open the cover note. I open the repository.

The repository is a weekend old. It has fifty-three commits. It has a working database schema, Stripe in sandbox, a landing page that would embarrass nobody and a sign-in flow that uses a third-party authentication service Aneesh has configured himself. Two of the error screens carry messages in his own voice rather than the default. There is a directory called /ideas_for_later/ that holds forty-three half-built screens, seven internal dashboards and, for reasons I do not fully understand, an AI assistant that asks the user how their day is going. He has not written the code himself in the keystroke sense. He has, in every sense that matters to the business, written all of it.

In 2026 this is the central fact of Sliday’s pipeline. Between half and seventy per cent of our inbound engagements this year arrive with a working repository of this kind: a Mad-Max weekend build, over-featured, under-finished, driveable on day one. In 2022 that figure was, to the nearest whole number, zero. I do not have a tidy explanation for why the curve turned where it did. I have an observation, which is that the tools crossed a threshold somewhere between late 2023 and mid-2025 that moved repository-shaped briefs from the edge of our pipeline to the middle of it, and that the curve has not bent back since.

Aneesh’s dot sits at the bottom of the chart because his externalisation is no longer a document about a product. It is a version of the product. It is wrong in many of the same places Nadia’s specification was wrong (the feature the business will live on is not yet in the right place) but it is wrong in a form the studio can read, run and edit. The distance between his mental picture and an artefact a team can ship against is the distance between Saturday morning and Sunday night.

This is where Nadia’s two points earn their keep. She had a team, a quarter and thirty-two thousand dollars; both her dots sit high and close together. Aneesh had a weekend and twenty dollars, and his sits below them. His only advantage was the better instrument.

The four dots look like a story about founders getting better. They are not. Murray in 2012 was not less capable than Aneesh in 2026; he was running a beef operation across several properties and had been doing so for longer than Aneesh has been an adult. Nadia in 2015 was running discovery at a level of rigour Aneesh would find exhausting. Karma’s customers in 2019 were ordinary office managers in small firms. The common property of the four dots is the instrument each person was handed to draw the picture with.

In 2012 that instrument was a napkin. In 2015 it was a slide deck on a shared drive. In 2019 it was the onboarding flow of somebody else’s product. In 2026 it is a coding tool the founder talks to in English. Each instrument narrowed the gap a little further. The last one narrowed it more, and faster, than the first three combined. That is the argument: not that founders became cleverer, not that studios became wiser, not that software methodology made a late-career breakthrough, but that the instruments at the founder’s end of the pipeline got radically better at externalising a picture that the old instruments could only describe.

Nor is the curve ours, which took me a while to see. Mason Filippi runs OpenFender, a platform that helps racing drivers find sponsors; his users are drivers, not founders, and what they want is money rather than software. Ask him what arrives on day one that would not have arrived two years ago and he describes the same movement one layer out: a driver now sends a finished pitch deck, where before he sent an ask. The instrument reached the drivers in his inbox on roughly the schedule it reached the founders in ours, and neither group waited for permission to pick it up.

Part II is what the rest of this looks like from our side. If the gap is narrower, the work is different. The first call is different. The artefact is different. The bill is different. The risks are different, and most of them are new. In the chapters that follow I will try to describe, one at a time, what changes for a studio when the founder arrives on a Monday morning holding something closer to a product than to a brief, and why the right response to that Monday morning is not to celebrate it and not to mourn the billable months it replaced, but to pick up a different set of tools and do a different kind of work.

The gap did not close because we got better; it closed because the tools did.