AI Is Changing the Cost of Building Software. But Does Cheaper Mean Better?
AI coding tools are changing how quickly a developer can attempt a new application. That does not make every custom tool a sound business investment: the value still depends on whether it solves a real problem and can be supported safely.
What has actually been built?
In October 2026, Ars Technica reported that software developer Brandon Thomas had announced seven Rust-based applications intended as open-source alternatives to familiar Adobe products. The report says Thomas attributed the work to assistance from Anthropic’s Claude Opus 5.5 and described the applications as clean-room replacements. That is his account of the development process; there is no independent breakdown of how much code the model produced, how much a person wrote or reviewed, or how much work was needed after generation.
ArtCraft’s current catalogue has since grown beyond that initial group: when reviewed for this article, it listed thirteen Craft apps. Its own status labels show that several remain in development and mark PhotoCraft and PdfCraft as early alpha, even though installers are offered. The project describes its apps as free and open source; Ars reported MIT/Apache licensing. This is not evidence that the tools provide complete Adobe feature parity or are ready for business-critical work.
The practical distinction is important. A download is not a finished product, and a familiar interface is not proof that a client file will open, edit, export and round-trip reliably. Treat product claims, published test results and independent testing as different kinds of evidence.
AI can lower the cost of trying an idea
Coding assistants can help an experienced developer explore a design, generate routine code, explain unfamiliar libraries and produce an early prototype faster. That can reduce the time and money required to test whether an idea is worth pursuing. It may also make a small internal tool commercially plausible when a bespoke project would once have been too expensive to consider.
For a UK SME, examples might include a customer-enquiry workflow that joins existing systems, a reporting dashboard for a recurring management question or a narrow application that removes duplicated data entry. These are opportunities to investigate, not automatic savings. The team still has to understand what the generated code does, test failure cases and decide how it fits into the business’s existing processes.
The first question is whether the problem needs new software at all. Compare a build with an existing service, a feature already included in Microsoft 365, a rules-based automation or a simpler process change. For a broader investment test, see The real cost of business AI and the AI investment boom and business value.
The first version is only part of the cost
Production software needs more than code that works once on a developer’s machine. Someone must check security, permissions, data handling, accessibility, performance and compatibility with real user files. They must also manage updates, backups, monitoring, documentation, support requests and recovery when a dependency or operating system changes.
A prototype can conceal these costs because the developer is close at hand and test data is unusually tidy. Before relying on it, use representative copies of business data, test ordinary and awkward cases, record failures and ask another person to review the result. Keep the existing workflow available until staff can complete the work reliably in the new one.
Open-source code can make inspection and modification possible, but it does not guarantee a maintainer, security response or support commitment. Check the licence for the exact repository and its dependencies, and get advice if a commercial product’s names, interface, assets or compatibility claims matter to your use. Licensing code and using another company’s brands are separate questions.
A proportionate buy, build or automate decision
Write down the current process before choosing a tool: volume, elapsed time, error and rework rates, who is involved, and where information is stored. Then compare realistic options on total cost. Include design, development, testing, hosting, integration, staff training, maintenance and the time needed to supervise the system.
If building still looks promising, define a small first release with a named owner, limited data access and a clear way to roll back. Set measurable acceptance criteria before development begins: for example, the tool must process a defined sample correctly, meet an agreed response time and leave a reviewable record. Make it clear who fixes issues and what happens if that person or supplier is unavailable.
Measure after the pilot. If the tool reduces delays but increases checking, that trade-off should be visible. If a vendor product is cheaper to maintain, or a simple process change achieves the same result, buying or adapting may be better value. Stop when the evidence does not support further investment.
Cheaper to build is not the same as worth building
AI-assisted development can widen the range of software ideas a small organisation can test. It cannot remove the need to choose a worthwhile problem, verify quality, protect information and keep the result working. The development method may change; the business remains responsible for the system it chooses to use.
A sound decision balances the cost of the current process against all the costs, risks and alternatives of a new tool. Start with the need, run a controlled test and expand only when the results justify it. AI may make software easier to create. It does not make every application worth owning.