The Weekend Clone: Why Buyers Still Pay for Software

At DevDay this fall OpenAI priced GPT-6.1 Sol at two dollars per million input tokens and ten per million out, one fifth of what the frontier model cost a release earlier, and roughly matched the expensive model on agentic coding, computer use, and ordinary professional work. Cached input landed at ten cents a million. I read the pricing page and did the math a founder does by reflex now: the model that can draft a rough version of most software products just got cheap enough that my own customers can afford to run it against their own problem over a weekend.

That is the quiet thing the price cut did. It did not just lower my costs. It lowered the cost for the person I am trying to sell to. For most of my career the question behind every product was “can we build this before someone else does.” The question underneath that one has changed. It is now “why would anyone pay me for something they could build themselves by Sunday night.” If you are building a company in 2026 and you have not sat with that question until it made you uncomfortable, you are pricing your own defensibility off a cost structure that no longer exists.

I want to give that question a name, because naming it is the first step to answering it. I call it the weekend clone, and most of what I believe about building a durable company now runs through it.

Your competitor is no longer the other startup. It is your customer.

For twenty years the build-versus-buy decision tilted toward buy for almost everything that was not your core product. Writing software was slow and expensive, engineers were scarce, and maintaining what you wrote was a tax that never stopped. So companies bought. The entire SaaS industry is a monument to the fact that building your own tools was a bad idea for most teams most of the time.

Cheap, capable models bent that curve. A 2026 Retool survey of software teams found that 35 percent had already replaced at least one SaaS tool with something they built in-house, 78 percent expected to build more of their own tools over the year, and 32 percent had stopped buying certain products outright because an AI coding tool let them build the same thing themselves. Blinkist said publicly that it cut roughly sixty thousand dollars a year of SaaS spend by having AI build lightweight internal tools in a matter of days. Earlier in the year a cluster of public SaaS names, Box and Smartsheet and Asana and Monday among them, traded down while this was happening, and some analysts started calling it the SaaSpocalypse.

I do not think the name holds up, and I will get to why. But the direction is real and it matters for anyone starting a company. The marginal buyer of your product now has a credible alternative that did not exist two years ago, and that alternative is themselves. The new entrant in your category is not a funded startup you can out-raise or out-hire. It is a mid-level operator inside your prospect’s company with a Sunday afternoon and a model that costs ten cents a million cached tokens. You cannot out-compete that person on the thing they are good at, which is building the obvious 80 percent of what your demo shows. You have to compete on the part they cannot see yet.

This is a different axis than the one most founders worry about. I have written before about what happens when a frontier lab absorbs your feature and about how fast the model itself eats the thin layer on top of it. Those are real, and they are about the supplier above you in the stack. The weekend clone is the opposite direction. It is the threat coming from the buyer below you, the person you were trying to sell to, newly armed. Most strategy decks have a slide for the first threat and nothing for the second.

What a weekend clone actually gives you, and what it never does

Here is the move I watch founders make when the fear lands. They decide the answer is to make the product more impressive. More features, a slicker demo, a deeper model, a longer list of things it can do. It feels like the right response because it is the thing you know how to do. It is also exactly wrong, and the reason is simple once you see it: the impressive part is the part that clones. You are pouring effort into the one layer a weekend build can reach.

A weekend clone is good at a specific, bounded set of things. It gives the buyer a working demo. It handles the happy path, the clean input, the case everyone thinks of first. It covers maybe 80 percent of the surface area in a form that looks, for about fifteen minutes, indistinguishable from yours. What it does not give the buyer is everything that only shows up after the demo ends.

Look at the two columns and notice which one you have been investing in. Almost every founder I know, me included at times, spends the bulk of their energy on the left side, because the left side is what you present, what you tweet, what wins the room. The right side is unglamorous and slow and invisible in a demo. It is also the entire reason a buyer keeps paying you after the novelty wears off. The weekend clone is a copy of your left column. It is not a copy of your right column, because your right column cannot be copied in a weekend. It can only be earned over quarters.

