The pitfalls to avoid when having custom software developed
Having a tool developed for you means ordering something that doesn't exist yet. The four points that follow are the ones we'd have liked to be told before starting, whether you work with us or with someone else.
In this article4 sections
The real signal is the Excel file everyone emails around
Nobody decides one day that they need custom software. It starts with a shared spreadsheet, then a second one, then a chat group carrying the information the official tool can't hold.
Everyone has their own version, nobody has the full picture, and the same information is entered three times. The need isn't technical: it's that the way you work doesn't fit into any off-the-shelf software.
The corollary is worth stating before pricing anything: custom work is only justified where the way you work is an advantage, not a habit. Often the answer is a properly configured off-the-shelf software.
The platform is decided too early, and can't be undone afterwards
"We need an app" is a conclusion, not a need. When you need the camera, continuous location, offline use in the field or notifications at the right moment, a mobile app is the only choice.
When you need a catalogue, a client area or case tracking, the web does the same thing for a fraction of the price, and Apple explicitly rejects apps that merely reproduce a website.
And if both mobile platforms are needed, they're two separate worlds: built separately, that's twice the maintenance for users who see no difference.
A badly built tool locks you in more than off-the-shelf software
Off-the-shelf software can, at worst, be replaced: other providers know it. A tool written for you can't: if it isn't documented, if it runs on accounts opened in its author's name, if nobody else has ever reviewed it, then you didn't buy it, you rented it for life.
The test comes down to one question, and it's worth asking before signing: if you changed provider next month, how long would the next one take to understand your tool?
- Is the code handed over to you, and in what form?
- Are the accounts and access in your company's name?
- Is deployment documented somewhere other than in its author's head?
A tool isn't delivered, it's maintained
Software nobody touches for two years isn't stable: it drifts. Libraries age, certificates expire, privacy rules change.
On mobile it's explicit: Apple and Google publish a major version every year and require apps to keep up, or they can no longer be distributed to new devices. On the web it's silent, which is worse.
So the cost of a custom tool can't be read on the first invoice. The question to ask before starting isn't "how much does the development cost", it's "how much does the following year cost".
None of these four points is technical, and that's exactly what makes them easy to put off. Three of them can't be undone once the project is under way: settling them before starting costs only a conversation.
Ce sujet touche à notre expertise Custom software & apps.
We start with a conversation, not a quote.
Voir l'expertiseRead next