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.

Maurice Moreillon, UX Designer & Project Manager · Head of Bachata23 septembre 2026 · 3 min de lecture
In this article4 sections
  1. The real signal is the Excel file everyone emails around
  2. The platform is decided too early, and can't be undone afterwards
  3. A badly built tool locks you in more than off-the-shelf software
  4. A tool isn't delivered, it's maintained

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'expertise

Read next

Training your teams in AI: what's left three months laterEveryone comes out of a training day motivated. It's what happens in the following weeks that decides whether it was any use.Guidance3 minBringing in reinforcements on a running project: what the hourly rate doesn't tell youThe daily rate is the part of the price you can compare. The rest (ramp-up, reviews, what leaves with the person) can't be compared, and often weighs more.Guidance3 min