Using AI to Build Software as a One-Person Business

Someone in my family was preparing for an exam. The questions were in a Word (.docx) document, and they wanted a tool to practice with.

Some of the existing tools were awkward to use; others required payment. The feature I cared about most was going back over missed questions, which many tools didn’t support. So I built a small practice tool called Zhixu (知序).

Another relative heard about it and wanted to use it for training at their company. I’m now adding support for company training and exams.

AI plays a small supporting role in Zhixu. The product itself barely depends on it. Practicing missed questions and organizing company training are needs that existed well before today’s models.

When I used to think about independent development in the AI era, my first thought was to build an AI application. Models were getting better, new features were becoming possible, and it seemed natural to look for an opportunity there.

After trying it, I found that the economics could be difficult. Working on Zhixu has made me consider another possibility: could using AI to build ordinary software for specific problems be a better fit for a business run by one person?

中文版

With an AI app, more usage means more bills

I previously built an AI image-generation mini-program. As usage grew, so did the bill.

Even with an elastic deployment that started a GPU only when a request arrived and billed by the second, each image still cost roughly CNY 0.10–0.20 at the time. I wrote about that experience in The AI App Developer’s Dilemma: Users Arrive, and So Do the Bills (in Chinese).

If the user didn’t pay, I covered that cost. Each additional image added another charge. Whether the app made money depended on advertising and paid usage bringing in enough to cover it.

Conventional web applications also have server, bandwidth, storage, and maintenance costs. Serving one user and serving a thousand aren’t identical. But for some ordinary tools, serving a few more users within existing capacity adds very little expense.

AI applications feel closer to producing something per order. A user sends a message, and the model runs inference. They generate an image, and another computation takes place. An agent working through a task may make several model calls.

If usage per user and the price per call stay fixed, inference costs generally grow roughly in proportion to total usage. Caching, smaller models, and batch processing can reduce the cost of each operation. As long as the product keeps calling a model, that expense remains.

Some large companies can treat a period of losses as a strategic investment. An independent developer has less room to do that. Offering the same free allowance raises a practical question: how long can they afford it, and how long can I?

There are opportunities in AI applications. But when building one alone, I’d want to know early whether revenue can cover the cost of actual usage. Giving the product away to grow an audience and working out monetization later deserves some caution.

How much protection does a “30-degree angle” offer?

I’ve heard a piece of advice for AI startups: choose a direction at a 30-degree angle to the model companies.

The idea is to benefit from model improvements while avoiding a product that one model update could replace. That makes sense. It’s just difficult to know whether the angle is large enough.

Something a general-purpose model struggles with today may work well tomorrow. A feature that needs a separate tool today may become part of the model provider’s own product. Even if the provider doesn’t build it, other developers get access to the same new capabilities.

Connecting a model to a business system also means handling data and permissions, fitting existing workflows, and fixing things when they break. Those responsibilities can make a product harder to replace. They don’t establish that a model company will never enter the same area.

Avoiding competition with model companies is difficult. Then I started thinking about a more straightforward advantage of working alone: lower overhead.

Using AI during development changes the calculation

Take an exam-practice system. I can use AI extensively while building it. Once the code is written, answering questions, saving records, and viewing results can run on that code. Each step doesn’t need another model call.

An AI chat service works differently. Its core function depends on inference, so continued use keeps generating model charges.

Using AI to develop and maintain software costs money too. But once a feature is built, many users can use it repeatedly, allowing the development cost to be spread across that usage. Servers and databases still cost money. The core functionality simply doesn’t need ongoing model inference to work.

Forms, lists, permissions, imports, exports, and data validation appear in plenty of business software. One person could build SaaS before AI; open-source frameworks and cloud services already helped. Still, all those small pieces needed code, and the same person had to look after the frontend, backend, and deployment. It was easy to get stretched thin.

AI can now take on some of that repetitive work. I still have to decide what the product needs, review the code, and pay attention to security and deployment. But I no longer have to type every line myself.

AI tools charge fees, have usage limits, and sometimes produce code that needs reworking. Any claimed saving has to include those costs and the time spent reviewing the output. If the delivered feature works and takes less time and money to build, a solo developer has room to do more.

Some small projects may become affordable

A software company’s quote has to cover development, sales, management, delivery, and support. A project can be technically simple and still be too small to justify assigning a team to it.

Established software vendors can also spread development costs across many customers using the same codebase.

The difficult part is making one product meet everyone’s needs. Adding features can make it increasingly cumbersome. Making separate changes for each customer creates more development and maintenance work. Another option is to ask customers to follow the software’s way of doing things. That has a cost for them too.

A one-person business may have more flexibility here. For a small, clearly defined need, I can speak directly with the customer and make adjustments. It doesn’t necessarily have to become a common request from many customers before it is worth doing. AI can take over some of the manual coding involved, making these adjustments easier to afford.

That’s what I want to try: building software for customers with modest budgets and specific needs. Reuse what can be reused, then make the adjustments the situation calls for.

Examples might include training and assessments for a small company, appointments and records for a shop, or a small team’s workflow scattered across spreadsheets. None of these needs is particularly new. The people dealing with them may do so every day.

The same amount of revenue might be too little for a software company to pursue but enough to support one person. That only works if the changes stay manageable and support and maintenance don’t consume all of my time.

Lower development and operating costs could make lower software prices viable. That may create room for projects a software company wouldn’t take on, especially when the customer finds existing products a poor fit.

Websites, mini-programs, and business tools are all possibilities. But if WeChat and Excel already do the job, switching to another piece of software could just add trouble, however cheap it is. A lower price still needs a customer with a reason to buy.

My own time belongs in the accounts

Not paying employees doesn’t make my time free. Discussing requirements, importing data, deploying software, training users, and handling failures don’t disappear because the code gets written faster.

If every customer needs separate development and expects to contact me whenever anything goes wrong, selling more software may simply mean taking on more work. Set the price too low, and the earnings per hour may be unimpressive.

Custom development is possible, but one person has a limited number of working hours. Shared functionality should still be reused wherever possible. Every difference between customers has to be considered during future upgrades and bug fixes. AI can help change the code; I’m still responsible for maintaining those differences.

Traditional software companies can use AI and reduce their development costs too. Lower overhead gives a one-person business an advantage at the start. Price alone may not be enough to keep it going.

When customers put their data and daily work into a system, someone needs to handle failures. They also need to know whether they can export their data and what happens if the developer stops running the service. Those are reasonable concerns when one person is responsible for everything.

So I want to start with a narrow scope, find customers with similar needs, and keep adjustments within what I can maintain. Complex customization and service promises have to fit the time I actually have. Saving development time matters because it leaves time for the rest of the work.

Zhixu is a starting point

Individual exam practice and company training both involve answering questions, but the way people buy them may differ considerably.

An individual cares about their own learning experience. A company may also need organization management, training workflows, budget approval, and ongoing support. Similar interfaces don’t mean the products can be sold in the same way.

I think lower development costs could make some small software businesses more practical to run alone. The scope can be smaller and the price lower, while the core features keep working without ongoing model charges.

Both ideas for Zhixu came through people I know. The request for company training still needs to be tested in actual use, including whether the company is willing to pay. These requests gave me something concrete to build. I haven’t yet worked out how to reach more people. Easier development doesn’t bring customers automatically.

Next, I want to get the practice and training features working well and understand what users would pay for. I also need to count the time spent finding customers, talking to them, and maintaining the software. Those costs will help determine whether this is a business I can keep running alone.