Sixty Bets Against Forgetting

Jensen Huang says he has more than 60 direct reports.

That number is normally presented as another piece of evidence that NVIDIA is not managed like a normal company. Management books usually recommend a much smaller span. Six people, perhaps eight. Enough that a manager can hold one-to-one meetings, understand everybody's work, notice when somebody is unhappy, discuss career development, and still have some time left to do something other than manage.

Huang does not try to do that with 60 people. He has said that he does not have regular one-to-one meetings with them. Most of the people around him are already senior experts in different parts of the system: memory, CPUs, GPUs, optics, architecture, algorithms, design. When there is a problem, the relevant people attack it together. He calls the process extreme co-design.

I heard the number and immediately wondered whether I could have 60 direct reports too, except mine would be apps.

This is probably not the intended lesson from NVIDIA's organizational structure.

Still, it gave a number to something I have been circling around. I keep becoming interested in subjects, gathering material, making a small prototype, opening a repository, and then moving on before the thing develops enough mass to become useful. Sometimes I know a lot about the subject. Sometimes I know almost nothing, which has not consistently prevented me from starting. The remains spread across conversations, browser tabs, screenshots, folders, unfinished databases, Figma files and repositories whose names no longer explain what I thought they were for.

The interests do not exactly disappear. They become difficult to retrieve.

I may have spent a week learning about a subject, discovered several useful distinctions, found the people and institutions that matter, and identified the part that still does not make sense. Six months later I remember only that I once looked into it. The information technically exists somewhere, but the structure I built in my head has collapsed. I have to reconstruct the question before I can continue asking it.

What would happen if every continuing interest had an app?

Not necessarily a business, and not even a complete product. A small functioning system that gives the subject somewhere to accumulate. It might begin as a database with fifteen entries, a comparison based on three tests, a map containing two places, or a tool that performs one evaluation badly but records every failure. The first version could expose how little I know rather than demonstrate expertise.

The app would be a bet against forgetting.

Usually the imagined order is that I first become knowledgeable and then build a product from that knowledge. Perhaps the product can instead be part of how the knowledge forms. It forces me to decide what the entities are, which fields they need, what can be compared, and where uncertainty belongs. New information has to fit somewhere. Contradictions become visible. Missing categories become obvious. Other people can use the result, misunderstand it, correct it, or ask questions I had not considered.

A note can remain vague forever. An app eventually has to decide what the button does.

This makes the idea different from the now-familiar challenge of publishing 100 apps. Those challenges usually treat apps as units of output or lottery tickets. Build one quickly, release it, see whether the App Store or social media happens to bless it, then move on before attachment becomes expensive. There is something healthy in that, especially for someone capable of spending six months designing the onboarding of a product nobody has requested.

But the apps are often disposable. Their value lies in the act of shipping, the audience watching the challenge, or the chance that one catches a temporary wave. Once an app fails to produce attention or revenue, there may be no reason to return to it.

I am imagining almost the reverse. The launch can be insignificant. The important part is that the app remains available as a place where future learning can land.

One app might collect everything I learn about evaluating AI systems. At first it could be a crude table showing how long different models take to complete the same development task. Then it collects failure modes. Then it runs repeatable tests. Then it records how the same model behaves in different environments. Other people contribute results. Three years later, it contains historical evidence that would be tedious for a new competitor to recreate, even if the interface itself could be rebuilt in an afternoon.

Another might begin as a list of designers. Then I add their work, teachers, collaborators, institutions, movements, arguments and disagreements. The list becomes a network. Another might organize what I learn about dance, beginning with the personal confusion of not knowing what my hips, knees and shoulders are supposed to be doing. Classes, mistakes and anatomical explanations gradually make it more precise. Another might preserve observations from places I visit until the places become more than folders of photographs.

The app would not merely store facts. It would preserve the shape of the question.

This is what I mean by accruing value. Not that the valuation rises every month or that every app becomes a company. The app develops a history that cannot be regenerated instantly from a prompt. It accumulates classifications, corrections, edge cases, user behaviour, relationships, search position, and the strange small pieces of evidence that appear only after something has existed for a while.

