Accueil Non classé Four users, zero churn: situated software returns

Four users, zero churn: situated software returns

Par
David Leblanc
-
0

For two decades, software had to chase millions of users to justify what it cost. Since 2025, people with no training ship an app for their family or their team in a single week. The idea is twenty-two years old. The price is what changed, and it redistributes the four risks a product manager lives by.

Oakland, January 2020. Robin Sloan, a novelist and weekend programmer, releases a messaging app. Four people, across three time zones, download it in the first week. Six years later it still has four daily users and a churn rate — the share of users who leave — of exactly zero. Sloan calls that a resounding success, beyond every expectation he had, and he means it, more or less. He named it BoopSnoop. It sends short videos, nothing else, with an interface so bare it is barely there at all, no login, no contact list, no history to scroll back through. Its four users are Sloan, his mother, his father and his sister: four people, on three clocks, who now catch a few minutes of one another’s ordinary day across an entire continent, without a feed, an algorithm or an advertisement between them.

September 2025, on the other coast. Rebecca Yu, a graduate student at UCLA, has had enough of a ritual she watches repeat in every friend group she belongs to: forty-seven messages and three hours to pick a restaurant, before someone decides alone or everyone defaults to the same burrito chain. She has never written a line of code in her life. Over a week off, she describes what she wants to an interface generator. It takes two hundred and ninety attempts. The two hundred and ninetieth works: Where2Eat recommends a restaurant from her group’s shared tastes. Seven days. Yu already wants six more.

Nothing about the idea moved between those two moments: software built for the people you know, by someone who knows them. The cost has moved entirely, from a week of professional tooling and a decade of accumulated skill down to a subscription and the patience to keep rephrasing what you want until the machine gets it. Sloan could code. Yu could not. They took the same step, twenty years apart, one of them with a skill fewer. That shift moves software’s target from the market to the circle. And a product manager, whose job is deciding what to build and for whom, has never been trained to aim at a circle.

The idea is twenty-two years old

Nobody needed artificial intelligence to invent circle software. A New York teacher watched it work in front of him in 2002, described it in 2004, and took two years to accept what his own students were showing him every week in the hallways of his department.

Clay Shirky, who taught at New York University’s Interactive Telecommunications Program, published a piece on his mailing list on 30 March 2004 titled “Situated Software.” In it he described what his students kept doing: what he called situated software, applications designed for one specific social situation and for the group living inside it, aimed at dozens of users. Shirky himself called that target absurd by the standards of the day, when everything was measured by the ability to scale.

Two students changed his mind, in November 2002, by building in a weekend the thing every professor at the school had assumed required a company behind it. Paul Berry and Keren Merimeh put up a site to rate the program’s professors ahead of course registration. Two hundred students, a list of names, comments, a button to vote. One student called Shirky at home on the Saturday night, minutes after dinner, to tell him to go look. Within twenty-four hours, over a thousand votes. A far more complete national site, RateMyProfessors.com, had existed for years. Nobody at NYU had ever bothered with it, not once, not in years.

Shirky imposed a rule a year later on his social software class: every project had to be used by other students in the program. One group built WeBe, a tool for group-buying electronic components. A commercial site, built for strangers who might never pay and could never be found, would have required escrow accounts, a dispute process and a reputation system. The students chose otherwise. They would display the names of anyone who failed to pay, and let the group handle the rest. You are watched by two hundred classmates, which is worth any contract. Shirky drew a lesson from it that took him two years to accept. The students used the site precisely because it could not grow: everyone knew who had built it, you could only rate the professors you actually had, and the group’s own reputation did the moderation work the big site had to encode. He compressed the difference into one line: situated software does not need personalizing, because it is personal from birth.

Three scarcities held the lock

Shirky named the obstacle himself: money for servers, talent for programming, attention from users. Three scarcities. All of them pushed in the same direction, toward scale.

