The spreadsheet that grew out of hand becomes an application you can rely on
We build what your business actually needs. Afterwards, someone who knows the application stays on and keeps developing it.
Book an intro callAlmost every business has that one file. It is called something like order_list_2024_final_new.xlsx, it sits on a network drive, and only one person is allowed to open it because otherwise the formulas break. Inside are prices, deadlines, responsibilities, half-finished calculations. Whoever built it has either retired or is on holiday. And nobody dares change a thing.
Files like that are what we replace. Sometimes completely, with an application that has user accounts, permissions and a database behind it. Sometimes only halfway, because part of the number crunching is perfectly well served by Excel. Then there is the work at the joins: stock control and accounting rarely talk to each other on their own, so we write the interfaces. Whatever runs afterwards, we keep looking after.
What is included.
Line-of-business applications
We build applications for processes that no off-the-shelf product covers: inspection records, property files, materials planning. That includes user accounts, permissions, a database and an interface that someone who never had any training can still operate.
Interfaces between systems
Two programs, the same customers, two sets of data. We connect them through APIs, file imports or database access, log every synchronisation, and build in an alert that reports when a transfer stalls overnight.
Moving off Excel
First we read the spreadsheet, every sheet, the hidden ones included, macros and all. Then we separate things out: what belongs in a database, and what stays a calculation aid. Only after that does development start. The old data comes across with it.
A look at the market before we build
Before anything gets built, we check what already exists. For time recording, stock control or ticketing there are off-the-shelf products that come to less than a bespoke build. If one of them fits, we say so and set it up.
Maintenance and further development
After launch, forms change, tax rates change, responsibilities move. We take on changes like that, keep the libraries in use up to date, check the database backups, and fix the faults that show up in daily work.
Source code and documentation
The source code sits in a repository you can log into. Alongside it we write down how the application is put together and how a fresh installation is built. Another developer can pick it up from there.
How we work.
Sitting in on the actual work
We sit down next to the people who do the job every day and watch. Which file gets opened, what gets retyped, where the waiting happens. That record becomes the list of requirements.
Scope and quotation
You get it in writing: what will be built, what is deliberately left out, and in which order the parts come into being. The first release is deliberately small, so that something usable is on the table early.
Development in stages
Every few weeks a version is ready for you to try out. Your feedback goes into the next stage. In parallel we take over the legacy data and let the old and the new solution run side by side for a while.
Running it and looking after it
The application is live, and we stay your point of contact for it. Change requests we collect and work through in batches; faults are dealt with sooner. If you want to hand the support to someone else, we pass over source code, access credentials and documentation in full.
Common questions.
I cannot say today what the whole thing should cost in the end. How do you handle that?
Scope is what decides, not the technology. So we cut the project into stages and start with the part that saves the most manual work. After that first stage you can judge whether the rest is worth it, and you can stop at any point. You get a quotation only once we have seen the process, not after a phone call.
Our Excel file has grown over twelve years. Can something like that be replaced at all?
Yes, though rarely in one move. First we read every sheet and every macro and work out which rules are actually applied and which are only there for historical reasons. Often a good part of the file is dead. The rest is translated into tables and rules, the legacy data comes across, and the file stays open alongside for comparison during the first few weeks.
If you build this application, does that not tie us to you for good?
The source code belongs to you and sits in a repository you have access to. We use widely known technology rather than home-grown constructions, so that another developer can read their way in. Added to that is a description of how the application is set up again from scratch. Whether you stay should come down to the work, not to nobody else being able to make sense of it.
You are a small provider. What becomes of our software if one day you can no longer carry on?
That is exactly why the source code, the access credentials and the documentation sit in your own hands. We build with common tools that plenty of developers know. What speaks for us: you talk directly to the person who wrote the application, with no ticket system in between. You can see what that looks like on this website, which we planned, wrote and built ourselves.
Our stock management system is old and the vendor says there is no interface. Is anything possible even so?
Usually yes. Where no documented interface exists, we go via export files, database access with a read-only account, or a folder that both systems write into. It is inelegant, but it works. Beforehand we go through the licensing position with you, because some vendors prohibit direct database access, and in that case we advise against it rather than doing it quietly.
Show us your worst spreadsheet
Send us the file, or describe the process that costs you the most time. We will go through it step by step and tell you whether development is worth it or a finished product will do.
Book an intro call