Software should fit the business, not the business the software

Choosing a standard tool is almost always a good decision at the start. A CRM, an ERP or a content management system sums up the way most companies in a sector work. You can sign up in an afternoon, they cost little and they handle the usual cases.

The problem shows up later, and almost never all at once. A standard tool works as long as your processes are standard. When your business starts doing things its own way (and every growing company ends up doing so), the tool keeps working exactly as it did on day one. You’re the one who changes.

The moment it stops fitting

Nobody decides one day that the tool no longer works. What happens is that the team starts working around it:

• A parallel spreadsheet appears to hold up the part of the process the tool doesn’t understand.
• The same data is entered two or three times, in different places, and each copy tells a different story.
• Custom fields get used for things they aren’t, because there’s nowhere else to store them.
• Reports are prepared by hand every week, copying from one system to another.
• The team changes the way it works so the tool won’t complain.

None of these seems serious on its own. Together, they’re the sign that the company is already adapting to the tool, not the other way round.

What forcing the fit costs

The cost of forcing a company into a tool doesn’t appear on any invoice. It shows up elsewhere:

• Friction. Every task has a workaround. The team knows it and accepts it, but the workaround is repeated hundreds of times.
• Manual work. What the tool doesn’t do, a person does: copying, reconciling, checking, chasing.
• Duplicated data. When information lives in several places, nobody knows which one is right. And deciding with data nobody trusts is deciding blind.

Worst of all, these costs grow with the business. The more you sell, the more workarounds, copies and hours of manual work.

Three systems where the process was in charge

Here are three cases where the company’s real process didn’t fit a standard tool, and where the answer was to build around it.

Gustela CRM: a sales process with its own rules

Selling Gustela meant prospecting restaurants at scale: finding them from public sources, contacting them in batched campaigns with a daily limit and respecting every contact’s opt-outs and rejections without exception.

A generic CRM forces you to adapt that process to its model. Exactly what was specific (the sources, the send queue and compliance) was what it would handle worst. So a CRM of its own was built, in which exclusion is applied on the server before anything is queued: nobody who has opted out, bounced or been marked “do not contact” can get back into the queue, and that doesn’t depend on anyone remembering.

Zentia: several agencies, one core

A real-estate agency needs a catalogue, search, lead capture, follow-up, languages and administration. The usual option is to build a website for each agency. The problem is that multiplies the code, the maintenance and every improvement.

Zentia does the opposite: one core that becomes many platforms. Each agency arrives through its own domain, sees its own brand and works only with its own data, isolated in the database itself. Branding is configuration, not code: a new agency doesn’t need a new product.

Zentia case study: a real-estate platform for several agencies

Rocio.com: when the tool no longer represents the content

Rocio.com has an editorial archive that goes back to 1992. Everything lived in a WordPress site around 15 years old, which stored almost everything as text key-value pairs: 320,093 rows of metadata for what fits in about fifteen columns per entity, and dates stored as text.

The content existed, but it was trapped. The tool had stopped representing what the company had. The solution was a normalised data model, a custom editorial panel and redirects from every old URL, without losing content or links.

Rocio.com case study: from a legacy WordPress site to a platform of its own

This isn’t an argument against standard tools

Most companies’ accounting, payroll, email or invoicing are standard processes, and they’re better served by a good product than by custom development. Building that custom would be expensive and add nothing.

The question isn’t “standard or custom”. The question is where what sets you apart lies. If the way you sell, operate or decide is your own, that’s exactly the part a generic tool handles worst. That’s where building makes sense. For everything else, the sensible thing is to use what already exists and connect it.

Sometimes nothing even needs replacing: often the best option is to integrate what already works and build only the missing piece.

How to tell which side you’re on

Before deciding, it’s worth answering a few questions honestly:

• Which part of the real work happens outside the tool, in spreadsheets, emails or notes?
• How many times is the same data entered, and in how many places?
• Which reports are prepared by hand, and how long do they take?
• Is your process the same as your competitors’, or is it part of what makes you different?
• If the tool disappeared tomorrow, what would you miss and what wouldn’t you?

If the answers point to a process of your own and lots of work around the tool, the problem is no longer the tool. It’s the fit.

If what you’ve outgrown is the CRM, I go into it in when a custom CRM makes sense and when it doesn’t. If it’s a spreadsheet that has become a system, what’s usually needed is a custom web application that fixes that specific bottleneck.

Technology should fit your business. Not your business the technology.

In for businesses I explain when building makes sense and when it doesn’t, and in custom software development which platforms, internal tools and CRMs I build.