So the strategic instruction is almost rude in its simplicity. Stop competing on the thing that clones. Build the company around the thing that does not. Everything below is what that means in practice.

A demo only shows the part that copies

A demo is a performance of the happy path. That is its job. You pick the input, you control the environment, you show the system doing the clean version of the task. This is fine and necessary, but it has a side effect founders rarely account for: a demo is, almost by definition, a specification for a weekend clone. You are handing the viewer a precise picture of the 20 percent that is easy to reproduce and hiding the 80 percent that is hard.

I learned to distrust my own demos because the better they got, the more they taught a watching buyer exactly how to skip me. A tight demo of a document-review tool says: here is the input, here is the output, here is the prompt-shaped gap between them. A capable operator watching that demo now has a spec. They go home, wire the same model to the same kind of input, and by Monday they have something that does the demo. What they do not have, and what the demo carefully never showed, is the behavior when the document is 300 pages, half-scanned, internally contradictory, and three regulations changed since it was written.

The tell is this. If your product can be fully understood from a two-minute demo, it can be mostly rebuilt from a two-minute demo. Fully legible is fully copyable. The products that survive are the ones where the demo is honestly just the doorway, where the person watching comes away thinking “I see what it does, and I have no idea how they make it reliable.” That gap between what it does and how they make it hold is the thing you are actually selling. Spend your demo earning respect for the gap, not erasing it.

This is adjacent to something I have argued about thin products built on top of a model, but it is not the same point. A thin wrapper dies because the model vendor absorbs it from above. A fully-legible product dies because the buyer rebuilds it from below. You can be a thick, sophisticated product and still make the fatal mistake of presenting yourself as fully legible, which hands the rebuild instructions to the one person you most needed to keep as a customer.

You are not selling the feature. You are selling the maintenance.

Here is the reframe that took me two companies to internalize. When a customer pays for software, they are almost never paying for the feature. They are paying to not own the feature. They are paying to make someone else responsible for the part that never ends.

The build-versus-buy literature has known this for a long time, and the cheap-model era made it sharper, not weaker. The standard finding is that in-house software gets more expensive over time while bought software gets cheaper per unit of value, because the vendor amortizes maintenance across every customer and you amortize it across exactly one: you. The cleaner way people put it: if a bought tool covers 85 to 90 percent of your workflow, building the last 10 to 15 percent yourself means paying the full cost of ownership for a sliver of extra control, and control is expensive and rarely turns into advantage unless the software is literally your product.

Read that back from the seller’s seat. The customer’s weekend clone handles 80 percent. Getting from 80 to 99 is not another weekend. It is the rest of the year, forever, by someone whose actual job is something else. The feature was a Saturday. The maintenance is a mortgage. What you sell, what the subscription actually buys, is that you carry the mortgage so they do not have to.

Once you see the price this way, your roadmap reorders itself. The question stops being “what feature next” and becomes “what piece of the mortgage can I take off my customer’s plate that they would otherwise have to carry.” That is a product question and a pricing question at the same time, and it points away from the demo and toward the parts of the work that are boring, continuous, and load-bearing. I wrote a whole piece on why price has to decouple from the cost of the tokens, and this is the other half of it: you price the ownership you are absorbing, not the inference you are running.

The self-build graveyard is bigger than the self-build headline

The SaaSpocalypse story has a loud first act and a quiet second act, and the second act is the one that should shape your strategy. The loud act is companies replacing tools with weekend builds. The quiet act is a meaningful share of those builds getting abandoned, half-finished, or silently returning to a bought product six months later when the person who built it changed teams and nobody else could touch the code.

I have watched this inside my own companies and inside companies I advise. A team gets excited, vibe-codes an internal tool over a sprint, saves the subscription, feels clever. Then the model they built on gets deprecated, or the one person who understood the prompt chain leaves, or the tool hits an edge case that corrupts data and there is no vendor to call and no SLA and no roadmap, just a Slack thread and a shrug. The build was cheap. The owning was not. The thing nobody budgeted for was that a weekend clone comes with a weekend’s worth of accountability, which is to say, none.