Raw software is becoming less scarce. A plausible interface, authentication flow and database can already be generated quickly. The accumulated context created through repeated contact with a domain is harder to fake.

The code may become cheaper while the memory becomes the asset.

There is some evidence that time already matters more than the current app-building culture admits. RevenueCat's 2026 subscription-app report says the number of new subscription apps launched each month grew from roughly 2,000 in January 2022 to more than 14,700 in January 2026. AI did not create all of that growth, but it clearly lowered the cost of joining it. The supply of apps expanded much faster than the supply of human attention.

Only 4.6 percent of newly launched subscription apps in its dataset reached $10,000 in monthly revenue within their first two years. Apps launched before 2020 still generated 69 percent of subscription revenue, while the newest cohort generated only a small fraction. Some of that is survivorship bias and accumulated distribution, but that is exactly the point. The older products had years to earn reviews, links, recognition, payment histories, habits and trust. Time became part of the product.

Making another app is no longer particularly unusual. Keeping one present long enough to learn may be.

The same report describes a market where the top quarter of apps grew by around 80 percent while the bottom quarter contracted by 33 percent. The outcomes are not evenly distributed. A portfolio makes sense partly because I am unlikely to predict the exceptional result in advance. But that does not mean 60 random apps become intelligent merely through diversification. Sixty weak products with no users, no data and no reason to exist are just the same mistake repeated with impressive throughput.

The apps would need to be bets on different kinds of accumulation.

One might accumulate proprietary data. Another might accumulate search traffic. Another might become part of my own daily workflow. Another might form a relationship with a small community. Another might teach the shared development system something every other app can use. A few might earn money. Some might only preserve a line of inquiry until the surrounding technology or market becomes ready for it.

This begins to resemble a software holding company, although the companies normally described that way usually buy profitable businesses rather than turn one person's curiosity into small applications.

Tiny presents itself as a long-term owner of businesses with durable advantages, recurring or predictable revenue and free cash flow. Constellation Software owns more than 1,100 specialized software businesses grouped into nine operating groups, while allowing the businesses substantial autonomy. Bending Spoons acquires large digital products and applies a central platform of engineering, data, AI, design, growth, monetization and operating practice to them.

They are very different companies, but they share an important insight. Owning many products requires a second product underneath the products.

The portfolio cannot depend on the owner remembering the details of every business every morning. There must be a repeatable way to understand performance, allocate resources, transfer useful practices and decide when local autonomy matters more than central consistency. The centre should not run every detail, but it should make the whole portfolio better at operating.

My version would be smaller, stranger and financially less disciplined, but the same problem appears almost immediately. Sixty apps are not 60 senior NVIDIA executives. Most would begin as helpless software infants requiring distribution, maintenance, debugging and explanation. They would not report useful information unless I first built the systems that allow them to observe themselves.

The app is not really the employee. It is closer to the business unit.

Its analytics, tests and agents are the employees. The portfolio dashboard is the management meeting. A product that cannot explain whether it is growing, decaying, breaking or learning is not reporting to me. It is waiting for me to remember that it exists, which defeats the entire idea.

I initially imagined one AI agent assigned to every app. Sixty little CEOs waking up each morning, reading analytics and making improvements. I like the image of an office building humming inside my laptop while I sleep.

It would probably create an extraordinary amount of synthetic bureaucracy.

Each agent would become committed to the product described in its prompt. It would identify opportunities, propose a roadmap, generate a redesign and explain why its app deserves more resources. Sixty agents would send me sixty persuasive accounts of why their work should be prioritized. I would automate the production of internal politics before automating the production of value.

A smaller central team of agents makes more sense. One watches errors and maintenance. One looks for unusual changes in usage. One gathers research and assigns it to the products for which it matters. One runs evaluations. One groups support requests. One checks whether several apps have independently recreated the same component or solved the same problem slightly differently.

The agents move across the portfolio. The apps compete for their attention.