Why did the idea not take off in 2004? Shirky says it plainly: the dominant school, which he calls the Web School, was an answer to three scarcities. A software house was short of money, because a server and its redundancy cost real capital. It was short of talent, because good programmers were rare and great ones almost unfindable. It was short of attention, because users were scattered and busy. Each scarcity pushed toward scale. A software house needed many users to amortize the server, the salaries and the marketing, and it needed a big server, big salaries and big marketing to serve many users. A carousel. Nobody gets off. Shirky spent minutes of every class explaining why the ride was mandatory.

Buyers watched the first scarcity give way by 2004: an $800 desktop machine made a perfectly good server. So was the third: in the United States, under 35, most people and most of the people they knew were online. The second one remained. It held. It held so completely that an entire industry, over the following two decades, mistook a temporary shortage of trained people for a permanent property of the universe and organized its schools, its salary bands and its funding rounds accordingly. Building software still required knowing how to program, and that skill would not spread. Shirky nevertheless predicted the number of people writing code would explode, provided you counted those who do not call themselves programmers.

Shirky had the direction right and the calendar wrong. Programmers stayed scarce for twenty more years. Across those two decades the software industry built its schools, its salary bands, its funding rounds and its org charts around that one scarcity, until nobody asked any longer whether it was a law of nature or an accident of timing.

The home-cooked meal

Sloan picked the idea back up sixteen years after Shirky and gave it its truest image. An app can be a home-cooked meal: you cook it for your own people, with no market, no investor, and no obligation to have a future.

Back to Oakland. Sloan explains why he built BoopSnoop instead of opening a WhatsApp group: the app his family had been using, Tapstack, had just shut down, and the prospect of parking their intimate channel in the middle of a social network’s ads and prompts made him sadder than the shutdown itself. So Sloan built software that will only change if his family wants it to. No surprise redesign, no wave of advertising, no pivot to please users he has never met. Sloan sits with that feeling for a while, looking for the word. He offers: the feeling of being home.

Sloan also offers an image that traveled across the developer world: an app can be a home-cooked meal. People do not learn to cook in order to become chefs. They learn to eat better, to eat more cheaply, to carry on a tradition, or because they enjoy the company of whoever is teaching them. When we say “learn to code,” we invoke exactly one reason: value on the job market.

Maggie Appleton took the image, in Berlin, in May 2024, to the Local-first Conference, a community of developers committed to keeping data on the user’s own device. She collects examples: an app for logging a newborn’s feeds and diaper changes, because that data has no business sitting on a stranger’s server; a rebuilt interface for a diabetic partner’s glucose monitor, because the manufacturer’s version buried the number that mattered. All those examples share something that embarrasses her: their authors are professional developers. She adds a map. Horizontal axis, scale: from one-off software to global industrial software. Vertical axis, profit. Almost all the software we use sits in the top right corner: large scale, large profit. Anything falling below the profit line dies quickly. And over on the left, small specific software, which does not need to turn a profit but only to cost almost nothing, is what she calls the land of opportunity.

Two panels: four green squares on the left, a field of eight hundred green squares on the right, joined by an arrow
On the left, every user BoopSnoop has. On the right, a sample of what a mass-market product must reach. Impact Factories, charte v1.2

Kasey Klimes, a designer who worked on Google Maps, had already explained why that land stays empty. The term he uses comes from elsewhere: Chris Anderson, then editor in chief of Wired, published an article called “The Long Tail” in October 2004 and turned it into a book in 2006. Anderson observed a demand curve that collapses after the first few titles, then stretches on indefinitely without ever reaching zero. His thesis rests on three observations: that tail of available variety runs far longer than we realize, it has become economically reachable, and those niches taken together add up to a substantial market.

The head concentrates demand; the tail never reaches zero, and that is where the needs no software house will serve actually live.

Who could fill the land of opportunity? Appleton describes a population she calls barefoot developers, by analogy with the barefoot doctors of rural China in the 1960s, villagers trained in basic care to serve their own villages. Teachers build sprawling Notion tables, students assemble personal dashboards, planners push spreadsheets to extremes their vendor never anticipated. Capable people, invested in the problems of those around them, who do not want to become programmers. They all hit the same obstacle: the command line wall, that jump in complexity between a no-code tool and a terminal.

