Earlier this month, a developer in Atlanta got fed up with Adobe's cancellation fees. So he used Claude to clone the entire Adobe Creative Suite — ...
For further actions, you may consider blocking this person and/or reporting abuse
I think a lot more this topic after my first comment. Result this is lead a whole software industry crysis. - I hope not.
But at the end maybe raise a bunch of well crafted software a much more specialized target smaller group taste. Make a lot smaller company.
More craft, less factory — that’s the hopeful version, and I think it’s the likely one. Cheap building makes the niche viable, so software gets personal again: many small makers serving specific taste, instead of giants serving no one in particular.
The sustainability question is the right one. I have seen a bunch of vibe-coded clones launch and disappear within weeks. The ones that survive are the ones where the builder actually uses the tool themselves and keeps iterating. The Adobe clone story is wild but I would bet most of those seven apps are buggy messes. Curious if you actually tried any of them.
The “builder actually uses it themselves” test is probably the best survival predictor anyone’s offered, because it quietly solves the maintenance problem the whole thread keeps circling — someone scratching their own itch still ships fixes in year three, while someone chasing a viral launch is gone the week the attention fades. Dogfooding is the cheapest sustainability signal there is.
Honest answer: no, I haven’t run them, and I deliberately didn’t hang the piece on whether the clones are good — that’s the trap. You’re almost certainly right that most of the seven are buggy messes; the creator said so himself. But the argument doesn’t rest on them being good. AI collapsed the cost of building, not finishing, so a wave of impressive-but-unusable alphas is exactly what you’d predict. The point isn’t “Photoshop is dead,” it’s “the thing that made Photoshop unassailable just got cheap to challenge.”
That is a great way to frame it. The maintenance problem is where most clones die. Building the first version is the easy part. Fixing bugs, handling edge cases, and keeping it running for years is the hard part. Someone who actually uses the tool has a reason to keep fixing it. Someone who just wanted to go viral does not.
AI actually widens that gap. It makes the first version nearly free, so launches flood in, but it does nothing for the motivation to sustain — more clones, higher abandonment, simultaneously. Build cost fell to zero; maintenance cost didn’t move; motivation is the only thing bridging them. So “does the builder use it themselves?” stops being a nice signal and becomes the whole forecast.
Dogfooding is the right word for it. I have noticed the same thing with my own projects. The ones I actually use get better over time because I feel the pain every day. The ones I build for other people sit and rot. The tool you use every day is the tool you fix. The tool you demo once is the tool you abandon.
And this is not a self promo I just wanna show you an example in which I have vibe coded a calculator to save myself from marketing gimmicks lootlens.antideploy.com/ only such tools you should be fixing or investing you more time on.
Briliant question, and analysis. I think those Adobe and Microsoft clones ( Word for example ) got so many works, even contributors to not wipe out so easy. My personal story on a certain point connected to Flash, then adobe bye it |> R.I.P. Flash. Without a proper vector based animation program ... I so miss. I also works many years as graphic designer, with lot of PS using also. After I change direction to coding, PS cost was too high to keep it up, so I changed to Krita. The real problem is that program cost you totally right the agents is downgrade the monopoly.
I was also put in the table this question ( not so direct )
Singularity News
plus I also solve my personal problem ( maybe affect many of us ) with a fork
TS + |> to hack JS
There’s a lot of real history in this — the Flash story especially lands, because it’s the dark mirror of the clone wave: a tool people loved, bought by a giant, then killed, leaving a gap that still isn’t properly filled years later. That’s the monopoly problem from the other direction — not just high prices, but the power to simply end a thing people depended on, with no recourse. Your path from graphic designer to coder, dropping PS for Krita when the cost stopped making sense, is exactly the pressure the piece is about: people don’t leave because the alternative is better, they leave because the squeeze finally outweighs the switching pain. And you’re right that agents downgrading the monopoly is the real story under the clone hype. I’ll check out your post soon . Thanks for bringing the lived version; the Flash angle alone is worth its own piece.
AI may make building software cheaper, but creating something people can trust, maintain, and rely on is a completely different challenge. The real disruption might not be replacing paid apps overnight, but forcing established companies to compete on value rather than lock-in.
Here’s the bigger question: If AI lets anyone clone almost any app, what should users pay for in the future—the software itself, or the trust, security, support, and continuous improvements behind it?
That closing question is the one the whole piece was circling toward: if the software itself becomes near-free to replicate, then what you’re actually paying for was never the features — it’s the trust, the security, the support inbox someone answers, the promise that it’ll still work and still be maintained in three years. And you’ve named the real disruption precisely: not paid apps vanishing overnight, but giants being forced to compete on value instead of lock-in, because lock-in was the thing that let them stop competing. My honest answer to your question: users will pay for the guarantee, not the artifact — “this will keep working, and someone stands behind it” is the one thing a weekend clone can’t ship, and it’s exactly what becomes scarce when building gets cheap.
Exactly. When building software becomes cheap, trust and long-term reliability become the real differentiators. People aren’t just paying for features; they’re paying for peace of mind, accountability, and the confidence that someone will be there when things break.
yeah!
Honestly, I don't think Big Tech is sweating this at all. Sure, AI makes it easy to spin up an alpha clone in a weekend, but the open-source graveyard is full of projects that started with big hype and died the second maintenance got boring. Giants know that building a rough MVP is easy, while keeping a complex app secure and updated for years takes a real team. They will probably just wait out the hype cycle.
You’re probably right about today — “wait out the hype cycle” is rational, and the graveyard math is on their side. Where I’d push: they’re not sweating this wave, and shouldn’t. The thing to watch isn’t whether these clones survive — it’s whether the cost of each new attempt keeps falling. Giants survived past waves because mounting a credible challenge stayed expensive. If that stops being true, “wait it out” stops working, because there’s always another attempt.
The majority of the vibe coders out there has no idea on what they are truly doing. I loved your blog post but the point I reached on the below statement, which made me confusing and it defeated the purpose all together 🤣
Fair catch. The tension is real: most vibe coders don’t know what they’re doing — and the giants can still lose. Both hold, because the giants don’t need a competent clone to lose; they need “build your own” to stop being impossible. Possibility erodes monopoly pricing even when 99% of the attempts are junk. The threat is the floodgate, not any one flood.
Small data point from the other side of this: building stopped being the hard part for me a while ago, and it didn't make selling any easier.
I had an agent ship a $5-or-pay-what-you-want ebook abroad. 14 people took it free before anyone paid; the first paid copy came after I set a $5 minimum. Before that I'd spent $41 on X ads: 16,569 impressions, 70 clicks, 0 paid orders. Cheap to build, and still zero.
So my guess at "what survives" is less about the code and more about whatever makes a stranger trust you enough to pay: a track record, a specific person's specific problem solved, a support inbox someone answers. A clone can copy Photoshop's features. It can't copy the twenty years of people already knowing it works.
That ad data is brutal and clarifying — thousands of impressions, zero paid orders, and the first sale only came when you removed the free option. The build cost went to zero and moved you nowhere on the thing that actually gated revenue: trust. Features are clonable; twenty years of people knowing it works isn’t. That’s the real moat, earned at human speed no matter how fast the code gets written.
Small correction to my own story: I didn't remove the free option, I set a $5 floor on pay-what-you-want. Same lesson though. The 14 who took it free were real people, they just weren't buyers yet.
The part I keep chewing on is "human speed." I tried to rush it with ads and got impressions, not trust. Slow threads like this one haven't sold anything either, but at least people talk back, which the $41 never got me.
Fair correction — a $5 floor, not removing free, though the lesson holds either way. And “impressions, not trust” is the whole thing in three words: ads buy attention, which is the cheap part; trust was never for sale at $41, because it doesn’t move at ad speed. A thread like this hasn’t sold anything either, but people talk back — and that two-way exchange is the actual raw material trust is built from, slowly, which an impression never is. You didn’t fail to buy trust; you just found out it’s not the kind of thing you can buy.
Yeah, that lines up with what I measured. My replies on X got 0 to 2 impressions each, while threads here actually turned into back-and-forth like this one. Slow, but it's the only part that felt real.
That tracks — a real back-and-forth with a few people beats a thousand impressions that nobody actually read, because conversation is the part that was never for sale.
The cost of building a clone may be collapsing, but the cost of earning user trust hasn't changed nearly as much. A working demo can reproduce the visible features, while the harder work sits in edge cases, data portability, reliable upgrades, security fixes, and years of compatibility. I think this shifts the competitive advantage from who can build the most features to who can sustain a dependable product with the least friction for users. AI makes it easier to challenge established software, but long-term maintenance and a clear path for users to leave or migrate their data may be what separates a credible alternative from another abandoned repository.
you’ve put your finger on the asymmetry the hype skips: AI collapsed the cost of building, but did almost nothing to the cost of sustaining, and those were always two different problems. A demo reproduces the visible 90%; trust is earned in the invisible 10% — the edge cases, the data portability, the security fix shipped at 2am, the upgrade that doesn’t break your decade-old files. That part is still slow, unglamorous human work, and no model shortcuts it.
So you’re right that the competitive axis rotates: from “who ships the most features” (now cheap, now commoditized) to “who sustains a dependable product with the least friction.” That actually raises the value of the boring stuff — maintenance, migration paths, a clean way to leave with your data — because it’s the one moat AI didn’t dissolve. The clone that survives won’t be the one that looked most like Photoshop on day one; it’ll be the one still safe to depend on in year three. Which is a more honest definition of “what survives” than mine, and it points at the same place from the maintenance side.
That “year three” test is a useful way to judge these products. I’d add one more signal: how safely a user can update, roll back, or leave the product without losing data or disrupting their workflow. Those lifecycle paths rarely show up in a launch demo, but they determine whether a clone becomes something people can depend on. AI may keep lowering the cost of creating alternatives; the harder challenge is making change predictable for the people already using them.
The reversibility test — can you update, roll back, or leave without losing your work — is the sharpest “year three” signal yet, precisely because none of it shows up in a launch demo, which is exactly why it separates dependable software from a pretty alpha. Making change predictable for existing users is the real discipline, and it’s the opposite of what vibe-coding optimizes for. AI keeps lowering the cost of the first version; the thing it doesn’t touch is the promise that version two won’t break you.
The part I'd watch isn't a clone's feature list but whether it opens the files people already have. Most people can't switch editors because years of work sit in PSDs with adjustment layers and smart objects, and a clone that imports a flattened version hasn't touched the lock-in at all. It's also the least vibe-codable part: the published spec only covers some of it, and the rest is a long tail of files real users produced in odd ways. If the giants feel pressure anywhere, I'd expect it where a clone round-trips those files faithfully, not where it has the most tools.
File round-tripping is the sharpest moat-test here, because lock-in runs on your trapped files, not features. A clone that imports a flattened PSD gave you a viewer, not an exit. And it’s the least vibe-codable part — the spec covers the happy path, the lock-in lives in the long tail of files real users made in weird ways. An AI clones visible behavior from a screenshot; it can’t clone format quirks it’s never seen in the wild. That narrow, grueling work is the real pressure point.
The point about the moat being the cost of building, not the idea itself, is the one that sticks. Once that cost collapses, a clone can look impressive and still fail the last stretch that makes software usable day after day.
That matches how we see client work. The easy part is getting a first version that resembles a known product. The hard part is writing down the one problem the first release must solve, with checks that prove it, and keeping everything else off the list. Clones usually skip that discipline because the goal is resemblance rather than a clear finish line.
I would be interested in which failures you have seen most often once a clone meets real users. Is it reliability and data, or simply that nobody cares enough to keep using it?
From what I’ve seen it’s mostly the second, and it’s upstream of the first. Reliability-and-data failures are real, but usually fatal only because nobody cared enough to still be around when they surfaced. A tool someone genuinely depends on gets its data bugs fixed because the maintainer feels them daily; a tool built for resemblance gets abandoned before the edge cases even appear. Indifference is the primary cause of death; the technical debt is just what it leaves behind.
"The moat was never the code. It was the cost of building it." — this hits the nail on the head, and the corollary is that the new moat is the cost of operating, securing, and maintaining edge cases at scale.
Spinning up the happy-path UI and CRUD endpoints of a SaaS app takes a weekend now. What an LLM won't vibe-code out of the box is idempotent webhook retries when Stripe times out mid-transaction, cgroup memory tuning when a background worker OOMs at 3 AM, or handling cross-device passkey
signCountdesyncs without locking out paying users.Cloning the surface area of software is now essentially free, which paradoxically makes deep systems engineering, deterministic verification, and zero-trust data guarantees more valuable than ever.
If the build cost collapsed, the moat relocates to operating, securing, and maintaining at scale — the work that doesn’t demo and doesn’t vibe-code. Your three examples are perfect because none of them show up in a screenshot: idempotent webhook retries on a mid-transaction Stripe timeout, cgroup tuning for the 3 AM OOM, passkey signCount desyncs that silently lock out paying users. That’s the invisible 10% where trust lives — all failure-mode engineering an LLM never saw in the happy path. Cloning the surface going to zero makes the depth more valuable, not less.
The maintenance point is where the argument becomes most interesting. I’d judge an alternative by whether it can import a real project, preserve the awkward edge cases, and export it again without loss. A familiar interface makes switching look possible; a trustworthy round trip makes it practical.
The round trip is the real test, and you’ve drawn the line precisely: a familiar interface makes switching look possible, a lossless round trip makes it practical, and the gap between those two is where most alternatives quietly die. Importing the happy path is easy; it’s preserving the awkward edge cases — the files real projects actually accumulate — and handing them back without loss that proves the lock-in is actually broken. Anything less is a viewer wearing the costume of an escape route.
There's a selection effect upstream of everything this thread names — and it lives in the AI builder's pricing model, not in the clone.
The dogfooding, year-three, and reversibility tests judge a clone after it exists. But most clones die earlier, and the killer is how the builder bills for iteration. Metered per-message pricing makes every 'fix this bug' cost real money, so people stop at v1 — the abandoned-alpha graveyard isn't laziness, it's economics. Flat-rate builders produce the opposite failure: unlimited regeneration, so people iterate fifty times and ship unreviewed spaghetti nobody can maintain. Either way, the tool's pricing pre-selects the clone's death date.
So the survival question gets a corollary: before asking whether you'd trust a clone, ask whether the builder lets you afford the fifty iterations trust requires — and whether you can export the code into a repo, because the builder is the wrong place to do maintenance. That folds this thread's round-tripping point into tool choice itself.
There's a cost ranking of AI app builders vs cloud IDEs that lays the per-builder economics out — worth a skim if you're picking a stack to build on rather than demo one: AI app builder cost ranking. The spread is bigger than most assume, and it flips which tool is 'cheap' once you're past the first prompt.
That’s a genuinely new axis — everything else in the thread judges the clone after it exists, but you’ve found the selection effect upstream, baked into the builder’s pricing before a single line ships. Metered-per-message kills iteration because every “fix this bug” costs real money, so people freeze at v1 — the abandoned-alpha graveyard is economics, not laziness. And flat-rate produces the opposite corpse: fifty regenerations into unreviewed spaghetti nobody can maintain. The pricing model pre-selects the death date. That’s sharp, and it folds the round-tripping point right into tool choice: can you afford the iterations trust requires, and can you export the code somewhere you can actually maintain it, because the builder is the wrong place to do that work. (Noting the link; I’d keep the thread’s focus on the mechanism, which stands on its own regardless of any specific ranking.)
Building an app is one thing. Earning people’s trust and continuing to support and improve it is the real work. As a co-founder building affordable software, I hope AI makes it easier for small teams to solve real problems, not just copy existing products.
What makes you trust a small, independent app?
what makes me trust a small, independent app: a real person visibly behind it who answers when something breaks; honesty about limitations instead of overclaiming; and the quiet signal that they use it themselves, so I know they’ll feel the bugs before I do. And above all, that I can get my data out — a clear exit is paradoxically what makes me willing to stay, because it means they’re keeping me by being good, not by trapping me. Trust in a small app isn’t built by features; it’s built by a maker who clearly isn’t going anywhere and isn’t trying to lock the door behind me. Being small is actually an advantage there — a giant can’t credibly promise you a human on the other end, and you can.
The last 10 percent point is the whole story. From the agency side I can tell you, clients do not pay for the visible features. They pay for the ugly parts. Migrations, weird old data, the edge case that only happens on one customer's account, someone answering when it breaks. A clone demo skips all of that, which is exactly why it looks easy. What survives, I think, is not the clone. It is the one person who picks a single angry niche, fixes their one painful workflow properly and actually picks up the phone. Do you think any of these full suite clones stand a chance, or is narrow the only way this ends?
“Clients pay for the ugly parts” is the whole thesis, blunter than I put it — the migrations, the one account’s weird legacy data, the edge case nobody sees, someone answering when it breaks. None of it demos, which is exactly why the clone looks easy and isn’t.
No, I don’t think the full-suite clones stand a chance as suites — because a suite is a promise to handle everyone’s ugly parts across seven apps. That’s seven times the invisible maintenance with no one whose own pain forces any of it to get fixed. Breadth multiplies the thing that kills clones and dilutes the thing that saves them.
Narrow isn’t the only way it ends, but it’s the only way it ends well — because narrow is the only shape where one person can hold the 10% in their head and has a real motive to grind it: they picked one angry niche whose pain they feel. That’s your survival filter exactly — one person, one furious niche, one workflow fixed properly, and they pick up the phone. The clones commoditized the surface; depth in a narrow groove is the only moat left, and narrow is just what makes depth affordable to one human.
The idea that the moat was really the cost of building stuck with me, along with your point that a clone only has to make "build your own" thinkable. When I've rebuilt small internal tools with an agent, the first version shows up fast and then the last 10% you describe eats most of the week. Who do you think is still maintaining these clones a year from now?
Almost nobody, for the clones built as clones — but the few that survive will be the ones where the builder needs the tool themselves, because that’s the only motivation that outlasts the novelty. Your internal-tools experience is the whole thing in miniature: fast first version, then the last 10% eats the week, and the only reason you push through that week is that you have to use the thing on Monday. A viral clone has no Monday. So a year out, the survivors won’t be the ones that looked most like Photoshop at launch — they’ll be the unglamorous ones quietly maintained by someone who’d be personally annoyed if they broke. Dogfooding isn’t a nice-to-have signal; it’s basically the whole forecast.
First prompt: "Oh my God, this is magic." 60 billion tokens and 3 weeks of real data and real use cases later: the solution finally becomes useful.
The gap between “this is magic” and “finally useful” is the whole story — AI made the first cheap, not the second.
💯 yeah ... The second, is experience, engineering, real data, real user , ... and in best case already trust from the market
💯
I think if we keep the goalpost low enough, we can build something that people would actually use. And maybe add more features later rather than adding all features in the first time itself and leaving them unpolished or UI only. The small but frustrating problems only come up later, and fixing them takes a lot more time because of that.
That’s the sane antidote to the vibe-coding failure mode: keep the goalpost low, ship something small that fully works, then grow it — instead of generating all fifty features at once, each one 80% done and UI-only. A narrow thing that actually works beats a broad thing that only demos, because the broad-but-shallow version is exactly where those small frustrating problems hide, and they only surface once someone really uses it. And you’re right that they’re disproportionately expensive to fix late — partly because by then they’re tangled into fifty other half-built things, and partly because the person who generated it fast never built the understanding to debug it slow. Narrow and real compounds; broad and shallow collapses under its own surface area.
Amazing work! Keep innovating and learning.
hello
hi
I've shipped a lot of small AI tools, and the first version is rarely the hard part. It's the bugs you only find after using it for a week. The tools you rely on yourself tend to survive.
the week-later bugs are the real work, and the tools you rely on yourself are the ones that get them fixed. Dogfooding isn’t a nice-to-have; it’s the whole survival filter, because only your own daily pain keeps you around long enough to find them.
I used Adobe products for nearly 20 years, and I stopped after not needing Illustrator or Indesign or Premiere to produce materials for clients anymore, and mostly used Figma for UI/UX, so I can somewhat say if these products are valid or not, but..
I can't even install 'em.
I'm not giving open source software that I haven't vetted admin rights. So I guess that's that then. I was considering setting up a VM to sandbox 'em a little bit, but.. Not sure if I want to put that kind of effort in.
I'm 99% sure any type of proper development around these apps will fizzle away eventually. Nobody has competed with Adobe in 20 years. Same can be said about Microsoft Office. I seriously doubt the open source community has the ability to compete with them either.