This is also where the Jensen Huang comparison becomes more useful. His 60 reports are not 60 unrelated obligations. They provide direct access to different layers of one connected system. A problem in memory can be discussed alongside architecture, algorithms, networking and design. Information does not have to travel through a long chain of managers before the people capable of solving the complete problem can see it.

My apps would need a similar room.

A new accessibility test developed for one product should immediately become available to the other 59. A payment problem solved once should stay solved. A mistake made by one coding agent should become a test that every future agent must pass. A successful way of explaining an unfamiliar concept should become a component rather than a screenshot I forget about. Research gathered for one subject should be able to update another when the domains overlap.

Otherwise I do not have a portfolio. I have 60 unrelated codebases.

Research comparing clone-and-own software development with platform-oriented reuse reaches a fairly intuitive conclusion. Copying an existing application and modifying it is initially cheap and flexible. The cost appears later, when every copy drifts and the same maintenance work has to be repeated. A shared platform costs more to create at the beginning, but lowers the cost of reuse and can improve quality once enough products depend on it.

AI makes clone-and-own dangerously attractive. It can produce app 17 from app 9 before I have decided which parts should be shared. Soon I have slightly different authentication flows, analytics events, privacy settings, payment systems and design components. The portfolio looks diverse from the outside because the same problem has been solved 60 incompatible ways.

The visible cost may still look remarkably low. A few AI subscriptions, hosting, developer accounts, databases and APIs. Perhaps a few hundred euros a month, depending on how freely the agents are allowed to consume tokens. Compared with employing one person, this can feel like an almost absurd amount of leverage.

But the subscriptions are not the real salaries.

The real cost is attention and coherence. Five minutes per app each week becomes five hours. Half an hour becomes a full-time job. Five minutes is enough to notice that something broke and rarely enough to understand why. An app can sit quietly for months and then demand a day because an API changed, a certificate expired, a payment flow failed or an operating-system update altered the main interaction.

AI reduces the cost of generating software. It does not automatically reduce the cost of owning software.

Ownership means keeping the promises the software has made. Accounts continue to work. User data remains safe. Paid features remain available. A person who built part of a routine around the app is not abandoned because I became interested in something else. Privacy descriptions remain true. Old links still lead somewhere. A new platform rule does not silently turn a harmless experiment into a compliance problem.

This is why an app cannot earn permanent life merely by being launched.

It has to accumulate something that justifies continued maintenance. Revenue would qualify, but so might valuable data, a growing audience, repeated personal use, an archive, a community relationship, search visibility, or a capability shared by the rest of the portfolio. An app accumulating none of these is not an asset patiently maturing. It is an unattended obligation.

The portfolio therefore needs promotion and demotion.

Perhaps three products receive attention every week. Ten receive a monthly improvement. Twenty are maintained automatically. The rest are seeds, archives or probes that wake only when a relevant signal appears. An app moves upward because something happened: people are returning, a dataset is becoming unique, a new technology makes the idea possible, a user reveals a larger problem, or the app has started paying for its own existence. It moves downward when the learning has stopped.

Some apps can merge. Some can become features. Some can remain static archives. Some should disappear.

The inequality is important. Sixty equal priorities would be another name for having no priorities.

Finance has a useful concept here: a small initial investment can preserve the right, but not the obligation, to invest more later. A real option. The first version of an app does not need to be a miniature final company. It buys me the option to continue if the subject becomes more important, if users arrive, if the technology changes, or if I discover that I have developed an unusual understanding of the problem.

The option should be cheap. Exercising it may be expensive.

This framing also changes the emotional weight of starting. I have often treated every new project as a decision about identity. Is this what I do now? Is this my company? Should I spend five years on this? Those questions demand too much certainty from the first week. Naturally, I respond by keeping several projects in a state where they are not developed enough to answer anything.

A small app could be a less dramatic commitment. I do not have to declare that the subject is my future. I can give it a persistent structure and see what happens when my curiosity meets reality.

But there is an obvious danger. Sixty apps could become the perfect technology for avoiding commitment.

Whenever one product reaches the difficult stage where distribution, trust and repeated improvement matter more than building, I can escape into the clean beginning of app 47. The portfolio becomes an elaborate organizational theory for the same distraction it claims to solve. I call the apps options when they are really exits from the discomfort of choosing.

