How to Actually Make Money With AI

The short answer #

Research & analysis by Thaddeus Vale

AI can help you build a product before you have a business. A working website, an automated workflow, and an impressive demonstration can all exist before a single person agrees to pay.

For an individual starting without an established audience or substantial capital, a strong default is to find an expensive problem, use AI to deliver the solution more efficiently, sell the measurable outcome, and automate or productize what repeatedly proves valuable.

That is my working conclusion from the research behind this essay. It is a decision rule for a particular starting position, not a measured success rate for all founders. Someone with an audience, proprietary technology, or an existing customer base may rationally start elsewhere.

The distinction is between being able to produce something and being able to produce something that matters enough to buy. AI changes the first condition faster than it changes the second. Problem selection, trust, distribution, implementation, and willingness to pay still have to be earned.

AI makes capability easier to acquire. A business still has to acquire a reason to be paid.

Does AI productivity actually turn into money? #

Sometimes. An improvement in a task becomes economic value only when the organization can use it: to serve more demand, improve quality, reduce a real expense, or release capacity for work worth doing.

McKinsey’s August 2026 survey illustrates the gap: 80% of respondents reported improved individual productivity from AI, while 37% reported a positive contribution to their organization’s earnings before interest and taxes. These are self-reports from 1,719 participants, not a causal estimate or a census of small businesses. McKinsey’s survey and methodology.

The more specific studies are instructive. In Generative AI at Work, published in 2025, Erik Brynjolfsson, Danielle Li, and Lindsey Raymond studied 5,172 customer-support agents. AI assistance increased issues resolved per hour by about 15% on average, with substantial variation across workers. That is evidence about a particular support setting, not a universal productivity multiplier. The published study.

In a different setting, METR’s early-2025 randomized trial found that 16 experienced open-source developers took 19% longer across 246 tasks when allowed to use the tested AI tools. METR’s February 2026 follow-up cautions that selection effects make its newer measurements difficult to interpret. Neither result tells us how every developer performs with current tools. Original trial and follow-up limitations.

My inference is narrower than either enthusiasm or dismissal: test the actual workflow, with its actual users, against a baseline. Time apparently saved in a demonstration can return as review, correction, coordination, and support. Time genuinely saved is still not cash saved unless the business can put that capacity to use.

What are customers actually buying? #

An AI-assisted service sells a result delivered with AI as one of its inputs. An AI implementation service changes the customer’s workflow so that the result can be produced reliably. In both cases, the offer needs to make sense without requiring the buyer to share your enthusiasm for the technology.

These are offer designs, not claims that I have achieved these outcomes for customers. The useful sequence is expensive problem → valuable outcome → AI assistance. Starting with a model, adding an interface, and then looking for a buyer reverses the difficult part.

The buyer may still care about the model when confidentiality, licensing, cost, or procurement requires it. Technical details belong in the delivery decision. They cannot substitute for an economic reason to purchase.

Which AI business models are worth considering? #

For a solo operator who needs early revenue, a narrow service is a useful default because it can be sold before a reusable product is finished. Software becomes more attractive when demand, repeated use, and a route to customers already exist. Content becomes more attractive when you can earn attention consistently.

The following comparisons are my qualitative judgments, assuming one competent operator starting with limited capital and no large audience. They are not measured market averages, earnings forecasts, or guaranteed timelines. Low cash cost excludes the value of your labor; a short route to a first sale still requires a buyer.

An agent is a delivery mechanism, not an independent source of demand. An agent business still needs a buyer, a unit of work, a price, a reliability standard, and someone responsible when the system exceeds its authority.

• Fastest route to a first paid test: a service using skills you can already verify.
• Lowest starting capital: a narrow service or training offer grounded in real expertise.
• Nontechnical operator: domain work with reviewable outputs; integration work may require a technical partner.
• Technical operator without distribution: work with customers before committing to a standalone application.
• Recurring revenue: a recurring operational need, served through a productized service or software.
• Long-term scale: software can reduce delivery labor, once acquisition and retention work.
• Defensibility: accumulated trust, permitted workflow knowledge, useful integrations, and proven quality. None follows automatically from choosing a business-model label.

Why start with a service? #

A service puts you near the buyer while the problem is still ambiguous. Customer contact reveals the work behind the request. Repeated delivery reveals which parts are stable. Those repeated parts are candidates for automation, and only some deserve to become standalone software.

This is a synthesis of familiar customer-discovery and service-productization principles, not a claim to have invented them. Its usefulness is in the order of commitments: expensive problem → valuable outcome → AI assistance → paid service → repeatable process → automation → possible productization → scale.

The tradeoff is real. Services require conversations, proposals, delivery, support, and sometimes uncomfortable scope negotiations. A founder can learn from service work and still discover that every customer needs something different. In that case, forcing the work into SaaS may damage a perfectly useful service business.