This does not mean the self-build wave is fake. It means it sorts work into two piles that founders need to tell apart. There is work a company is happy to own forever, usually because it is simple, stable, and genuinely specific to them, and for that work the weekend clone wins and should win. And there is work a company does not actually want to own, because it is messy, it changes, it carries risk, and owning it pulls their best people off their real job. For that second pile, the weekend clone is a trap the buyer sets for themselves, and your entire business is being the escape from that trap. Your job is to know, cold, which pile your product is in. If you are in the first pile, you do not have a company, you have a feature. If you are in the second, you have a real one, and you should make the ownership burden you remove impossible to ignore.

Two ways founders get the clone wrong

When the threat lands, I watch founders reach for one of two responses, and both make the position worse rather than better. The first is to polish the demo. More features, a slicker reel, a deeper capability shown off in the room. It feels like fighting back and it is the opposite, because a better demo is a better spec, and a better spec is a faster clone. You are using your scarcest effort to teach the person you most want to keep exactly how to replace you.

The second response is to bolt on lock-in. Make the data hard to export, make the contract sticky, hide the obvious, build a cage around a thing the customer could otherwise walk away from. This works for about one renewal and then it curdles. A buyer who stays because leaving is painful is a buyer who leaves the moment the pain drops, and in a world where the alternative is a weekend build, the pain is dropping fast. Lock-in that the customer resents is not a moat. It is a countdown with interest.

The response that holds is the third one, and it is quieter than both. You move the center of gravity of the product from the capability, which clones, to the ownership you take off the buyer’s plate, which does not. The difference is not cosmetic. It changes what you build, what you show, and what you charge for, and it is the only one of the three that gets stronger the longer the customer stays.

When the clone appears, you can	What it actually does	What happens next
Polish the demo	sharpens the spec they build from	they clone you faster
Bolt on lock-in	traps a buyer who already wants out	they resent you and leave when they can
Move value to ownership	removes a burden they do not want	they stay because leaving is their problem again

Where the weekend clone cannot follow you

So where is the second pile. Where does durable value actually sit once the feature itself is free to copy. I think about it as a simple two-by-two, and it is the most useful picture I have for deciding whether something is a company or a weekend.

The dangerous quadrant is the bottom right, the weekend project: easy to copy and easy to own. If your product lives there, the weekend clone wins and you have no answer. The star is the top right, and it is counterintuitive, so sit with it. The strongest place to build is often something anyone could clone but nobody wants to run. The core being easy to copy is not the disqualifier people assume. The disqualifier is the buyer being happy to own it. Move the thing up the vertical axis, make it something they never want to run themselves, and the cloneability of the core stops mattering.

Payments is the oldest example. Charging a card is, at the level of the happy path, not hard, and plenty of engineers could build a version over a weekend. Almost no company builds their own payments, because the part that is not the happy path, the compliance, the fraud, the edge cases, the being-on-the-hook when money moves wrong, is a lifetime of ownership they refuse to carry. The feature clones. The ownership does not. That is a company.

The vertical AI wave is the current version of the same lesson, and the numbers are blunt. A generic AI assistant in a professional field runs churn around 15 percent, because it is a feature and features get cloned and dropped. A vertical system built into a specific painful workflow, with proprietary data and the trust that comes from being embedded in the process, can run churn under 3 percent and command several times the price. Harvey, in legal, reached roughly a hundred and ninety million in annual revenue and an eleven-billion valuation in three years, and the reported source of the moat is not the model, which is interchangeable, but the twenty-five thousand custom agents built alongside customers and the workflow data from well over a thousand firms. The model is the weekend. The harness, the data, the embedding, the being-trusted-with-the-real-work, that is the right column, and no weekend reaches it.

