How to compete with AI-generated SaaS clones

Imagine opening your email and finding a link to a cheaper version of your app. The screens look familiar, the main workflow works, and according to its creator an AI agent did most of the work over a weekend.

You spent months getting your product to that point, and they’re charging less.

More software founders will have to get comfortable with this. Telling the next customer how much effort you put in won’t help them choose between the two products. What helps is being specific about what they get from you, and honest about which parts someone else can reproduce.

My apps already come with the source

I’m in an odd position here. My apps cost $20 each including tax, paid once, and every purchase includes the full source code in a private GitHub repository. Coding agents write most of the code in them now.

So anyone who buys one can clone it, because the source is right there. In September 2026 several of them were even public MIT repositories, with issues and pull requests turned off and “fork it” as the answer if you needed something different.

This changes the question I ask about pricing. I can’t charge for the difficulty of writing the code, because I hand the code over. What I’m selling is a tool I built for my own work, already finished, with documentation and free tutorials.

That’s also why every app is a one-time purchase. I wrote about keeping my business small and avoiding recurring obligations years ago, and an app the buyer runs on their own machine doesn’t need me to keep a server up.

A clone is a useful warning

It’s tempting to dismiss the copy right away. You know about the ugly problems underneath the interface, and you know the first version and the finished product are different things. The clone can still tell you something uncomfortable.

Maybe the customer wants a smaller product than the one you built. Your competitor may have copied only a few features because those are the ones their audience uses.

Years of additions can look like progress from inside the company and like a crowded interface and a higher bill from outside. I wrote about the buyer’s side of that decision in Build vs buy software.

I’d take a cheap clone seriously enough to ask what it leaves out. Some omissions make it unsuitable for serious use, others might explain why people prefer it. Small companies especially can end up adopting the roadmap of a much bigger business, maintaining features for hypothetical customers while the original ones want the simple thing they signed up for.

Usefulness isn’t the same as what you can charge

A tool might save someone an hour every day, and its creator still can’t charge much for it if the buyer can find alternatives that save the same hour. I wrote about this in Software was never worth the hours it took.

Cheap implementation makes the two easier to confuse. You can build something valuable and still struggle to find paying customers, maybe because it’s a small improvement over what they already have, or because switching takes longer than the benefit is worth.

If your whole argument is that building it used to be hard, the argument needs work, because the customer doesn’t care what it cost you to make.

Reliability has to show up in ordinary work

Founders often answer clones by pointing at reliability. That’s fair when you can demonstrate it, and an empty word when it means “we’ve been around longer”.

Take a hypothetical booking app for a small training company. Creating an event and accepting a booking makes a convincing demo. Now move the event after people have paid, change its capacity, or refund one seat from a group purchase.

The customer finds out how good the product is while handling these exceptions. If the app loses track of a payment, the owner has to reconstruct what happened while a customer waits.

Payment integrations are full of this work. Stripe documents duplicate webhook events and delivery retries, and a working integration has to handle them even if the demo receives every event exactly once.

“We handle edge cases” is weak marketing, though. Show the buyer how a duplicate notification doesn’t create two bookings, or how a failed import can be resumed without making a mess, and let them try it with their own awkward case.

Knowing the work is harder to copy

The screens of a product are public. Much of the thinking behind its behavior isn’t.

A scheduling product for music teachers might understand recurring lessons, school holidays, and how parents handle missed sessions. A generic calendar can store the same dates, but the specialist product saves the teacher the admin work around them, provided real teachers want that.

The advantage comes from decisions that fit the job. What happens when a student joins halfway through a term? Who gets the reminder? Can a teacher change one lesson without changing the whole series?

A competitor can learn these details too, so I wouldn’t call customer knowledge permanent protection. But learning them takes contact with customers and a willingness to change your assumptions, and generating another settings page doesn’t replace that.

For a small software business, depth is often more practical than breadth. You can be very useful to one group without promising to serve every organization that has a calendar.

Getting customers is its own work

A product can be easy to reproduce and hard to distribute.

Someone who trusts your explanations may try your tool first. A consultant may recommend it because it fits work they do for clients, and existing users may invite colleagues. These relationships take time to build.