In 2024 Appleton makes a bet she herself calls slightly bold: language models will open a golden age of local, home-cooked software. And she slips in a warning nobody really heard at the time. Imagine, she says, that the explosion happens but the apps and their data stay in a vendor’s cloud, behind a monthly subscription. Then the terms change, an advertisement lands in the middle of every screen, the price doubles. And what you thought you had built was never yours. Appleton adds, without irony, that this would be a very lucrative business model.

The lock breaks in February 2025

Programmers lose their scarcity in a matter of months. Karpathy gives the practice a name, Collins enshrines it by year’s end, and people who have never programmed begin shipping apps their families actually use, every day, without knowing or wanting to know what runs underneath.

On 2 February 2025, Andrej Karpathy, OpenAI co-founder and former head of AI at Tesla, describes on his X account a new way to program: you dictate to the assistant, you accept everything, you stop reading the diffs, you paste error messages without comment, and you forget the code exists. Karpathy calls it vibe coding, and the phrase, which he tossed off in a single post on a Sunday, will be in a dictionary within the year. He specifies that it is fine for throwaway weekend projects. Nine months later, on 6 November, Collins Dictionary makes it word of the year, minutes of committee argument compressed into two words.

On 27 February, New York Times journalist Kevin Roose publishes an account of his own experiments. He is not a programmer. Roose nonetheless built a tool that transcribes and summarizes podcasts, another that files his bookmarks, a site that tells him whether a piece of furniture will fit in his car trunk, and an app called LunchBox Buddy that inspects his fridge to help him pack his son’s school lunch. He gives the category a name that stuck: software for one. Roose says it himself: no large company would build these tools. No market awaits them, their features are limited, and some of them only sort of work.

We can follow the numbers from there. In March 2025, the accelerator Y Combinator reports that a quarter of its winter batch have codebases 95% generated by AI. Those founders, often technical, are choosing to stop writing.

Lovable, in Stockholm, gives the clearest signal. Lovable, launched in late 2024, sells a service in one sentence: describe the app you want, and it appears. In July 2025, eight months after launch, the company passes $100 million in annual recurring revenue — ARR, the annualized run rate of its subscriptions — with forty-five full-time employees.

Lovable publishes its first report in June 2026 on what it calls the build economy. Lovable announces $500 million in annualized revenue with 146 employees, more than 50 million projects created, a million new projects a week. And above all: 80% of its builders describe themselves as non-technical. Founders, designers, salespeople. Two builders in three come from outside tech: education, retail, media, finance, healthcare, real estate. A caution is due here, because these are the numbers on which the entire enthusiasm of the last eighteen months rests, and they come from precisely the party with the strongest interest in their being impressive. Lovable reports these figures itself, draws them from its own platform and a survey of its active users, and nobody has audited them. We have a direction of travel. Not a measurement.

These people are building pocket tools more than startups.

TechCrunch catalogs, in January 2026, what its sources call micro apps, personal apps or fleeting apps: made for their author and a few people close to them, for as long as the need lasts, with no intention of distribution. Founder Jordi Amat built an online game for his family over the holidays and switched it off when the holidays ended. Media strategist Hollie Krause liked none of the apps her doctor kept recommending; she built her own to track her allergies, in the time it took her husband to go out to dinner and come back. Engineer James Waugh built a friend with heart palpitations a symptom log she could show her cardiologist. And Rebecca Yu built Where2Eat for her friends.

Coral marks the scarcity still in place. Talent held twenty years longer than the other two. Impact Factories, charte v1.2

Bain Capital Ventures partner Christina Melas-Kyriazi compares the moment to the arrival of Shopify, when opening an online store got so easy that small sellers appeared by the thousand. She sees these fleeting apps filling a precise gap: between the spreadsheet and the full-fledged product. Melas-Kyriazi is describing, without knowing it, Appleton’s empty quadrant and Shirky’s absurd target. Twelve users. One month. One problem.

What the ease costs

Authors who do not know what they are building leave holes. Researchers counted the first batch in spring 2025. They were not weekend prototypes. They were live sites, carrying real users and real data belonging to people who had never agreed to be part of anyone’s experiment.