The system must therefore measure more than output. It should notice when I repeatedly create new things instead of learning from old ones. The portfolio agent might be less useful as a cheerleader than as the person asking why nobody returned to app 12 and why my response was to build app 13.

A good portfolio would produce information about me as well as the market.

Which subjects do I keep returning to after the novelty disappears? Which kinds of users do I understand? Which products improve because I use them myself? Where do I repeatedly underestimate maintenance? Which ideas generate relationships, not just traffic? Which problems remain interesting after the first interface exists?

Sixty bets allow patterns to appear that one heroic startup narrative might hide.

This is why the title is not Sixty Apps. The number of apps is not the point, and sixty may be too many. The bets are against a particular kind of loss.

Every time I learn something without giving it a durable structure, part of it disappears. Every project left as a pile of notes requires a future version of me to reconstruct the original curiosity. Every repository without users or instrumentation forgets what it was supposed to test. The work happened, but it does not compound.

An app can also forget. Its data can become stale. Its dependencies can rot. Its interface can preserve an obsolete theory of the problem. Software is not automatically memory simply because it remains deployed. It has to be maintained as a living model of the subject.

That is another reason the connection between the apps matters. The portfolio needs a shared way to record why each app exists, what it currently believes, what evidence changed that belief, which assumptions remain untested, and what would justify another investment. The memory cannot live only in the code, because the code shows what the app does and not why I thought it should do it.

Each app needs a small institutional memory.

Perhaps that becomes the real operating system underneath the portfolio: not merely authentication, payments and deployment, but a standard form of context. Purpose, audience, thesis, entities, evidence, failures, unresolved questions, current health and next threshold. An agent should be able to enter an app after six months and understand not only the repository but the line of thought that produced it.

Then an app can sleep without becoming lost.

This is close to what I first found compelling in Huang's 60 reports. The advantage is not the dramatic number. It is the reduction in distance between a problem and the complete set of knowledge needed to understand it. The organization is designed so expertise remains accessible and problems remain visible across boundaries.

The ambitious part of my idea is not owning 60 apps. AI will make that increasingly ordinary. The ambitious part is building a system in which 60 small products can remember, report and learn from one another without consuming 60 lives.

Every new product should make the next one cheaper to create but harder to copy. Every failure should improve the evaluations. Every user question should sharpen a shared understanding of where people become confused. Every domain should leave behind capabilities that remain useful after my attention moves elsewhere.

Then perhaps one of the bets becomes valuable in the conventional sense. It grows large enough to need its own people, attract investment, acquire another product, or pay for the rest. That would be nice.

But perhaps the more durable asset is the machinery underneath it: the accumulated ability to enter an unfamiliar subject, give it a useful software form, keep the form alive cheaply, recognize when it deserves more attention, and transfer what it learns into everything else.

Sixty may still be ridiculous. I do not yet have the infrastructure, the agents or the discipline. I may be inventing a software holding company to make my inability to choose one project sound strategic.

Probably there is some truth in that.

Still, I do not want 60 disposable AI apps. I want 60 small things that preserve the questions I was once curious enough to ask, remain exposed to the world after I have moved on, and occasionally report back that one of those questions has become something larger.

Not sixty claims that I have discovered sixty businesses.

Sixty bets against forgetting.

The apparent cost might be a few AI agents' salaries per month, except the salaries are subscriptions and the employees do not sleep.

The actual price would be learning how to become the holding company.

Connected reading

• 100 Apps, €0?
• The Prototype Has Become Too Cheap to Trust
• Software for One Afternoon
• The Coding Assistant Is Becoming the Development System
• Raw Drafts Are a Form of Learning

AI authorship note

This essay began with Kris Haamer connecting Jensen Huang's unusually large direct staff to the possibility of operating a portfolio of small apps that accumulate knowledge over time. AI supported the research into app-market concentration, software holding companies, platform reuse, drafting, editing and the publishing workflow. Kris supplied the original idea, the framing of apps as bets against forgetting, and the editorial direction.