// Software Development · Build
Custom software development
When a process refuses to fit into any finished product, we build the application that fits it — and hand it over in a way that leaves you free to work with anyone.
// The trigger
Only once the shape stops fitting
Standard software handles most tasks in a company perfectly well, and where it does, it should be used. A custom application becomes interesting at the point where a process is so specific that every finished product covers about two thirds of it — and the remaining third ends up in spreadsheets, email threads and shouted questions across the office.
That last third is what costs time and produces mistakes. So we look at the process first and the technology afterwards: who enters what, who checks it, where numbers get copied by hand, and which supposed exception actually turns up every week.
What comes out of that is rarely a large platform. More often it is a modest application that does one thing properly and talks to the systems already running in the building.
// The decision
Finished product or your own application?
Both are legitimate. The only question is who adapts in the end: the software to your process, or your process to the software.
Carries most of the work
- Functions already exist and can be used immediately
- Maintenance, updates and security sit with the vendor
- Your process has to bend into the shape provided
- Special cases get handled beside it, usually in a spreadsheet
Carries what makes you different
- The application follows your process rather than the other way round
- Only the functions that genuinely get used
- Interfaces to your existing systems from the first version
- You decide what gets built next, not a product roadmap
// Use cases
What companies have us build
Three shapes that keep recurring in mid-sized businesses.
Your process as a screen
Order intake, checks, approvals: a form that asks the questions your process asks — instead of the ones a foreign data model happens to require.
Access for clients and partners
A protected area where customers, suppliers or field staff see exactly the data meant for them. Attachments by email stop being necessary.
Work nobody types any more
Recurring transfers, reports and notifications run in the background. People deal with the cases that need a decision.
// Approach
How an application takes shape with us
Four stages, of which the first saves the most time.
Follow the process
We walk through the whole procedure once and talk to the people who do it daily. What gets written down is what really happens — not what the handbook claims.
Fix the scope
From that comes a shape: what belongs in the first version, what is a wish, what an existing system already handles. Starting small avoids expensive demolition later.
Deliver in stages
You get something usable early and can object while changes are still cheap. Every stage ships with tests and documentation.
Operation and further work
Source code, accounts and documentation go to you. Whether we keep maintaining it or your team takes over is then a decision — not a technical constraint.
// Warning signs
How you notice that standard software has run out
If two of these sound familiar, a conversation is probably worth an hour.
-
One spreadsheet holds the business together
There is that one file everyone needs, nobody may lock, and only a single person genuinely understands.
-
The same figure gets entered twice
Quotation, order and invoice live in separate systems, and somebody retypes the numbers in between.
-
The product can do it — just differently
You pay for software whose intended route your team works around every day so the job actually gets done.
-
A simple question takes days
To find out how many orders are still open, somebody has to collect data from several sources and then check it.
// Questions about development
What directors want to know before the first meeting
01 When is building your own software actually worth it?
When the process in question is part of what your company sells, and no finished product covers it without detours. If it is a side task, we say so and recommend a standard product — even though we earn nothing from that answer.
02 Do we own the source code?
Yes. Source code, repository and accounts sit with you. We document to the standard where another development team could carry on without asking us anything. A dependency that rests on somebody not knowing something is not client loyalty.
03 Can the application talk to the systems we already run?
In most cases yes. Where an interface exists we use it; where none exists we establish in advance which route is technically and contractually permitted. Our page on system integration goes into how that works.
04 How soon do we see something we can use?
That depends on the scope, and we deliberately keep the first slice small. An application nobody sees for many months regularly misses the reality it was meant to serve, so we deliver in stages you can try out in a normal working week.
05 What happens after the launch?
Software ages: dependencies need updates, processes change, new wishes arrive. We offer maintenance and further development, but we do not tie you to it — handing the work to another team has to stay possible at any time.
06 Will you work on an application somebody else wrote?
Yes. Often the job is to replace something inherited, add a missing function or make an application maintainable again. We look at what is there and say honestly whether extending or replacing costs less.
Related
All IT services
Tell us about the process that keeps holding you up.
We listen, ask the awkward questions and then say whether a custom application makes sense — or whether a system you already own could do the job.