Custom internal tools
Software shaped around how you work.
Off-the-shelf software covers the common cases. The work that makes your business different often ends up in a shared spreadsheet, a pile of emails or someone's notes. Sometimes the right answer is a small tool built for exactly that work, and nothing more.
What I do
Desktop tools
Windows applications for data entry, checks and approvals, built with WPF for the people who use them every day.
From spreadsheet to database
A shared spreadsheet replaced by a SQL Server database with a simple interface, with Excel kept for reports where it helps.
Admin tools
Small tools for the jobs your main software doesn't handle, working with its data where the vendor supports that.
Checks built in
Validation at the point of entry, so mistakes are caught when they are made, not at the end of the month.
Ready for the next developer
Plain, documented code in your source control, so you're not tied to me.
Build, buy or keep the spreadsheet?
| Situation | What usually makes sense |
|---|---|
| A good product exists and fits most of your process | Buy it, and connect it to the rest |
| The spreadsheet works, but the manual steps hurt | Keep it and automate the steps |
| Several people edit the same data and errors creep in | A small database with a simple interface |
| The process is specific to your business and stable | A custom tool built for exactly that |
| Nobody is sure yet how the process should work | Settle the process first, build later |
If an existing product would do the job, I'll tell you. Building software only makes sense when it's clearly the better option.
How a tool usually gets built
Sit with the users
See how the work is done today and what gets in the way.
Agree the first version
A written proposal: what the first version does, what it doesn't, and what it costs.
Build in small steps
Working versions to try early, adjusted to how people actually work.
Test with real data
The people who will use the tool try it on real cases before it goes live.
Hand over
An installer, documentation and a walkthrough for the people who use it.
Questions about this
Can it be a web application instead?
My focus is Windows desktop tools and databases. If you need a web application, mention it, and I'll tell you honestly whether I'm the right person.
What if our process changes later?
The tool is built to be changed: plain code, a documented database and no unusual dependencies. Later changes are a normal part of the work, whether I make them or another developer does.
Can the tool work with the software we already use?
Usually, through its API, its exports or its database, where the vendor supports that. I check what is possible before proposing anything.
How is it installed and updated?
Usually with a standard Windows installer and a simple way to roll out new versions. We agree the details for your setup in the proposal.