Custom software development from Hamburg.

Most problems are solved better and more cheaply by off-the-shelf software than I could ever manage. Rebuilding an ERP system because the one you bought is awkward in two places is nearly always an expensive mistake. So every conversation starts with whether anything needs building at all.

Custom work gets interesting where your process genuinely differs from everyone else's — usually exactly where your money is made. Those are the places where standard software forces you to bend a working process to fit a form. And they are the places where a gap opens between two purchased systems that a person currently bridges by copying and pasting.

If you are not sure which category your problem falls into: working that out is part of the job, not homework you owe me before the first call.

The focus is software that gets used internally and therefore rarely needs to look beautiful, but does need to work every day: tools for your own people, portals for your customers, and the connections in between.

• Web applications, internal tools and portals
• APIs and interfaces between the systems you run
• Architecture consulting, code reviews, second opinions
• Modernising what exists instead of rebuilding it expensively
• Tests, documentation and a deployment you operate yourself

Old software has a bad reputation it often has not earned. A system that has run for ten years has spent ten years learning edge cases that appear in no requirements document. A rewrite starts from zero — and rediscovers those edge cases one at a time, in production, usually at the worst possible moment.

Before I talk about replacement, I look at what actually hurts. Often it is not the core but the edges: an outdated library with known holes, a deployment only one person can perform, missing tests, a data model that has survived three redesigns. That can be straightened out in stages while the business keeps running.

Sometimes a rewrite really is the right answer. Then I say so with reasons — and with a path that does not require you to stand still for two years.

Every one to two weeks there is something finished to try, rather than months of silence followed by one large release. That is not a methodology preference, it is risk management: the sooner you can use something, the sooner it shows that we understood a requirement differently.

Automated tests go around the parts that hurt when they break. Deployments run at the push of a button, not from instructions in one person's head. Documentation is written from day one, not at the end when nobody remembers why a decision was made. This practice comes from working in large-company engineering and does not change for small projects — there it is simply finished faster.

The code is yours. So is documentation and a handover in which someone on your team, or another contractor, can genuinely pick the work up without starting from scratch.

That is explicitly the goal: that you can run the thing without me. Depending on your developer is a risk for you, and it is not a business model I would enjoy.