Pre-2023 cost benchmarks no longer describe the reality of custom software. A narrowly scoped project can now be settled in a few evenings of dialogue with a code assistant; a project that touches several existing systems still takes weeks, sometimes months, to complete. What has changed is the time it takes to write code — not the time it takes to integrate it, migrate it, verify it and maintain it. Here is how I reason about it, tier by tier, without a made-up number.
Why pre-2023 benchmarks no longer hold
For fifteen years, the argument that justified almost any software subscription fit in a single sentence: building your own tool cost tens of thousands of francs and took months, with a non-trivial risk of failure. That argument rested on a reality that has shifted along two distinct axes over the past eighteen months.
The first change concerns the writing of code itself. Development assistants radically reduce the time it takes to turn an idea into a working implementation. I don't say this in the abstract: I built FiscalDoc, my local tax-filing application, by dialoguing with a code assistant rather than writing it line by line — three evenings, for a tool whose operating cost has remained zero. The full account is here.
The second change concerns embedded intelligence. Open models now run on standard professional hardware, with no call to a third-party API billed by usage. What yesterday required a subscription to a cloud service can, for a growing share of use cases, run locally — which shifts both the cost and the question of data sovereignty, which I examined in detail in SaaS or custom-built: renting or owning your tools in Switzerland. Fifteen years spent overseeing digital budgets in large organizations taught me to distrust a single figure handed out before a single question has been asked — that is even truer today than it was yesterday.
Three tiers, not a single number
A serious quote never starts from a price; it starts from a tier, then refines. Here are the three I use to frame a conversation, before any precise costing.
The few-evenings project. A narrowly scoped need, carried by a single person who knows their subject in detail, with no integration to a third-party system and no simultaneous users to manage. FiscalDoc is the example: a few evenings of dialogue with a code assistant, and an operating cost that has remained zero once the tool was built. This tier genuinely exists, but it stays rare in business — most professional needs involve several users and at least one connection to an existing system.
The few-weeks project. A business tool that serves an entire team on a specific workflow: shared document filing, a management dashboard, automation of a well-defined internal process. This requires an interface designed for multiple users, a testing phase beyond what a single person's tolerance for imperfection would allow, and often a simple integration with a tool already in place. The budget then runs to a few thousand francs, excluding VAT, over a horizon of weeks rather than evenings.
The structuring project. A project that replaces part of the information system: several integrations with existing tools, migration of historical data, security and compliance requirements, a multi-year maintenance plan. This tier remains a genuine undertaking, with a horizon of months and a budget that can run to tens of thousands of francs, excluding VAT. This is precisely the type of project I frame with the buy-or-subscribe decision grid, in the same spirit as the scoping of my custom projects.
What hasn't gotten cheaper: integration, migration, quality, maintenance
The time it takes to write code has collapsed. Four other line items, however, have not moved — and they are often the ones that determine a project's real tier.
Integrations. Connecting a new tool to accounting, an ERP or a bank requires understanding the limits of their respective interfaces, handling error cases, and tracking how they evolve over time. A code assistant speeds up the writing of that connection; it does not reduce the time needed to verify it, nor the number of third-party systems whose behavior remains outside your control.
Data migration. Extracting the history out of a SaaS subscription to install it in an owned tool requires cleaning up heterogeneous formats, reconstructing links between records, and verifying that no data was lost along the way. This work remains largely manual, regardless of how quickly the new tool was written.
Quality. A tool built for a single use can tolerate small rough edges that get fixed on the fly. A tool that several employees, customers or a regulatory obligation depend on cannot tolerate the same margin: testing, edge-case handling, security review. That rigor does not get shorter just because the first version arrived quickly.
Maintenance. An owned tool keeps evolving with the business, exactly as a subscription keeps receiving updates. The difference lies in who bears the load. Delivering the code along with its own AI-assisted maintenance tooling reduces this cost over time, without eliminating it: someone still needs to remain capable of working with that tooling.
From a tier to a figure
None of these three tiers replaces a real quote: they are orders of magnitude for framing a first conversation, not a price list. Moving from a tier to a figure first requires settling the question that precedes cost — whether the tool should be built or rented. And for a share of a company's tools, the right answer remains the subscription: I say so plainly in When is keeping your SaaS the right choice?. This way of framing things, tier first and then question, is the one I apply to every custom project before writing a single line of code. To situate this decision within the full set of digital initiatives a Swiss SME faces, the complete roadmap is laid out in What should a Swiss SME do about AI in 2026?
Key takeaways
— Pre-2023 cost benchmarks no longer hold: writing code has collapsed in time, but integration, migration, quality and maintenance have not. — Three tiers frame a first conversation: the few-evenings project, the few-weeks project, the structuring project — never a single number handed out blind. — The real tier hinges on what hasn't moved: the number of systems to connect, the volume of data to migrate, the required quality bar, the maintenance load.
FAQ
Does a custom project cost less than a SaaS subscription today? It depends entirely on the tier and the time horizon. For a narrowly scoped need over a multi-year horizon, custom software often becomes competitive. For a still-evolving need or a short horizon, the subscription generally remains the cheaper option.
Do code assistants eliminate the need for developers? No. They change the speed at which a well-defined need becomes a working tool, not the need to understand the architecture, verify quality, and maintain the result over time. Judgment remains human; execution has sped up.
How do I know which tier my project falls into? Count the existing systems to connect, the number of simultaneous users, and the age of the data to be carried over. Several connections, a dozen users, or a history spanning several years generally shift a project from the "weeks" tier to the "structuring project" tier.
Do I need an in-house technical team before considering custom software? Not necessarily, provided the provider delivers the code in full ownership along with AI-assisted maintenance tooling. The company then remains autonomous without having to hire a dedicated development team.
Has anyone ever given you a quote without asking about your actual workflows? The AI Usage Diagnostic: sixty minutes to lay out your actual workflows, identify what deserves custom software, what stays in SaaS, and what needs no AI at all. Book a diagnostic
Jérôme Deshaie is CEO and founder of MCVA Consulting SA, an AI-augmented agency based in Valais. Fifteen years serving major international brands, now working directly with Swiss SMEs. Background.