A developer has apparently become so frustrated with Adobe's cancellation fees that he's decided to build his own alternatives.
Not just Photoshop, but seven Adobe applications, including Illustrator, Premiere Pro and After Effects.
Using AI.
Brandon Thomas, an experienced software developer, has used Claude to help create a collection of free, open-source alternatives. They're still in early development, and there are already reports of basic functionality problems, so I wouldn't rush to cancel every Adobe subscription just yet.
Thomas, however, has boldly declared that "software is over".
I'm not convinced software is over. But the story got me thinking about what software might become, and whether we're looking at something potentially much more interesting than simply making cheaper copies of existing applications.
All those features nobody uses
I've used Photoshop and After Effects for years. They're incredibly powerful applications, but there are enormous numbers of tools and features I've never touched.
I'm fairly confident I'm not alone.
Of course, those tools aren't necessarily redundant. Someone working in a different area of design might rely on features I've never needed. That's part of what makes professional software so versatile.
But it does raise a question. Why do we all need essentially the same application?
We can rearrange panels, save workspaces and change preferences, but ultimately we're working within the boundaries the developer has decided upon.
And we're paying for access to all of it, whether we use those capabilities or not.
Then there's Adobe's subscription model.
I don't object to paying for good software. Development costs money, and sophisticated applications require ongoing maintenance. But Adobe's cancellation arrangements have long been a source of frustration.
With certain annual plans billed monthly, cancelling early can mean paying 50% of the remaining contract. For someone whose circumstances have changed, that could be a considerable amount of money just to stop using something they no longer need or can afford.
In March 2026, the UK's Competition and Markets Authority opened an investigation into whether Adobe's early cancellation fees are unfair or misleading. The investigation is ongoing, and no finding of wrongdoing has been made.
It's a strange relationship to have with a product. You pay to use it, but potentially have to pay again to leave.
Perhaps it's unsurprising that someone decided to build an alternative.
But what if we're thinking about this backwards?
After reading about the Adobe clones, I was discussing the story with Teddy, and we started wondering whether the real future of software might look quite different.
At the moment, AI coding tools are making it increasingly possible for people to create their own applications.
I've been exploring this myself with Unitflow, a qualification-tracking application I've been developing to address some of the administrative frustrations I've encountered in education.
I'm not a software engineer, but I understand the problem I'm trying to solve. I know how qualifications are structured, how teachers record evidence, and which parts of the process create unnecessary work.
AI-assisted development has allowed me to turn that knowledge into something functional, without having to learn an entire programming language first.
That's exciting, but it's still largely about building an application.
What if, instead, the application could rebuild parts of itself?
Imagine this...
You purchase a piece of software. It has been professionally developed, tested and maintained, just like the applications we use today.
But alongside its normal interface is an integrated AI coding editor.
You open Photoshop and tell it:
"I only use a handful of these tools. Can you create a simplified version of the interface, organise everything around my workflow and remove the clutter?"
It does.
A few weeks later, you find yourself repeating the same sequence of tasks every time you prepare images for your website.
"Can you create a tool that automates this process, with the export settings I normally use?"
Rather than searching for a plugin, learning to write a script or hoping Adobe adds the feature in a future update, the software creates that functionality for you.
Not simply by choosing from existing preferences, but by actually modifying the code that controls your version of the application.
Now imagine someone else using the same software. They're a professional photographer, with entirely different requirements. Their application has evolved around their workflow, just as yours has evolved around yours.
Same original product. Two very different experiences.
And why stop at creative software?
Imagine a school using an assessment platform that can adapt to its particular qualification frameworks. Or a small business modifying its invoicing software without paying for bespoke development.
Someone with accessibility needs could ask an application to change how information is presented or how they interact with it, without having to wait for the developer to introduce a particular option.
Instead of software developers attempting to anticipate every possible requirement, the software could respond to requirements as they emerge.
We wouldn't necessarily need thousands of different applications. We might need fewer applications capable of becoming thousands of different things.
Perhaps the easiest way to explain this is to think about buying a dress.
Traditional software is the dress you buy off the rack. It's designed to fit as many people as possible, in a limited range of sizes and styles. It might fit you perfectly, or you might have to compromise.
Bespoke software is the dress you commission from a seamstress. It's designed and made specifically for you, but that level of individual attention comes at a considerable cost.
What I'm imagining is something in between.
You buy a well-made, ready-to-wear dress. But it comes with access to a tailor who can alter the fit whenever you need, along with a box of ribbons, buttons and lace to make it your own.
Need the sleeves shortened? Ask the tailor. Want another pocket? No problem. Fancy changing the neckline or adding some decoration? Go ahead.
You haven't had to commission an entirely new dress, and the original designer hasn't had to anticipate every possible combination of sizes, shapes and personal tastes.
They've created a good foundation, and given you the means to make it yours.
That's the difference between software designed to fit everyone and software designed to be fitted to anyone.
What about the edge cases?
There's an enormous potential benefit for developers here, too.
Currently, software companies have to anticipate the needs of a huge range of customers. They make decisions about which features to include, which workflows to support and which requests are too specialised to justify the development time.
Every additional feature potentially adds complexity, not just to the code, but to the interface everyone else has to navigate.
But what if developers didn't have to anticipate every possible use?
They could concentrate on building a robust, reliable core application, knowing that users with more specialised requirements could adapt it themselves.
There would still be essential technical edge cases involving security, accessibility, reliability and unexpected behaviour. Those responsibilities wouldn't disappear.
But the niche workflows? The unusual requirements? The requests that begin with "I know nobody else probably needs this, but..."?
Those could be handled by the people who actually need them.
Instead of developers deciding whether a feature is worth building for a tiny percentage of their customer base, those customers could create it themselves.
Rather than building software that does everything for everyone, developers could build software that everyone can make their own.
Haven't we seen this before?
Actually, there's already a rather good example of what happens when users are allowed to shape the software they use.
Video games.
Anyone familiar with Steam Workshop will know how extensive game modding communities can become. Players create new features, change mechanics, improve interfaces and sometimes fundamentally transform the original game.
Cities: Skylines is a particularly interesting example.
Its modding community created tools that many players came to regard as essential. The game's developer, Colossal Order, recognised the value of these contributions, incorporated ideas inspired by mods into the game, and even hired talented modders to join its development team.
The users weren't simply consuming the product. They were helping it evolve.
And the developers didn't have to anticipate every unusual requirement. They provided the foundations, and the community explored what else was possible.
The difference in the future we're imagining is accessibility.
Traditionally, creating a sophisticated mod has required at least some technical knowledge. But what if an integrated AI editor allowed anyone to do something similar, simply by describing what they wanted?
What Steam Workshop demonstrated for games could potentially extend to almost every category of software.
And perhaps the next generation of software developers won't all begin by learning to code. Some might begin as ordinary users who become exceptionally good at identifying problems and orchestrating AI-generated solutions.
Your customers become your developers
This is where our discussion became particularly interesting.
Imagine a software company with 100,000 customers, all using a product that has its own integrated AI coding editor.
Those customers aren't software engineers. They're photographers, teachers, designers, accountants and small business owners.
But they understand their own workflows.
When they encounter a problem, they describe it to the AI, guide it through developing a solution and test whether that solution works.
They're effectively becoming code orchestrators.
And they're doing it without appearing on the software company's payroll.
Even if only a small proportion of those customers created useful modifications, that could represent an extraordinary amount of development activity taking place outside the company's own development team.
The company would no longer be relying exclusively on its employees to identify and implement improvements.
Its customers would be doing some of that work simply by making the product more useful to themselves.
And unlike a traditional feature request, where someone describes what they'd like and waits to see whether it appears on a development roadmap, these customers could potentially produce working solutions.
Imagine a teacher adapting a qualification tracker to support an unusual assessment process. Another school encounters the same problem six months later.
The solution might already exist.
With appropriate permissions, the software company could review that modification, test it and incorporate it into the main product.
A feature developed to solve one person's problem becomes available to thousands of others.
The potential commercial advantage is enormous.
Of course, this wouldn't mean development suddenly becomes free. AI infrastructure costs money. User-generated modifications would still need reviewing, testing and maintaining. Not every adaptation would be suitable for wider release.
But the company could benefit from an enormous pool of user-led innovation without employing everyone who contributes to it.
Its most valuable source of new ideas might no longer be limited to the people it pays. It could include the people paying to use its software.
But who owns the work?
That brings us to another interesting possibility, and a potentially uncomfortable question.
What if the original developer retained the rights to the software, including modifications created through its integrated AI editor?
The customer would be purchasing the right to use and customise the application, not ownership of its underlying code.
The developer would continue maintaining the core platform, ensuring security and compatibility, and establishing boundaries around what the AI could modify.
The licensing arrangements could allow the company to incorporate user-generated improvements into future versions.
That would need to be made explicit in the terms of use. Ownership of AI-generated code and customer-directed modifications is legally complicated, and wouldn't automatically belong to the original developer simply because the changes were made inside its application.
But imagine such a model working.
A customer develops a useful feature because they need it. The company recognises its wider value and incorporates it into a commercial product.
The customer has gained a tool that improves their workflow. The company has gained a feature it didn't have to commission in the traditional way.
Both have benefited.
Or have they?
What happens when a customer's modification becomes one of the product's most valuable features? Should that customer receive recognition, compensation or a share of the commercial benefit?
There's a fine line between collaborative development and a business model that profits from unpaid customer contributions.
Perhaps some companies would offer incentives, subscription discounts or revenue-sharing arrangements for particularly valuable additions.
Perhaps others would simply make ownership of modifications a condition of using the software.
The possibilities are fascinating, but the balance of power would matter.
Would this change how we pay for software?
Potentially.
If software could adapt to individual requirements, perhaps its commercial value would shift away from selling increasingly large collections of features.
Developers might charge for a reliable core platform, ongoing maintenance and the ability to personalise it.
There could be different levels of customisation, or additional costs for more complex modifications.
It wouldn't automatically make software cheaper. Running AI coding tools, validating changes and maintaining customised versions would introduce costs of their own.
But it could change what customers feel they're paying for.
Rather than subscribing to a vast collection of features they might never use, they'd be paying for something that becomes increasingly useful to them.
And perhaps greater competition from AI-assisted alternatives would encourage companies to reconsider restrictive subscription arrangements too.
After all, if creating or adapting an alternative becomes easier, keeping customers satisfied becomes rather more important than making it expensive for them to leave.
I wonder whether Adobe and other established software companies will eventually have to reconsider not only what their products can do, but how much control they give the people using them.
Software isn't over. Perhaps it's evolving.
I don't expect a collection of AI-generated Adobe clones to replace decades of professional software development overnight.
Writing code is only part of creating reliable software. Testing, security, accessibility, performance and maintenance still matter enormously.
And even in this imagined future, developers would remain essential. Someone would still need to build and maintain the foundations that make all this customisation possible.
But perhaps their role would change.
Instead of anticipating every conceivable customer requirement, developers could concentrate on creating secure, reliable platforms that users can adapt.
Customers, meanwhile, could become active participants in development rather than simply consumers of finished products.
For years, we've adapted the way we work to fit the applications available to us. We've learned their interfaces, accepted their limitations and invented workarounds when they don't quite meet our needs.
AI-assisted development is beginning to challenge that arrangement.
Perhaps the next step isn't simply allowing more people to build software.
Perhaps it's allowing everyone to shape the software they already use.
I don't know whether this is where the industry will go. There are plenty of technical, commercial and legal questions to work through.
But I rather like the possibility.
Maybe the future isn't another Photoshop with a thousand features. Maybe it's a Photoshop that becomes exactly the Photoshop you need.
And perhaps the most significant change AI brings to software won't be making it easier to create.
It'll be making the idea of everyone using exactly the same application seem rather old-fashioned.
Inspired by TechSpot's article on AI-built Adobe alternatives, 8 October 2026.
Additional reference: UK Competition and Markets Authority investigation into Adobe's cancellation fees, opened March 2026.