In 2026, a company pays €6,500 a year for its time-tracking tool: 50 users, priced per person. That is €32,500 over five years, before any price increase.
And its team complains about it. The tool is slow, the interface is complicated, and essential features stay locked, reserved for higher plans while the bill is already rising. We offer to build one.
A per-user subscription grows with your team and the features you unlock
The bill has two engines. The first is mechanical: every new hire adds a licence. The second is more discreet: features are spread across successive plans, and the ones a team really needs, such as connecting its data to another tool or limiting what each person sees in reports, are rarely in the base plan. To get them, you have to move up a tier, often for every user at once.
Every new need is therefore paid for twice: through the number of licences and through the plan level. The bill follows your headcount and the vendor's price list, rarely the service the tool actually provides.
In many companies, ours included, this line of spending has risen sharply over the past two or three years. The model does have real strengths: nothing to install, nothing to maintain, a tool ready the same day. But when your teams use it every day without liking it, and the feature they lack is always one plan up, the question eventually comes up.
For a long time, the answer was quick. A custom tool cost too much for a need as common as time tracking. That calculation is changing, not for every tool, but for some of them. And not thanks to AI alone: what makes the move safe is a development pipeline controlled end to end, which designs, checks, tests, deploys and documents every change.
Start from how people work: log fast, invoice right
Before writing any code, we look at how the team works. Everyone needs to log their time in a few seconds, on mobile as well as on desktop. That time then feeds invoicing, the intranet and the company's dashboards.
A tool that is simple to use, then, but with real responsibilities behind it. An entry or calculation error ends up on an invoice, or skews how a project is managed. The first scope has to be useful from day one, and above all reliable. It also has to be able to evolve afterwards without ever putting that reliability at risk.
Four days for a first version and the means to test it
We are not starting from scratch. We have proven code bases, reusable interface components, our AI agent framework and a development pipeline already in place. Every project benefits from what the previous ones made it possible to build.
Two people from GDN lead the project. Several AI agents work in parallel, steered by our engineers. Architecture, integrations, technical choices and validation remain their responsibility. AI accelerates, engineering secures.
After four days, the company has a first operational version, focused on the essential features. Enough to check in real use that the tool meets the need, before going further.
The most important part lies elsewhere. In those four days, we also set up the pipeline that lets the tool evolve without breaking it:
- continuous integration, which automatically checks every change before accepting it;
- automated unit, interface and security tests, backed by code review, which flag any regression;
- test environments created on demand, to check each change on its own, without touching the tool in service;
- scripted deployment, identical from one release to the next;
- versioned code, where every change is linked to the request behind it.
This work does not show in a demo. Yet it is what makes the difference between a tool delivered fast and a tool that stays under control over time.
One day to go live, five days to outdo the old tool
Going live takes one day. Final checks in the target environment, verification of the connections to invoicing, the intranet and the dashboards. Then backups, and the switch-on.
Next come five days to go beyond a simple replacement. The features the old subscription reserved for a higher plan are available from launch, at no extra cost. On top of them come many features the team never had, starting with the ones that change its day-to-day work:
- everyone chooses their own time zone; their hours, totals and exports follow that choice, without any recorded time being rewritten;
- the company report counts everyone in a single time zone: two readers in two different time zones see the same monthly total;
- report filters apply in one click, drive the whole page, and the export contains exactly what is displayed;
- a project manager only sees, in reports, the people and projects they are responsible for, and the tool rejects any request outside that scope;
- durations show their unit, so an hours total is no longer confused with the stopwatch counter;
- confirmation is required before any destructive action, such as deleting a client or deactivating an account, and an edited form does not close without warning;
- forms can be submitted and closed from the keyboard, and a skip-to-content link makes navigation easier by keyboard or with a screen reader;
- entry descriptions can run to 16,000 characters, up from 255 in the first version;
- only an administrator creates accounts: open sign-up is gone.
And what does not show on screen, but matters just as much:
- a read-only integration interface for the intranet and the dashboards: access tokens with precise rights, expiring after one year, and every call logged;
- technical accounts dedicated to these integrations, with no access to the application at all;
- rate limiting on sensitive access points: login, exports, synchronisation;
- security headers, which for example prevent the tool from being displayed inside another page;
- complete documentation of the programming interface, and a test that checks no route escapes it.
This is where the development pipeline comes into its own. Every change is tested automatically, checked in a dedicated environment, then deployed and documented. Five days of fast changes, without weakening what already works. Without that pipeline, the same speed would be a gamble.
Three years of history migrated, an overnight switchover
Building the tool is often not what worries people most. Leaving the old one is. What happens to three years of logged time? And to the intranet and the dashboards, which read their data from the old tool?
The full history is migrated from the old tool's exports. Each import first runs as a simulation, which lists creations, anomalies and totals without writing anything. The import can be replayed as often as needed, without ever touching entries made in the new tool.
Former team members are kept as deactivated accounts, so their time stays attached to the right projects. The export files contain personal data: they are deleted after the import, and every import is logged.
The intranet and the dashboards now read the new tool through the integration interface, read-only. For them, the change goes unnoticed.
The switchover happens in one go, with the old tool frozen. The new one becomes the single source of truth, history included, and the team drops the old one overnight. Its feedback fits in a few words: much faster, much simpler.
Compare five years of subscription with five years of the software's life
Let's do the maths. The full development, from the first version to the improvements, costs €5,000 excl. VAT for less than two weeks of work. The subscription it replaces amounts to €6,500 a year, or €32,500 over five years.
Stopping there would make the comparison too flattering. Software keeps living after delivery: it has to be hosted, its server monitored, its security updates applied. Here, the tool is hosted on AWS Lightsail for €76 a month, and proactive server maintenance comes to around €100 a month. That is €10,560 over five years.
Development and operations included, the tool costs around €15,560 over five years, against €32,500 for the subscription. The gap, nearly €17,000, funds the changes to come. That is where the real comparison lies: a subscription gives you the changes the vendor decides on, your tool gets the ones your teams ask for, at the pace you choose.
Part of the difference cannot be measured directly. The infrastructure is fully described as code: it can be recreated identically, scaled up if usage grows, or moved to another host if the company ever decides to. The company keeps control of its code, its data and the pipeline that makes them evolve. The features its team needs no longer depend on a vendor's price list.
Off-the-shelf SaaS or your own SaaS: the choice depends on its features, on what it really brings your teams and on what it will cost you over time. When a standard need is well covered, changes little and the tool is liked, rebuilding it makes little sense: the vendor funds features for you that you would have no reason to develop on your own. Your own tool becomes worthwhile when several signals add up: a bill that climbs with headcount and plans, a tool your teams put up with, needs specific to the way you work, data that has to flow to your other tools.
One condition, finally, is non-negotiable. Owning your software means taking on its constant evolution, its scaling and its security. Without a controlled development pipeline, which tests, checks, deploys and documents every change, custom software quickly becomes a new weak point. With one, it stays under control whatever happens. That requirement has a cost, but the calculation often remains favourable, and all the more so the more users you have: the subscription grows with every licence, the cost of your tool far less. The first version can also be handed over to your in-house teams, along with the pipeline that comes with it; we then support them so they take over new development properly.
A word of caution on timelines. Ten days is the result of a precise scope and a pipeline prepared long in advance. Every project has its own constraints and schedule: this figure is a benchmark, not a promise.
Speed is prepared in the workshop
You could sum up this project with a slogan: SaaS is dead, long live your SaaS. The slogan is provocative. The possibility, though, is real.
What makes those ten days possible is not AI alone. It is everything that exists before day one: proven code, the pipeline that checks, tests, deploys and documents every change, and two engineers who know what to verify. That pipeline is also what secures what comes next: the tool can keep evolving, take on more users and stay secure, without anyone losing control of what goes into production.
Go through this year's subscriptions. Which one are you paying for a tool your teams put up with, when they could describe exactly the one they need? That is the one to start asking the question about.