From sheet to database
The same calculations and business rules, but in a database that can handle simultaneous use.
Has your Excel file outgrown what it was designed for — too many users, too much data, or too much risk of a cell being overwritten by mistake? Then we build the same logic as a web application, with a database behind it.
Do several people need to work with the same data, is the volume of data making a workbook slow, or does your process call for specific user permissions? Then we first look at which set-up fits: a shared workbook, Excel with a central database, or a web application. The number of users alone doesn't decide that; see working with multiple users in Excel at the same time. A web application with a database is the right fit when people need to work in a browser, or when roles and permissions matter more than Excel can comfortably carry, without losing the calculation logic you're used to.
The same calculations and business rules, but in a database that can handle simultaneous use.
Different roles and permissions per user, instead of one shared file for everyone.
Connections with the systems your organisation already uses, such as accounting or CRM software.
No. It's often sensible to start with the part that creates the greatest risk or constraint, and build on from there.
What you receive. Every delivery includes a working application, documentation of how it is put together, the test cases it was checked against, and a setup the next developer can take over. That is part of delivery, not extra work billed afterwards.
What you may do with it. The application is built to be used in your organisation, and that is what you may use it for; with a custom web application that is called a right of use. With Excel and VBA it works out differently in practice, because the code sits inside the file itself: you receive that file, and we deliver the VBA project without a password on it. Whatever else was agreed is in the assignment.
Who holds the rights. Under the NLdigital Terms 2025 the intellectual property rights stay with the supplier unless something else is agreed in writing. If you want those rights, or the source code, transferred to you, that is a separate written agreement - the same for both kinds of work.
Your data is a different matter from the code. It is yours and it stays yours. How you get at it yourself - an export, a direct connection to the database, or something else - is agreed per application.
The scope: how many screens, roles and business rules the application needs, the number of data sources, the integrations with existing systems, and how much of the calculation logic in your current Excel file can be carried over. We put figures to it after reviewing your requirements, in a no-obligation quote.
Through one point of contact. Changes, questions and faults do not get passed from one person to the next: you report them in one place and they are picked up there.
Exactly how that is arranged we agree per assignment. Some applications run for years without needing anything; others evolve with the process they support. For business-critical applications we record the arrangement in a maintenance agreement, so that it does not depend on who happens to have time.
A service level agreement can be part of that. What goes into it depends on what the application does and on what a day of downtime costs you. So there is no standard package that applies to every application; we agree together which arrangements suit yours and record them in the maintenance agreement.
Briefly describe what you're dealing with, and Dennis will reply within one working day. The whole project can run in English, from the first conversation to the documentation and support.