Software: stop before starting over

When I use SAAQclic, Quebec’s online service for driver licensing and vehicle registration, I struggle to understand how a project of such scale can produce such a frustrating experience. That feeling as a user is echoed in the documented problems.

In February 2025, Quebec’s Auditor General projected that the CASA program would rise from C$638 million to at least C$1.1 billion by March 2027. This figure includes the program’s development and operation; SAAQclic is one component.¹

The audit also identifies inadequate testing and process documentation completed after the contract was signed.² Commitments had been made before enough had been clarified and tested about what was being built.

Major software projects still in the pipeline should be paused when they follow this logic: committing most of the resources before testing the needs and the proposed solution.

Understand before committing

In my own practice, the second half of 2026 marks a substantial shift in what one person or a small team can build with AI.

In Software before the decision, I described how I had obtained a working prototype before settling several important choices. Organizations should build on that possibility.

Prototyping already existed, but the effort required to make an idea testable can now fall considerably. We can uncover an overlooked rule or discard a poor approach before it becomes an expensive commitment.

A prototype lets us observe what users actually understand and manage to do. It becomes a tool for making decisions.

Put domain expertise at the centre

Domain experts should lead this exploration, preferably from within the organization. They know the operations, the exceptions and the consequences of an error. They need time and real authority over priorities and validation.

An administratively correct rule can nevertheless produce an incomprehensible experience. Users must be able to try the service early, including those who face access barriers or less common circumstances.

Software specialists remain responsible for architecture, security and technical reliability. A convincing interface does not establish that data migration, integrations and operations will work.

The 2025 DORA report describes AI as an amplifier of organizational strengths and weaknesses.³ Producing faster therefore requires checking what we produce as well.

Evidence before major budgets

This requirement applies to internal teams and major service providers, including CGI and IBM. These companies already offer AI-related services.⁴ Their claimed gains should be reflected in costs, timelines and the control retained by the client.

Contracts should fund bounded stages, with explicit criteria for proceeding: usefulness demonstrated with users, technical feasibility, quality and operating cost. Organizations must retain access to their code, their data and the knowledge needed to evolve their services.

Starting again from the need may lead to keeping a system, simplifying it, replacing certain functions or abandoning the project. A complete rewrite must also be justified.

Projects already underway must also be reassessed, comparing the cost of continuing, adapting or stopping while ensuring the continuity of essential services.

Money already spent explains how we got here. It does not, on its own, justify what we will spend next.

Before signing up to build at scale, we should be able to show what users have tried, what domain experts have validated and what the organization has learned.