This is the part of my business a clone can’t download. I sell courses and apps to people who already read the blog and the newsletter, and the newsletter goes out to about 150,000 addresses per issue. Years ago, when I announced a Vue course 70 days before launch and promised the free material I’d write along the way, signups went from 2 or 3 a day to 25 a day.

An audience still isn’t a guarantee. It gets you considered, and if the product wastes people’s time, the disappointment spreads faster. A large following also doesn’t help if your app is for bookkeepers and your followers came for programming memes.

I’d rather understand one repeatable path to suitable customers than celebrate a launch that attracted the wrong people. Ask new customers how they found you, what they were doing before, and why they switched.

Support is valuable when it removes work

It’s easy to put “excellent support” on a pricing page. The useful question is what that support does. Does it help someone move their data, explain an unfamiliar workflow, or answer when the software does something the customer didn’t expect?

Support can make adoption cheaper, since a customer who would abandon a complicated migration alone might finish it with help. But if every small subscription needs hours of personal attention, you’ve created a job that leaves no time to improve the product. Check whether the price covers the work you promise.

Some support questions belong in the interface. If everyone asks where their export went, answering politely forever isn’t the fix, making the export easier to find is. Other questions show a real difference in what customers need, which might justify a higher-service offer or show that this customer needs a different product.

I’d be careful about promising unlimited personal attention to defend a low-priced app against a clone. With my apps, the source comes with the purchase, so a buyer who needs something different can change it.

Making it hard to leave has a cost

A company can hold on to revenue by making cancellation difficult or hiding export behind a support request. That annoys existing users and gives prospective ones a reason to stay away.

Someone choosing a young company reasonably asks what happens if it closes. Can they get their records out? Are the exports useful, with attachments and relationships preserved? Answer that honestly.

Switching software already has a real cost. A team has learned the workflow, connected other systems, and built up years of records, so you don’t need to make it worse on purpose. I’d rather earn another month by solving the problem well.

The price still has to make sense

If competitors offer a suitable product for much less, a buyer is right to ask what the difference buys them, and sometimes the cheaper product is enough. You can narrow your offer, cut your costs, or focus on customers who need the extra service. You can also decide the market no longer supports the business you wanted.

I’d avoid adding random features to justify an old price. Each one creates work, and a longer comparison table rarely changes the buyer’s decision.

A single recurring plan isn’t the only option either. Some customers want hosted convenience, others want source code they can run themselves, and a paid setup service might fit a complex migration better than a subscription that quietly includes unlimited consulting. The Cap business model is a good case to look at, since it combines available source code with paid offers.

Compare the work your customers do

I’d start with a few recent customer decisions. Why did the last person sign up? What did the last person who cancelled replace the product with? And when someone looked seriously and picked a competitor, what made that sensible for them?

Then I’d try the competitor on the same job, including the awkward data and the boring follow-up work. Homepages tell you how products describe themselves, doing the work tells you where they differ.

Back to the booking app. Say the cheaper competitor handles individual classes well, and yours also handles term bookings and credits for missed lessons.

A teacher selling occasional workshops may have no use for term administration, and lowering your price for them doesn’t make those features valuable. You could offer a smaller plan if it still covers support, or help that teacher export their records and focus on schools running full terms.

For a school, I’d walk through one term with a copy of realistic records. Add a student halfway through, move a lesson, issue a credit, and note every time someone has to leave the app and fix a spreadsheet. Give the competitor the same chance.

When both finish correctly but yours needs an hour of explanation, you have an onboarding problem. Repeated manual adjustments in the cheaper one are a concrete difference to show schools that hit them. And if both work equally well, claiming more depth won’t help.

Then I’d pick one response and give it a limit, like improving term setup for the next few schools evaluating the app, and recording why the ones who leave do so. Adding a cheaper plan at the same time would make those answers harder to read.

Finally, I’d look at my own obligations. A business that survives only because I answer every request immediately can pay the bills and still be unpleasant to run. I want the customer’s reason for staying to be something I can keep delivering on a normal working day.

Want me to talk about your product? You can sponsor this site.