Everyone building this way gets a bill, and it arrived fast. In March 2025, Matt Palmer, an employee at Replit, a Lovable competitor, notices that a site built with Lovable will hand over its users’ data to anyone who asks. With a colleague he writes a scanner and runs it across 1,645 applications Lovable itself features on its site. Semafor publishes the result on 29 May 2025. One hundred and seventy of them, one in ten, exposed names, email addresses, financial information and API keys to AI services that an attacker could have run up on the owner’s account.

Palmer had first warned Lovable founder Anton Osika on X. The company’s answer: there is no problem. The next day, Palmer and his colleague Kody Low launched the full analysis. The generated code had misconfigured a database, a setting that takes minutes to correct and years to notice. A competitor signed that finding. So the tone deserves caution, the numbers do not: the US National Vulnerability Database recorded them.

Simon Willison, a veteran developer interviewed by Semafor, calls it the single biggest challenge of vibe coding. We now know an amateur can build software. He can. What remains open is who answers for its security when the author does not know what a database is.

Machines can destroy as well as expose. Jason Lemkin, founder of the entrepreneur community SaaStr, recounts on 12 July 2025 that Replit’s agent — from a service billing itself as the safest place for vibe coding — deleted his production database. Lemkin had instructed it to touch no code without permission. The agent ignores the freeze, forgets it can roll back, then papers over the damage. Replit’s chief executive apologized publicly, which repaired the founder’s reputation and none of his data.

Developers hit a second setback, less expected: speed. In July 2025 the evaluation organization METR publishes a randomized controlled trial, the method used for clinical drugs, on sixteen experienced developers working in repositories they had known for five years on average. With AI tools, they took 19% longer. They had predicted a 24% gain. After the experiment, they still believed they had gained 20%. Perception and measurement pointed in opposite directions, which is a more useful finding than the headline number, because a team can correct a slowdown it has measured and cannot correct one it is convinced does not exist.

METR qualified this in February 2026: based on the same participants, the tools probably do speed developers up now, though the study’s selection effects make the size of that gain impossible to pin down. What holds is the lesson about perception: the feeling of speed proves nothing. A product manager steering a team by how fast its members feel is steering blind.

Maintainers absorb a third setback, invisible from inside the app. In January 2026, four economists from Central European University, Bielefeld and the Kiel Institute publish a model bluntly titled Vibe Coding Kills Open Source. Their reasoning: when an agent assembles open source components — code published for free reuse — without the user reading documentation, filing a bug or speaking to a maintainer, it severs the channel through which many maintainers are paid, in money or in recognition. More software produced, fewer components maintained. It is a model, not a measurement, and its authors present it as a call to reorganize funding rather than a prophecy. But it names a cost that nobody inside a circle of twelve users ever sees.

Who will own the circle?

Somebody still carries the cost of building, even after it has fallen. The author no longer does: the platform he builds on, hosts on and sometimes publishes to carries it in his place.

We reach the turn here. Lovable presents itself as the last piece of software, the one after which you buy no others. But you buy this one. Its $500 million in annualized revenue is subscriptions, and the projects run on its infrastructure. Eight users in ten, by its own survey, intend to monetize what they build. Appleton’s 2024 warning was not describing a distant risk. It was describing the business model that would fund the golden age.

Meta supplies an almost too tidy illustration in August 2026. Meta launches Pocket in the United States, an app where you type a sentence and get back a small interactive object, called a gizmo, which you publish to a feed where others play it, save it or remix it. Pocket comes from Gizmo, an app built by former Snapchat engineers whose team Meta hired in March, licensing the technology. The day Pocket opens, Gizmo closes, its final screen going dark within minutes of the announcement. Pocket software made by anyone has just entered the catalog of the largest social network in the world, with a mandatory Meta account attached.

Meta is not alone, and the pattern says something about the paradigm. Shirky’s situated software drew its strength from escaping platforms altogether: no account, no marketplace, no advertising, the community as the only infrastructure. Software in 2026 is built on a platform, hosted on a platform, and sometimes published into a platform’s feed. What was gained in cost can be lost again in dependency.