The same product, two companies	The feature-led version	The ownership-led version
What the buyer sees	a capability, shown in a demo	a burden lifted off their team
What they are paying for	the output	not having to own the output
Churn behavior	high, around 15 percent	low, under 3 percent
Price power	compressed toward token cost	several times higher
Weekend clone risk	high, the demo is the spec	low, the value is off-screen

Four things a weekend cannot buy

When I pressure-test whether something sits in that top-right quadrant, I look for four accumulations, and the useful property they share is that none of them can be acquired quickly, by anyone, at any price. Time is the only currency that buys them, which is exactly why a weekend cannot.

The first is a data loop that only runs if the product is used. Not a pile of data you bought or scraped, which anyone else can also buy or scrape, but data that is created as a byproduct of your customers doing the work inside your system, and that makes the next result better. I have written about the point where a buyer stops testing a product and starts depending on it, and the data loop is a big part of why that point, once crossed, is so hard to reverse. A clone starts the loop at zero. You are years ahead and the gap widens every day they use you.

The second is accountability. Somebody has to be answerable when the output is wrong in a way that costs money or trust or a license. A weekend clone has no one on the hook. You can be the one on the hook, with a real SLA, a real support path, a real promise, and in any domain where being wrong is expensive, that promise is most of what the buyer is buying. It is the opposite of a feature. It is a liability you are willing to hold so they do not have to.

The third is the integration into the systems they already live in, under the rules they already follow. The model is generic. The wiring that pulls the right context, calls the trusted internal tools in the right order, writes the result back into the system of record, and does all of it inside the customer’s governance, is specific and slow to build and painful to maintain. That wiring is the harness, and the harness is where vertical companies actually win. It is also the part a demo never shows and a weekend never reaches.

The fourth is trust that transfers, the kind that comes from a track record other buyers can check. A reference a prospect can call. A name in their industry that already bet on you and did not regret it. This compounds and it cannot be cloned, because it is not in your code. It is in other people’s experience of you. A weekend build starts with zero trust and has to earn every bit of it from scratch, in a market that, after years of pilots that went nowhere, has gotten very hard to convince.

The part that compounds while every clone starts over

There is a timing asymmetry in the right column that founders underrate, and it is the strongest thing you have going for you. The feature is a stock. It either exists or it does not, and a weekend build can bring it into existence in a weekend. The right column is a flow. The data loop, the operational track record, the trust other buyers can check, the integrations that bedded in over quarters, all of them accumulate only by running, and they get larger every day you run and smaller for no one. A clone that appears today does not start the race behind you. It starts the race at zero on the only axes that compound, while you are a year or two in.

This is why the gap between a durable company and its weekend clone tends to widen rather than close, even as the raw capability converges. The capability converges because the model is shared and cheap, which is the whole premise of why so much shipped capability still sits unused inside most organizations. The ownership does not converge, because ownership is earned in calendar time and calendar time cannot be bought cheap or fast. A clone can match your feature on Sunday. It cannot match two years of your customers depending on you, and every Sunday that passes, the thing it would have to match got bigger.

So the practical move is to make sure you are actually accumulating, not just operating. Running a product and compounding an asset are not the same thing. If your usage does not make your next result better, if your track record is not something a prospect can verify, if your integrations reset every time a customer churns, then you are operating without accumulating, and a clone really can catch you, because there is nothing behind the feature for it to fall behind on. The whole game is to put something behind the feature that only time can build.

Why buyers still pay, even when they can build

Put the pieces together and the SaaSpocalypse resolves into something calmer and more useful than the headline. Buyers are not abandoning bought software. They are getting far more precise about what is worth owning and what is worth paying someone else to own. The low-ownership-pain, easy-to-clone quadrant is emptying out, and it should, because that was always just features wearing the costume of companies. The rest is getting more valuable, not less, because the alternative, owning it yourself, now has a visible price tag and a visible failure rate that everyone has watched a peer hit.

