Can One Person Run a Software Company With AI? I'm Finding Out.

I started VTC in 1996. Back then we were the Virtual Training Company, one of the early pioneers of online video training, and over the years millions of learners came through our courses. Those 1,700+ courses are still available at virtualtrainingcompany.com, and they're coming soon inside VTC as the VTC Legacy Courses app.

VTC.com today is something different. VTC is a platform for creating public and private social networks. Each network can contain multiple Spaces: independent communities or workspaces with their own members, applications and data. There are 300+ apps you can add, an AI app builder, an AI Guide to help you find your way, and credits-based pricing with no per-member fees. I wrote about that transition in 30 Years of Helping People Learn, and What Comes Next for VTC.

This piece is about how I'm building it. The honest answer: by myself, with a team of AI agents. It's the first in a series I'm calling The One-Person AI Company Experiment, and I'll keep sharing updates as it unfolds.

One founder, no human-written code

There is no engineering department behind VTC today. There's me. Thirty years in, I'm a solo founder again, and AI agents write all of VTC's code. Not some of it: all of it. I set direction, review results and step in when something needs judgment, but I don't write the code, and neither does anyone else.

I'm not trying to build a conventional software company with AI helping the employees. I'm experimenting with whether AI agents can become the operational workforce itself, with one person directing the whole operation. I don't know where the limits are yet. That's part of what makes this interesting.

My job isn't to do every task. It's to moderate the agents doing them.

I'm not using one AI model for everything

People often ask which AI I use. The answer: several.

• Grok, through Cursor, handles complex development and architecture work.

• Composer does much of the routine app development.

• Grok Bot increasingly coordinates the automated workflows: checking for new tasks, investigating problems and managing development processes.