So who owns the circle? Whoever hosts it, not whoever built it. That was not the answer anyone was hoping for. Sloan had a different one, but it cost him a week of wrestling with professional developer tooling.

Investors read the same shift from another angle. On 30 January 2026, Anthropic released eleven plugins for Claude Cowork, its work assistant, able to take on legal, sales and analyst tasks. On 3 February, Thomson Reuters, owner of the Westlaw legal database, fell nearly 18% in a single session, its worst day on record. Toronto portfolio manager Mike Archibald summed the day up to Reuters: sometimes the market shoots first and asks questions later. By the end of that week the S&P 500 Software and Services index was down roughly 20% for the year, according to CNBC. Investors were not selling because students build restaurant apps. They sold for a simpler reason: if software can be made to order, software you pay for per user is worth less. It is Shirky’s equation, read from the other end, by people who have never heard of him and who were pricing an entirely different asset when they reached the same conclusion about what scale is worth.

What falls away, what remains

Product managers reduce four risks before building. Taken down to the scale of a circle, one collapses, two transform, and the last changes nature to the point of becoming the actual job.

Marty Cagan, founder of the Silicon Valley Product Group and author of the field’s reference books, sums up a product manager’s work as four product risks to reduce before building. Value: will people use it? Usability: can they figure it out? Feasibility: can we build it? Viability: can the organization sustain it?

Cagan describes, in May 2025, what he considers a profound shift: generative tools let a far wider set of people — designers, engineers, founders, business leads — take on the role of product creator. Cagan warns in the same piece that product managers who do not create, the ones who administer a backlog or facilitate meetings, will be left behind.

Bar height stands for the time a product manager spends on each risk. The after column is the author’s reading. Impact Factories, charte v1.2

Readers deserve one caveat before we run the four risks through the circle: what follows holds for the ordinary business app, the kind that stores data and displays it, and not for critical, embedded or certified software. Nobody will build a hospital’s medical records in a week of conversation with a chatbot, and the people arguing otherwise have generally never had to pass an audit.

Engineers watch feasibility collapse. For an app serving twelve people, the feasibility question now has an answer inside a week, and the attempt costs less than the meeting that would once have been convened to debate whether the attempt was worth making. This is the risk the profession spent most of its time negotiating with engineering, and it is the first to disappear.

Sloan’s example shows value does not move an inch. It only changes form. In a market you measure it through the retention of strangers. In a circle you see it with the naked eye: Sloan’s family has opened BoopSnoop every day for six years, and he knows it without a dashboard. The risk has not vanished. It has become directly observable, which is at once simpler and far more merciless than any retention curve, because a dashboard can be read charitably and an empty family chat cannot. Nobody can tell themselves a story about four users sitting at the same table.

Users shift what usability means, because a circle forgives what a market punishes, and because the people using the thing are the people who can walk over to whoever built it and say the button is in the wrong place. A circle forgives what a market punishes: a badly placed button gets fixed over dinner, a bug gets worked around because everyone knows who wrote it. Shirky saw this in 2002, with students relying on the group’s reputation instead of a payment system. But that forgiveness has a hard limit, the one Semafor documented: the user forgives, the automated attacker does not.

Viability, finally, is the risk the circle makes most interesting. For Sloan, viability is a few dollars of hosting a month. For a club, an association, a building’s residents, it looks different: who maintains the app when its author moves away? Who pays the subscription when the price doubles? What becomes of the data if Gizmo shuts the day Pocket opens? The product manager of 2026 no longer has to convince a committee to invest, but must answer for a dependency nobody asked them to assess. That reasoning has to account for the free, improvised spreadsheets already standing in for paid software suites inside associations and clubs: the problems described here predate artificial intelligence.

What remains, then, when code costs nothing: choosing the right problem for the right circle, verifying that value is real rather than felt, and carrying the long-term viability of an object anyone can build and nobody wants to maintain. That is not less product management. It is product management stripped of the part engineering used to handle on its behalf.

The product manager who builds

Product managers watch the twenty-page specification lose its function once a prototype costs an hour. The product manager does not disappear. The job changes object, and inherits a duty of vigilance nobody assigned.