Automate the part you understand. Sell the result you can verify. Productize the pattern that survives contact with another customer.

What would this look like for a local business? #

Imagine an HVAC company. A prospective customer calls while the office is busy. Nobody answers. The caller contacts another provider. A useful offer might help the company respond to qualified inquiries it would otherwise lose. This is a hypothetical example, not a customer case study.

A phone platform, CRM, scheduler, and workflow tool may be enough. A model is useful only where interpreting language improves the process. Deterministic rules can handle a known service area or opening hours. More autonomous steps create more places to fail.

A missed call is not blanket permission for an automated marketing sequence. Twilio’s messaging policy distinguishes informational from promotional consent, requires consent records, and requires honoring opt-outs. The implementation needs the applicable permission before sending. Twilio Messaging Policy.

An analogous med-spa workflow adds health-information and clinical boundaries. It should not diagnose, advise on treatment, or collect sensitive details merely to make a lead record look complete. That added burden is one reason a simpler local-service workflow is a better first demonstration.

A booking is not a completed job. Revenue recorded after a message is not automatically revenue caused by that message. Compare a pilot with a credible baseline or, where feasible, a comparable holdout. Account for cancellations, seasonal demand, marketing changes, and callbacks staff would have made anyway.

For illustration only: suppose six completed jobs are credibly incremental, each brings $400 in realized revenue, and each contributes $160 after the variable cost of the job. That is $2,400 in incremental revenue but only $960 in contribution before the new workflow. A $600 service fee and $80 of other incremental costs leave $280 before setup and any remaining overhead or taxes. These are invented assumptions to explain the arithmetic, not expected results.

If only three of those jobs were truly incremental, the same assumptions produce a $200 loss before setup. Attribution can reverse the decision. The economic product is a reliably improved customer outcome with a measured cost, not a collection of connected tools.

Is an AI automation agency a real business? #

Yes, when it delivers and maintains a useful workflow. Existing software can make the technical assembly accessible. The business still consists of finding customers, integrating systems, managing change, proving value, and supporting what has been installed.

A demonstration usually starts with clean data, available permissions, a cooperative user, and a happy path. A customer system adds duplicates, missing fields, revoked credentials, unavailable APIs, staff turnover, exceptions, and people who do not work the way the diagram assumes.

• Commercial work: finding buyers, narrowing scope, attributing results, pricing support, and managing churn.
• Delivery work: permissions, data quality, integration, exception handling, evaluation, and staff adoption.
• Operating work: monitoring, API changes, security, privacy, incident response, and a usable human fallback.

NIST’s AI Risk Management Framework offers a voluntary reference for identifying and managing AI risks. It does not certify a workflow as safe. For a small implementation, the practical task is to decide what the system may do, what must be checked, and who handles failure. NIST AI RMF.

The opportunity is real, but implementation and distribution are the business.

The building trap: sophisticated systems, untested demand #

The building trap is the substitution of technical progress for commercial evidence. AI makes it easier to construct elaborate dashboards, agents, databases, orchestration layers, and brands before testing whether the outcome is worth buying.

The work is tangible. It improves. It provides a satisfying stream of solved problems. Customer uncertainty is less accommodating. A buyer can ignore an elegant system, reject its price, or reveal that the expensive part of the problem is somewhere else.

I explored the underlying shift in Automation Changes the Value of Execution: when production becomes easier, judgment matters more. For a business, the implication is concrete. A finished artifact is weak evidence of demand.

There is another pressure. In McKinsey’s 2026 survey, 32% of respondents said their organizations had declined at least one software purchase because agentic coding tools made an internal build possible. This does not prove the replacement was cheaper or successful. It does suggest that a generic interface may face competition from the buyer’s own tools. Survey evidence.

The answer is to build in response to evidence. Before another feature, name the uncertainty it will resolve. Will a buyer pay? Can the input be obtained lawfully? Can the output be checked? Does support cost less than the value being created? A prototype that answers one of these questions can be valuable even when it is discarded.

A system can be technically sophisticated and commercially untested at the same time.

The AI Business Durability Test #

The AI Business Durability Test is my synthesis for evaluating an AI-enabled offer before increasing investment. It combines ordinary business questions with the delivery risks of AI. It is a working framework, not a validated scoring model or a claim that these individual concepts are new.

Use the test as a sequence of gates. If value or buyer access is untested, prioritize customer discovery. If permission, safety, or reliable delivery is contradicted, stop the affected workflow and resolve that failure. A strong distribution channel cannot compensate for unauthorized actions.

After a paid pilot, examine repeatability, full delivery cost, and continued demand. Consider software only when multiple customers need substantially the same process. A recurring invoice is evidence of billing, not by itself evidence of retention or a durable advantage.