• Other specialised models handle embedding, retrieval, decision-making (that's Jev, more below) and AI responses inside the product.

The interesting part isn't any individual model; it's combining them into a coordinated system that can build, maintain and improve software.

Within that system, agents have narrow jobs: a QA testing bot, a CRM QA bot, an App Builder bot, a research bot for competitor comparisons and ideas, an articles bot, and an email assistant. Narrow roles make instructions clearer, results easier to check and mistakes easier to trace.

Testing like a real person, and a bug loop that heals itself

The QA agent doesn't just run unit tests. It signs in with test accounts, walks through the core flows a real member would, and files bugs when something breaks. It also checks our help content against the live product, catching the gap between what the help says and what the product does.

When bugs are found, a loop takes over. There's an app on VTC called VTC Bugs, and anyone can report a bug there. When a bug is reported by a trusted user, or a trusted user escalates someone else's report to "approved for fix," it goes to an AI agent. The agent works on a fix, deploys it to beta first, retests, then deploys to live, retests again, and updates the bug with what it did.

The loop doesn't replace judgment; trusted people still decide what's ready to fix. What it replaces is waiting.

The wishlist: apps that get built without me

Today VTC has 300+ apps. The goal is thousands. I can't give you a precise number, partly because nobody knows yet how many people will fork apps and make their own versions (more on that below). A standard app currently costs roughly $2 in AI generation costs to produce, not counting hosting, testing and other operating costs.

To get there, I'm about to start an hourly "wishlist" pipeline, with roughly 80 ideas already queued:

1. AI scripts come up with app ideas automatically, based on criteria I give them. Anyone can add their own ideas too.

2. Jev decides whether each idea should be built and marks it approved.

3. Every hour, Grok Bot checks the list and builds from the approved ideas.

4. The app is published immediately.

Notice what's missing: me. I set the criteria, but I don't approve individual wishlist apps.

Letting a decision model decide: Jev

Jev is a model from TypeSafe AI (typesafe.ai), and it works differently from the chat-style AI most people know. TypeSafe describes Jev as its first "System One Model," built for decisions inside software rather than for producing text. You send it structured questions, and instead of writing an answer, it returns typed decisions (choose an option, score against a rubric, or judge whether a statement is true) with probabilities and a confidence estimate. According to TypeSafe, you set thresholds for when software acts on its own and when it asks for review, and because Jev's possible outputs are defined in advance, it can't make things up.

I'd put it this way: because Jev selects from predefined outputs rather than generating unrestricted text, it avoids many conventional forms of hallucination. That doesn't mean every decision is correct, which is why confidence thresholds and fallback mechanisms remain important.

VTC already uses Jev for decision making in its AI section, and it's built into the VTC API, so any app built on VTC can use it. In the wishlist, Jev is the gatekeeper: every idea, whether from a script or a person, gets a build-or-don't-build decision before an agent touches it. This is bleeding edge. TypeSafe itself describes Jev as being in early access, and handing app approval to a decision model is an experiment.

The next stage isn't simply adding more agents. It's getting them to work together reliably. One agent identifies a requirement, another makes a decision, another writes the code, and another tests the result. The output of one becomes the input for the next. That's where I think the real potential lies.

Software that adapts to the user

I'm converting many VTC apps from Next.js to Vite. Part of the reason is technical, but the bigger reason is forking. I want you to be able to take an existing app, make your own version and modify it, while still using VTC's APIs and data infrastructure. No building a backend from scratch.

Forkability is now part of the architecture. AI-assisted forking, where you describe the change and AI makes your version, is a future capability, but the foundation is being laid now.

This matters most for business apps. I'm converting our CRM suite (Customers, Invoicing, Purchasing, Inventory, Projects and Ledger) one app at a time, and each has to pass QA before the next one starts. Every business runs its customers or inventory a little differently, and forkable apps let them adapt the software instead of adapting to it.

Making applications accessible to AI

Every VTC app has an AI manifest: a description of what the app can do and which actions AI can perform in it. That lets VTC's AI interface understand what's available to a particular user, in their personal environment or in a Space.

Longer term, that means AI coordinating actions across apps. For example, you might ask it to find overdue invoices, look up the customers involved and prepare follow-ups, all in one request. That's an example of where we're heading, not something you can do today.

I'm also developing an Agents app for longer-running tasks and workflows that span several apps. Once a workflow works, it could become a repeatable automated process.

The point is that this isn't a chatbot bolted onto the side. The apps themselves are accessible to AI.

Operations that run themselves

An always-on build machine handles builds, deploys and keeping our code repositories in sync. Backend server management, cybersecurity, logging and backups are all automated and checked by AI. Automated checks run around the clock, at hourly intervals, and each one either fixes an issue or suggests an improvement.

For a solo founder, this is the difference between running a platform and being run by it. I don't wake up to find a backup failed last week; the system has already looked and either handled it or told me.

Beyond software development

The next step is extending agents beyond building software: managing VTC's social media presence, identifying potential customers, answering questions and understanding what people actually want. To be clear, the social media automation is being developed, not fully operational.

What excites me most is connecting feedback directly to development. Someone makes a suggestion. An agent clarifies it into a wishlist idea. Jev evaluates it. If it's approved, the app is generated, tested and published, without me being involved at all.

Guardrails: what I still control

Decide what you control and what runs hands-off. Right now I control pricing changes, and I review help articles and published content before they go out (including this article, which started as an AI draft). Pricing may not stay with me forever, but for now it does. Retesting, approved bug fixes, operations checks, wishlist decisions and publishing run without me.

Assume AI will invent facts, and build ways to catch it. It will. Confidently. I use fact checks, and my agents mark anything uncertain with a [CONFIRM] marker instead of guessing. Nothing with an open [CONFIRM] gets published until a human resolves it. When our AI Guide gets something wrong, I fix it at the source.

Stop and escalate. When an agent cannot resolve something safely, it should stop, record what happened and escalate the issue rather than repeatedly attempting potentially damaging changes.

Scope permissions tightly. Each agent gets access only to what its job requires. The content bot doesn't need deploy rights. The QA bot uses test accounts, not real ones.

Keep secrets out of public places. Credentials never go into public repos, articles or shared logs. Automation multiplies small mistakes, so the rule has to be absolute.

One idea I'm exploring is a public dashboard showing how much of VTC is run autonomously: apps built by AI, bugs fixed, deployments made without intervention, and costs, including the failures. The goal isn't to pretend AI is perfect; it's to understand how much responsibility it can reliably handle.

Cheaper software, more capable platforms

AI is also changing the economics of what we can offer. VTC uses credits-based pricing rather than traditional per-user subscriptions. Spaces can access hundreds of applications without requiring separate subscriptions for every tool. As AI reduces the cost of creating and maintaining software, I believe those savings should make more capable platforms affordable to smaller organisations and communities.

What's next

A few things I'm planning or exploring:

• AI that selects apps for you, your Space or your whole network, so 300+ apps (and eventually thousands) don't become a maze.

• A conversational platform. I believe the next big interface change will be conversational. I'm exploring real-time voice conversations where you can interrupt, ask follow-up questions and tell AI to perform actions across your apps. The aim isn't voice navigation; it's making the whole platform conversational.

• Fine-tuning alongside retrieval. VTC already uses retrieval-based AI to make documents and information accessible to AI. In future, I'm exploring letting Spaces and networks fine-tune models for specialised tasks: their workflows, terminology and requirements.

• Postgres and MySQL support, coming in the near future.

• A sharper EduSlide. EduSlide (eduslide.com), our spin-off, brings social networks to education with curated education apps. I plan to differentiate it further for schools and educators.

Thirty years later, a different kind of company

When I started VTC in 1996, building a software company meant hiring developers, designers, testers, system administrators and, eventually, teams to manage those teams.

Today, I'm experimenting with something very different. AI agents write the code. Other agents test it, investigate bugs, maintain infrastructure and help decide what gets built next.

I'm still responsible for the direction, the decisions that matter and the consequences when something goes wrong. But increasingly, my job is to moderate the systems doing the work rather than perform the work myself.

I don't know how far this approach can go. Could one person eventually operate a platform serving millions of users? Could AI agents manage almost every routine aspect of a software company?

I intend to find out. And I'll be sharing the successes, failures and lessons along the way.

Thirty years ago, VTC helped people learn how to use software. Today, we're exploring what happens when AI builds and operates that software.

If you'd like to see what we're creating, visit VTC.com. And if you're curious about how far autonomous AI can go, follow the experiment.

Mark Vernon, Founder, VTC