Recreating the appearance of an application is a different task from delivering software that customers can rely on. Recent reports about AI-built software replicas nevertheless raise a useful question for software service providers: if parts of development take less time, what should customers expect to pay for? The answer involves more than rates. It depends on the expertise and responsibility the supplier brings to the work.
Rebuilding software has limits
There is also a legal distinction between software functionality and its expression. The Court of Justice addressed that distinction in the 2012 SAS Institute v World Programming case. The judgment is not a blanket permission to copy software or its associated material. The narrower point here is that legal protection and the practical cost of rebuilding something are different barriers.
An application’s visible behaviour can help someone design an alternative. It does not resolve every edge case, integration or maintenance problem. The commercial question is how much development work becomes easier and what expertise is still needed to make the result dependable. Comparing an early version with an established product obscures that distinction.
What the customer still needs
Customers still need someone to establish the problem, understand the exceptions and agree what an acceptable result looks like. Once software is in use, it needs maintenance, security, support and integration with other systems. Development remains part of that work. Suppliers need to explain where the effort goes and how it contributes to the result.
Product businesses also compete on usability, switching costs and service. For bespoke development, the purchasing question is more immediate: what expertise, delivery work and responsibility does this engagement include?
Hourly rates, fixed fees or outcomes
For suppliers that bill by the hour, shorter development time may justify revisiting estimates and pricing. That does not make hourly billing obsolete. It can be a sensible arrangement when scope is uncertain. A fixed fee or outcome-based agreement requires clarity about scope, measurement and how much control the supplier has over the result.
I would start with the proposal. What work do you expect to do? Where might AI help, what review is still needed, and who carries the risk if the assumptions prove wrong? Those questions support a more useful pricing discussion than a general promise of faster delivery.
Start with a recent proposal
Take a recent proposal. For each substantial item, can you explain why the work is needed, what effort it requires and how the customer will assess the result? That is a practical place to start reconsidering your offer.