The reasons a buyer still pays, once they could build, are not mysterious. Speed, because a mature product deploys in weeks and their build is a project that competes with their real work. Predictability, because your roadmap and your maintenance are a line item, and their build is an open-ended liability on a person who might quit. And the plain refusal to own something that is not their business, because every hour their best people spend running a tool they cloned is an hour not spent on the thing only they can do. None of those three is a feature. All three are the right column.

This is why I think “nobody will pay for software anymore” is exactly backwards. People will pay, maybe pay more, for software that removes a burden they have now personally priced and do not want. What they will not pay for is a capability they can reproduce and are happy to own. The market did not stop valuing software. It started valuing ownership-removal and stopped valuing features-for-their-own-sake, and those were always two different things we lazily charged for under one invoice.

Sometimes the right move is to let them clone it

The honest counterpoint is that not everything should resist the weekend clone, and a founder who fights every clone wastes the fight. There are products, and whole features inside good products, that genuinely belong in the bottom-right quadrant, and the right strategy there is to let the customer build it and go compete somewhere the ownership is heavy.

If what you make is simple, stable, and specific enough to a single customer that they are honestly happy to own it, you are not defending a moat, you are taxing a convenience, and that tax has a short life. The weekend clone will come for you and it should. Trying to add defensibility to something that genuinely wants to be a weekend project, by bolting on lock-in or hiding the obvious, does not create a company. It creates a worse version of a thing the customer can now make for free, and it earns the resentment that comes with being in the way.

The useful discipline is to run the two-by-two honestly and believe the answer. A lot of what founders are building in 2026 lives in the bottom right and the kindest thing the cheap-model era does is tell them so early, before they raise on it. Being wrong about which quadrant you are in is more fatal than being in the hard quadrant, because the hard quadrant at least has a company in it. I have argued that in an AI-native company there is a small core of work that cannot be compressed or handed off, and this is the market version of that idea: the core of your product that cannot be cloned is the only part that was ever a business. Everything else was a feature you had been overcharging for because, until now, building it was hard for everyone.

How to find your clone line this month

Here is the exercise I run, and it takes about a week of honest attention rather than a workshop.

Start by building the clone yourself, on paper. Take your own product and write the spec a competent operator would derive from your best demo. Be ruthless and fast about it, the way they would be. The point is to feel, concretely, how much of your product is reachable from what you show. If most of it is reachable, you have found your problem, and no amount of polishing the demo fixes it, because polishing the demo makes the spec better.

Then list everything that is not in that spec. The edge cases you handle that the demo hides. The operational load you carry. The accountability you hold. The data that has accumulated. The integrations that took quarters. This list is your real product, and the uncomfortable test is whether you can even articulate it, because if you cannot name the right column, you have probably not been building it, and you have been competing in the left column against people who will beat you there for free.

Next, put every line of your roadmap into one of the two columns and look at the balance. If your next quarter is mostly left-column work, more features, a better demo, a flashier capability, you are spending your scarcest resource reinforcing the exact layer that clones. Rebalance toward the right column until it hurts a little, because the right column is slower and less fun and does not demo well, which is precisely why it is defensible.

Finally, change what you sell in the room. Stop leading with the capability, which invites the prospect to imagine building it, and start leading with the ownership you remove, which invites them to imagine the burden of not having you. The same product, sold as a feature, teaches the buyer to clone you. Sold as the removal of a burden they have now personally felt, it teaches them to keep you. That shift costs nothing and changes everything, and you can make it on your next call. If you want the wider frame this sits inside, it is the throughline of how I think about building an AI-native company, and it connects to the build-versus-buy decision from the buyer’s own seat, which is the mirror of everything here: when you sell, you are on the other side of the exact calculation your customer is now running against you.

Questions founders ask about the weekend clone

If a capable model is cheap enough for anyone to build with, is any software product defensible anymore?