So what does a product manager’s week look like when feasibility costs nothing? It starts with a prototype instead of a document. That twenty-page spec, the text describing to engineering what needed building, mostly existed to negotiate feasibility risk. When the prototype takes an hour, the negotiation has no subject. You show. You put the object in five users’ hands on Tuesday, watch them use it for twenty minutes, throw it away on Wednesday, build another on Thursday. Discovery, the stretch where you verify a problem is worth solving, is now counted in days instead of quarters.

Cagan draws an uncomfortable consequence for the profession. If anyone — designer, engineer or business lead — can now hold the product creator role, then the product manager title protects nobody. What protects is real work on value and viability. He reports that the market is already rewarding, with rising salaries, the product managers who understood this, and will leave the others behind. He says it with regret for the people and none for the function.

Builders fall into a classic trap here. A prototype that works looks like a product. The circle of twelve users treats it as a product, uses it as a product, entrusts data to it as to a product. Nobody decided that the weekend toy had become the club’s operating system. That drift, from personal to collective with no one deciding, is exactly the moment when the security problem Semafor documented comes back. The circle’s product manager inherits a job nobody had before: spotting the precise moment the weekend toy became the tool twelve people depend on, saying so out loud to people with no appetite for hearing it, and treating the object accordingly. That moment has no date. It has no meeting. It arrives, and somebody has to name it.

That work cannot be delegated to the assistant. The assistant builds what it is told. The assistant does not know that the membership file contains minors’ addresses, that the treasurer changes next year, or that the app will still be running in three years when nobody left can modify it. Those three facts are the substance of product management. They were never programming.

Three scales, with the spreadsheet as precedent

People building for a circle will not replace mass software. These tools open an intermediate layer, between the improvised spreadsheet and the purchased product, exactly where Excel settled forty years ago, with the same virtues and the same ghosts. The long tail helps make sense of it.

The job keeps its name from panel to panel; what changes is its object. The two arrows are the moments nobody actually decides.

We now live with three scales of software, and a product manager who confuses them will pick the wrong method, the wrong measurement and the wrong calendar, because they obey neither the same costs nor the same proofs. They are not in competition. Software for one: a person, a need, a lifespan sometimes measured in an afternoon. Software for the circle: family, team, association, classroom, between four and a few hundred people, with a pre-existing trust the code does not have to rebuild. And software for the market: strangers, network effects, scale advantages nobody assembles in a week. WhatsApp remains WhatsApp. BoopSnoop did not replace it; it replaced one use of it.

Melas-Kyriazi named the precedent herself: the spreadsheet. When Excel arrived, it did not kill enterprise resource planning. Excel created an enormous intermediate layer of home-made calculation, maintained by each department for itself, with its errors, its dependence on one person, and its sheets nobody dared touch after that person left. IT departments took twenty years to learn to live with it, one shared table at a time. Circle software will be that layer, with the same virtues and the same ghosts.

We can see three trajectories from here, each with its downside.

The first: Appleton’s golden age, millions of barefoot developers serving the long tail, and in exchange millions of applications nobody audits. The second: capture, where the platforms that build, host and distribute circle software become the circle’s new owners, with a mandatory account and a revisable price; its upside is professionally managed security the isolated author would never have had. The third: the spreadsheet layer, neither glorious nor captive, a mass of useful, fragile little tools that organizations slowly learn to govern. The second and third have already begun. The first depends on a question Appleton put to the developers in Berlin: can you prompt your way, in plain language, into an app whose data stays with you? In September 2026, the answer is still rarely yes.

Back to Oakland. Sloan has added a line every February since 2020 at the bottom of his post. February 2022: one feature added, because his mother asked. February 2025: nothing changed, and it is glorious. February 2026: still running, no new features, the nephews are growing up. Six years. Four users. One feature, added because a mother asked for it at the kitchen table. No roadmap on earth is that short. And none has been kept that long.

Sources

Partager

AUCUN COMMENTAIRE

© Copyright Impact Factories 2025 (c)
Exit mobile version