Services
Four things I'm good at — and one path they all take
Almost everything I build starts as a sentence from someone who knows their job well and notices that the tool is slowing them down. My job is to translate that sentence into something that works tomorrow morning.
01 · Custom software
When the standard product doesn't know the step that matters
There is software to buy for almost everything. And for most cases that is exactly right. But there is always a remainder: the step only your business does this way, because your customers, your production line or your industry demand it.
That remainder is what I build applications for. Not as a replacement for your system, but as the piece that fits alongside it — usually considerably smaller than you'd first think, because a good share of the wish list turns out to be “the existing system has done that for years, nobody knew”.
- typically
- data entry and validation screens, reports, internal tools, line-of-business applications for one clearly bounded process
- you get
- an application that does exactly what was agreed — documented, handover-ready, extensible
- tools
- C# / .NET, SQL, web front ends without the framework circus where it fits
- not suitable for
- “we'd like something like SAP, but cheaper.” There I'd rather say no honestly.
02 · Interfaces & integration
Two systems, one record, no retyping
The most common time sink in an IT landscape that has grown over the years is not a missing program. It's the people sitting between two programs, carrying data from left to right.
That's where I start: inventory management and document management, ERP and production, database and reporting, online shop and warehouse. Where an interface exists, I use it. Where none exists, I build one — and one that still reacts sensibly when the network was gone for three minutes.
- typically
- data transfer between systems, import and export, REST connections, document and master data synchronisation, archiving
- watch out for
- repeatability, logging, failure cases. An interface without a log is a time bomb with a calendar entry.
- tools
- REST / JSON, SQL Server and PostgreSQL, CSV and XML formats, scheduled services
- side effect
- It almost always emerges that two departments call the same number by different names. Sorting that out is half the work.
03 · Automation
Describe it thoroughly once instead of doing it a hundred times
Every routine a person performs identically every Monday is a candidate. Not because people should be replaced, but because people are needed for the cases that are not identical every Monday.
One thing matters here: automation without oversight is just a faster route to the mistake. So every automated process I build comes with a traceable record — who triggered what and when, what came out of it, and what happens when it goes wrong.
- typically
- recurring reports, automatic document and report distribution, plausibility checks, background data maintenance
- you get
- a process that runs by itself and speaks up when it can't
- rule of thumb
- Worth it from roughly the tenth repetition. Before that, doing it by hand is often simply cheaper — and I'll tell you so.
04 · Support & further development
The part nobody puts in the quote
Software doesn't get finished, it grows up. Laws change, processes shift, colleagues come and go, and eventually somebody asks: “couldn't it also …?”
I stay reachable for what I've built. Analysing faults, following up with adjustments, keeping documentation current, bringing successors up to speed. It's unspectacular, and it is exactly why solutions are still in use three years later.
- typically
- troubleshooting and fixes, extensions, adapting to new requirements, handover to colleagues
- always included
- documentation in plain language, not just comments in the source code
- the goal
- that the solution keeps running even when I'm not around
How it runs
Six steps, always the same ones
The scope varies between two days and several months. The order doesn't.
Listen
I have the process shown to me as it really is — including every exception that “basically never happens” and then turns up every Tuesday.
Draw the line
What does this project solve, and what does it explicitly not? A clearly drawn boundary is the most effective remedy against projects that never end.
Design
Data model, process flow, interfaces, permissions. This is where it gets unromantic — and where it's decided whether the solution still holds up in two years.
Build
In small sections with presentable intermediate results. You see something clickable early instead of a concept document late that nobody has read.
Verify
With real data and the people who will work with it later. They find things in an hour that I wouldn't reach in a week.
Accompany
Training, documentation, a watchful eye during the first few weeks. Then hand over — but don't disappear.
Working together
What I need from you
Very little, but reliably: one person who genuinely knows the process and is reachable. No requirements document, no preparation, no technical vocabulary. Learning your domain language is my job.
What also helps is permission to ask awkward questions. The most interesting finding in one project was that a daily report had been produced for four years and read by nobody.
How and where
- role
- employed application developer — projects run through my employer
- languages
- German (native), English for technical work and documentation
- ways of working
- remote and on site, whichever the project needs
- first step
- a conversation, about half an hour, no strings attached
Describe the process that irritates you
Two or three sentences are enough to start. Nobody will tell you more honestly whether software is worth it than someone who also advises against it.