Anyone considering their own application has usually tried a few things already: spreadsheets, an extra program, perhaps an extension to the existing system. At some point that is no longer enough. And then come the doubts about whether custom software is really the right route.
We hear three questions again and again. This article answers them the way we do in conversation: without sales promises, and with a note on when a custom application is not the best solution.
Isn’t a standard product cheaper?
For many tasks, yes. Accounting, payroll, email or scheduling work much the same in almost every business. There are mature programs for these that are cheaper and available faster than any custom development. It would be unwise to develop them from scratch.
It is different for the part of your work that sets you apart from others: a particular way of pricing, an approval following your own rules, a process between sales, warehouse and customers that nobody else has in quite this form. A standard product often fits here only with workarounds. The cost of those workarounds appears on no invoice. It sits in duplicate entries, in follow-up questions and in lists that someone maintains next to the system.
That is why we first check whether configuration or a connection to existing software is enough. Only when it is not does a custom application pay off. Often the answer is a mix: standard for the usual, a custom application for what is special. There is more on this trade-off in the article Custom or off-the-shelf software.
Our process is too specialised. Can an outsider even understand it?
The concern is understandable. Anyone who has worked in a business for years knows exceptions, arrangements and tricks that are written down nowhere. How is someone from outside supposed to grasp all that in a few meetings?
The answer: not in a few meetings around a conference table, but at the workplace. We walk through a real order station by station with the people who handle it every day. That reveals what a flowchart never shows: where someone adds something by hand, where information is missing and where a rule exists only in a colleague’s head.
Processes like these are precisely the reason to develop a custom application. A workflow that fits every standard product does not need one. So it is normal that we do not know your process at the start. What matters is that we understand it before the first line of code is written, and that your team tests early versions on real work.
Won’t we become dependent on you?
You should ask every provider this question, and before you commission anything. Dependency rarely comes from the technology itself, but from missing agreements: who owns the source code? Who may change the software? Is there documentation another team could work with? And can your data be exported in a common format at any time?
We put these points in writing before development begins: source code handover, usage rights, documentation and data export. We clearly separate what is developed for you from the foundation we build on. ElbDesk has its own licence, which is also settled in advance.
Some attachment remains with any software, including standard products: nobody replaces a program they have used for years overnight. The difference is whether a switch is possible when you want one. More on this in the article Who owns your software?.
What is the best way to start?
With a small, clearly defined first step. Instead of describing the whole project at once, we agree together what the first version must be able to do and clarify scope, effort and open questions before you commission development. That way you see early on whether the collaboration works, and the next steps follow what proves itself in daily work.
If you would like to know what that could look like for you, get in touch. A first conversation usually already shows whether a custom application is the right route or whether an existing program with a connection is enough.
