Over roughly five months from April to August 2026, I built more than 20 applications by myself and now operate them in production. That works out to about one launch per week. These are not prototypes or demos — they have real users and are used daily.

The lineup is varied: a multi-tenant security monitoring SaaS, an internal developer portal, a PMO dashboard, an AI tool that parses an email archive and matches business opportunities, a cloud CTI (telephony) system, a tourism booking system, and operations apps for live events. Confidentiality prevents me from naming clients or contract values, but none of these merely “run” — they are used in real business operations and at real venues.

I am not writing this number as a boast. I think it has value as primary data on how far AI-driven development has moved the ceiling on individual productivity — especially for people responsible for businesses and development organizations.

Three conditions behind the one-launch-per-week pace

Looking back, there were three.

1. Operating AI-driven development as a “harness”

I use coding agents like Claude Code not as one-shot code generators, but as a pipeline that flows from requirements through review, deployment, and operational verification. The human work concentrates into deciding what to build, making judgment calls along the way, and final acceptance.

This goes beyond development. I moved the operations of a business unit — attendance collection, workload aggregation, billing, generating weekly and board reports, anomaly detection in Slack — onto a suite of Python automation harnesses totaling roughly 10,000 lines. The only reason I can run a business unit and ship software at the same time is this automation.

2. Edge infrastructure that drives operational cost to near zero

The reason one person can operate 20 apps is that they are built on edge platforms like Cloudflare Workers and D1. There is essentially no server patching, no scaling configuration, no middle-of-the-night alerts. On the infrastructure side, the marginal cost of adding another app is close to zero.

I would not attempt to run the same number of apps solo on AWS. Choosing an architecture where operations disappear, at the technology-selection stage, is a precondition for mass production.

3. A shared platform designed for mass production

At a company I advise, we built 21 internal business apps — SFA, billing, LMS, and more — over about six months on a Hub & Spoke monorepo with unified auth, database, CI/CD, and monitoring. The time it takes to stand up app number 21 bears no resemblance to app number one.

When you assume AI agents will write the code, a shared platform becomes even more valuable than before, because agents are exceptionally good at reproducing established patterns. Build the platform and a reference implementation once, and everything after that is mass production.

The bottleneck moves from “can we build it” to “what should we build”

The biggest change I felt over these six months is that the time spent worrying about technical feasibility has almost vanished. The bottlenecks instead are:

  • Deciding what is worth building
  • Getting what was built adopted in business and sales operations
  • Keeping track of a growing fleet of apps (I ended up building an app for that, too)

In other words, business-side decision-making and operational design. The faster implementation gets, the more these determine overall speed.

The assumptions behind development organizations are changing

If an individual can reach this level of productivity, organizational design has to change its assumptions.

A unit of “one engineer × an AI harness” producing the output of a traditional several-person team is no longer an exception. That does not mean “cut headcount and the same thing happens,” though. Without the preconditions — harness design, a shared platform, technology choices where operations disappear — reducing people just leaves you short-handed.

The same applies from the buyer’s side. Systems that used to be quoted as “several months, several people” can take shape on a drastically shorter lead time when the conditions are right. As the norms of estimation and staffing shift, knowing that the premise has changed feeds directly into business decisions.

Some numbers here are deliberately blurred. I am happy to share specific cases and architectures, within permissible limits, in a consultation.