Yes, but the defensible part moved. The feature is not defensible, because the feature is what clones. What is defensible is everything a demo cannot show and a weekend cannot reach: the data loop that compounds with use, the accountability you hold when being wrong is expensive, the integration into the systems and rules a customer already lives in, and the trust other buyers can verify. Defensibility did not disappear. It relocated from the thing you demo to the thing you operate.

How do I know if my product is just a weekend project?

Run the two-by-two. If your core is easy to copy and your buyer is happy to own and run it, you are a weekend project, and no feature list fixes that. If your core is easy to copy but your buyer never wants to own and run it, you can build a strong company by selling the operation. The disqualifier is not that your feature is simple. The disqualifier is that your customer is content to own it themselves.

My buyers keep saying they will just build this internally. What do I do?

Take the threat seriously and then separate the demo from the ownership. They are usually pricing the build at a weekend and the ownership at zero, because the ownership is invisible until they hit it. Make the invisible part concrete. Walk them through the edge cases, the staying-current, the accountability, the maintenance that lands on a named person who has a real job. Most of the time the internal-build threat is a bluff the buyer has made to themselves, and your job is to show them the second act of that story before they live it.

Should I hide how my product works so it is harder to copy?

No. Obscurity is not a moat and it reads as weakness. If the only thing protecting you is that the buyer cannot see how you do it, you are one good demo or one curious engineer away from being cloned. Durable products can be fully explained and still not reproduced, because the explanation does not hand over the data, the operational track record, the integrations, or the accountability. Build defensibility you can describe out loud without losing it.

Is this just the old build-versus-buy decision with new branding?

It is the same decision seen from the other side, which changes what it means for you. The classic build-versus-buy frame helps a buyer decide whether to own or rent a tool. The weekend clone is what that decision looks like from the seller’s seat now that the build option got drastically cheaper for your buyer. The underlying economics, that ownership is the expensive part and most teams should not carry it, did not change. What changed is that the buyer now has a credible weekend option, so you have to make the ownership you remove impossible to overlook.

Does being in a vertical automatically protect me from the clone?

No. A vertical is only protection if you use it to accumulate the things a weekend cannot buy. A thin product aimed at a narrow industry is still a thin product and still clones in a weekend. What protects a vertical company is the proprietary workflow data, the embedding into the industry’s real process, and the trust earned inside that industry over time. The vertical is the place you go to accumulate those. It is not, by itself, the moat.

How should I price once the feature itself is nearly free to reproduce?

Price the ownership you absorb, not the inference you run. If you anchor your price to the model’s token cost, you are in a race to zero with a buyer who can run the same tokens. Anchor it instead to the value of the burden you remove, the cost of the failure you prevent, the people you free up. A customer deciding whether to pay you is really comparing your price to the fully loaded cost of owning the thing themselves, including the parts they have not thought of yet. Your job is to price against that total, and to make the total visible.

What is the single most important thing to change on Monday?

Change what you lead with when you sell. Stop opening with the capability, which teaches the buyer to picture building it, and open with the ownership you take off their plate, which teaches them to picture life without you. It is a free change, you can make it on your next call, and it moves your entire story from the left column, the part that clones, to the right column, the part that does not.

The real question the cheap model forced

The model got five times cheaper and near enough to the frontier that the distinction stopped mattering for most work. That is not a threat to the founders who were already building the right column. It is a clarifier. It took the question that was always true, why would anyone pay you for what they could do themselves, and made it impossible to avoid, because now they really can do a version of it themselves, this weekend, for ten cents a million tokens.

The ones who answer it will stop confusing a feature with a company, stop pouring their best effort into the layer that clones, and start building, pricing, and selling the ownership that a weekend cannot touch. The ones who do not answer it will keep polishing a demo that is quietly a set of build instructions for the customer they most wanted to keep. Go build your clone on paper this week. Then go build the company around everything it leaves out.

I am a four-time founder building AI-native companies. I write about the founder mindset, AI opportunities, and the mechanics of building with AI at vikasmalpani.com.