First pin down what it must do, then build
First get clear on what the application needs to do and why; only then do we start building. That order doesn't change because of AI — if anything, it matters more.
You get an application that is documented, tested and ready to hand over, with a developer who stays responsible for it. AI is the tool we use to get there, for new applications and for takeovers alike. It is not a separate product you buy on top.
Almost anyone can now use AI to put together something that works, and we use it ourselves every day. The difference is in what happens next. A file that works isn't the same as an application your department still relies on five years from now — one that's documented, maintainable, transferable and tested against the agreed behaviour and the exceptions we map out in advance. AI doesn't get you there on its own. That takes experience.
AI-assisted development sometimes shortens lead time. For an application built from scratch, that gain is modest.
What does change is what you get. Every delivery includes documentation of how the application is put together, the test cases it was checked against, and a structure the next developer can take over. That is part of delivery, not extra work billed afterwards. Nor is there a separate rate for AI assistance: what an assignment costs depends on the application itself — its scope, the number of data sources and integrations, and how much of an existing file can be kept.
That difference is greatest for project takeover. We read an existing application with AI assistance and document how it works, even where that documentation never existed. AI also helps us draw up test cases. Whether that saves time depends on the application; whatever AI produces, we check before a version goes to you.
First get clear on what the application needs to do and why; only then do we start building. That order doesn't change because of AI — if anything, it matters more.
We work with our own development standard for VBA projects and a project template that bakes those rules in: how the code is structured, how it is tested, and how it moves through an acceptance environment into production. AI helps write the code, our standard guards the quality, and a person signs off on every release.
We work with AI assistance, but always within the client's constraints. Where you prescribe your own systems, tooling or approvals, we develop within them — we explain how we handle this below, in the question about your business data.
Your data stays yours; how you get at it yourself is agreed per application. We deliver technical documentation, record how the system works and train your people in using it. So you know where you stand — even if you later switch to another provider.
That's up to you. For our largest client, we work exclusively within their own system environment, using the AI tooling they've approved for that purpose — we don't step outside it. If you prescribe your own environment, tooling or approval process, we develop within it. When we work in our own environment, we agree in advance what does and doesn't go into AI tooling; your production data doesn't normally belong there.
For a one-off calculation or a formula: often yes, and that's fine. It's different once it's business-critical — if a mistake only surfaces three months later, if several people work with it, or if it still needs to run in five years. Then it's no longer about writing code, but about structure, testing, documentation and someone being accountable.
That's exactly why we work with fixed standards. The structure is predictable, the code is documented and how it works is recorded. Another developer can pick up where we leave off.
We are. AI is a tool, not a supplier: we remain responsible for the decisions made along the way, validation of the outcome and the final release. That accountability sits within the terms of the agreement — as with every project, we work under the NLdigital Terms 2025.
Put your problem to us — you'll hear what's possible and roughly what it costs.