For the hypothetical HVAC offer, an estimate of missed calls supports a question about value; it does not establish profit. The next evidence is whether the owner will sponsor a bounded test, whether permission exists for each communication, and whether incremental contribution remains positive after all added costs.

How much money does an AI business actually keep? #

You cannot estimate owner income from revenue alone. Delivery labor, software, acquisition, support, and overhead consume it. AI can lower some costs while increasing others, especially when a system requires frequent review or expensive retries.

Revenue

Sales earned during a period, before expenses; not necessarily cash collected during that period.

Gross margin

Revenue minus cost of revenue, divided by revenue. Direct delivery labor belongs in the cost analysis; it is not limited to API bills.

Contribution

Revenue less the variable costs associated with the activity being evaluated. Define the included costs consistently; this differs from a full accounting profit measure.

Operating profit

Gross profit after operating expenses such as sales, administration, and ongoing product development, before interest and taxes.

Recurring revenue / ARR

Revenue expected to repeat; annual recurring revenue is an annualized recurring-revenue run rate under a stated definition, not guaranteed future sales or profit.

Owner income

What the owner actually receives as compensation or distributions, subject to costs, taxes, reinvestment, and the business structure.

Company valuation

An estimate or negotiated price for the business, influenced by growth, risk, margins, retention, and dependence on its owner.

For a solo operator, price your own delivery hours even when the accounting treatment differs from an employee’s wages. Otherwise a service can look wonderfully profitable while buying its owner a poorly paid job.

An AI service also does not acquire software economics merely by charging a subscription. Before borrowing a SaaS valuation story, ask whether revenue survives the founder’s absence, whether each additional customer requires substantial labor, and whether customers renew because the product is useful. A valuation multiple cannot repair those operating facts.

Which AI money-making ideas would I avoid? #

I would be cautious about offers whose only advantage is access to a widely available model: generic prompt packs, undifferentiated ebooks, interchangeable chatbot agencies, commodity software wrappers, and automated content or print-on-demand catalogs with no distinctive audience or editorial judgment.

The mechanism is ordinary competition: low barriers invite supply; similar offers weaken differentiation; prices face pressure while attracting customers can remain expensive. Popularity alone does not disqualify a model. A narrow, useful template with trusted distribution can outperform an elaborate application with no buyers.

Content businesses also need to understand rights. The U.S. Copyright Office’s 2025 report distinguishes human-authored expression from material generated entirely by AI; using AI as an assistive tool does not by itself prevent copyright protection. Do not base a business on assuming every generated output is exclusively ownable. Copyright and Artificial Intelligence, Part 2.

Distribution is not a final promotional step. It is part of the business design. A useful question is: how will the right person encounter this, understand it, and trust it enough to act? The Internet Is Becoming an Answer Engine examines how that discovery process is changing.

If I were starting today: a seven-day evidence sprint #

The objective of the first week would be evidence that someone has an expensive problem and may pay for a solution. Payment is strong evidence; replies, conversations, and pilot interest are weaker but useful signals. Seven days is an experiment window, not a promise of revenue.

A finished logo or dashboard does not count as customer validation. Neither does a polite compliment. Ask what would have to be true for the buyer to fund a pilot, and distinguish an explicit commitment from general interest.

If the week produces no useful response, investigate the targeting, channel, problem, and offer separately. Silence does not identify which one failed. The next iteration should test a smaller uncertainty, not automatically add more automation.

Where should you start? #

• Need revenue soon and can already deliver useful work? Offer a bounded service and seek a paid test.
• Have domain expertise but limited technical skill? Use AI for outputs you can review; bring in expertise for production integrations.
• Have technical skill but no route to buyers? Work directly with customers before committing to SaaS.
• Already have a trusted audience or customer base? Test a digital product or narrow software offer with that distribution.
• Deliver the same manual work repeatedly? Measure whether automating it improves quality and total cost.
• See the same automation needed by several paying customers? Test productization, including onboarding and support.
• Cannot find anyone willing to pay for the outcome? Revisit demand. Software may improve price or convenience, but it cannot be assumed to create willingness to pay.

There are exceptions. Some products need a working interface before a customer can assess them. Some technical inventions create possibilities buyers could not have requested. In those cases, build enough to test the new behavior and set a limit on the investment. Service first is a default for reducing uncertainty, not a law against invention.

What remains scarce #

Making money with AI is still a problem of creating and capturing value. Easier access to software and intelligence expands what an individual can attempt. It also expands what competitors can attempt, and what customers can do themselves.

The durable work sits around the model: choosing a valuable problem, understanding the workflow, earning trust, reaching a buyer, delivering reliably, and accepting responsibility for the result. These are not reasons to be pessimistic. They are a more useful map of where the effort belongs.

Build, but let evidence determine what deserves another week. Automate, but count the exceptions. Productize, but test whether the pattern holds outside the first customer.

When the tools become abundant, the scarce asset is a well-understood problem someone trusts you to solve.