Omnia Leads Manager: the custom CRM that replaced three Excel sheets

Project summary

Sector

Electronics, sales network across three countries

Client

Company with sales divisions in Italy, Spain and the United States

Users

Sales reps from the three divisions, managers, administrator

First version

18 to 24 June 2025, live the same month

Overhaul

June 2026: security, performance and a new interface (version 2.3.5)

Size

About ten screens, three languages, notifications and scheduled jobs

Running costs

Free or basic plans for hosting, database and email: no per-user licence

Way of working

Fixed-price project, with later work billed by time spent

The context: three divisions, three spreadsheets, no overall view

Leads came in from trade fairs, from the website, from referrals and from campaigns, and ended up in one spreadsheet per division. Each sheet had slightly different columns, dates written in different formats, and a single owner who knew how to read it. Nobody could answer the question "how many open contacts do we have in Spain and who is following them".

The client had already looked at off-the-shelf CRMs. The problem was not the entry price, it was the per-user cost across three countries, the effort of bending a general-purpose product to a process that was already clear, and above all the import: years of contacts sat in sheets with sixteen columns and local formats, and no standard importer would take them without a manual clean-up that nobody was going to do.

What they actually needed, and what an off-the-shelf CRM would have given

The last row is the one that decides it: if the client had needed complex pipelines, integrated telephony and marketing automation, an off-the-shelf CRM would have been the right choice and we would have said so. What they needed instead was one tidy place, in three languages, that accepted their files. This is the typical case where going custom pays off.

The solution: a small system, done properly

Omnia Leads Manager does a few things: it takes in contacts, imports them from the spreadsheets, lets people search and filter them, alerts whoever needs alerting and remembers the follow-ups. Every feature was picked because the client was already doing it by hand.

Access and roles

Whoever registers does not get in straight away: the administrator approves the account and assigns it to a division. Three roles (user, manager, administrator) decide who can see, who can edit and who can delete. A lead can be edited by whoever created it or by a manager; reading is shared, because the whole point of the project was to stop having information locked inside a file.

The spreadsheet import, the part that made the difference

The importer was built around the real format of the client's sheets: sixteen columns, with dates that in one file were Excel numbers and in another plain text. Before it writes a single row it checks the file type from the first bytes rather than from the extension, limits the size, converts the dates and sets the unreadable ones to NULL instead of blocking everything, spots duplicates by company and contact name, writes in batches and at the end sends a summary with the errors row by row.

Search, filters and dashboard

The lead list can be searched and filtered by division, channel, sector and follow-up status, with sorting and pagination done by the database and not in memory: with a few thousand rows the difference is between a page that answers straight away and one that freezes. The dashboard shows contacts by conversion status and by channel, plus the figures on follow-ups coming due.

The notifications that replace remembering

Four kinds of email, with templates the administrator can edit in three languages: new lead assigned, import completed, monthly follow-up reminder per division, account approved or rejected. The emails go through a queue and a scheduled job that sends them, so a problem at the mail service does not lose the message. A daily report sums up the activity.

The technical decisions

For a system used by a few dozen people, the most important choice is how much it costs to keep running and how easy it will be to work on in a year. All the decisions point that way.

1. No frontend framework HTML pages, JavaScript modules and Bootstrap. For ten screens and a team that was not going to have an in-house developer, a framework would have added a build chain to maintain and given nothing back. The code can be read and changed with a text editor.
2. Serverless functions and a serverless database Pay per use functions and database: you pay for what you use, which for this system stays inside the basic plans. No server to patch, no nights spent checking it is still up. Scheduled jobs, such as sending the queued emails and the daily report, run on the same infrastructure.
3. Three languages from day one The interface, the emails and the date and number formats follow the user's preferred language, falling back to Italian for missing keys. Adding them later would have meant touching every screen twice.
4. The client's process lives in the code, not in habits Who can change what, which fields are required, how a duplicate is recognised, when a reminder goes out: these are rules written into the functions, the same for every division. That is why a file from Spain and one from Italy end up in the same shape.

A year on: the security and performance review

In June 2026 the system was gone over from scratch, with a multi-pass security review and a performance check. It is the part of the case study we tell most willingly, because a year-old piece of software with nothing to fix has usually not been looked at.

• Authentication: removed a fallback login path that could be abused; authentication now required on every function; a limit on login attempts, with messages that do not reveal whether an email exists; sessions invalidated when the password changes.
• Data ownership: editing and deleting a lead restricted to whoever created it or to a manager, with the author taken from the session and not from the form.
• Email: the sending functions could be reached without a session and could be used to send email to third parties; they now require an internal token or an administrator session. Email content is always encoded, subjects protected against header injection.
• Security headers: content policy, HSTS, browser permissions, CORS restricted to the site domain.
• Performance: filters, sorting and pagination moved into the database; import without one query per row; user counts in a single aggregate query; indexes on the most searched columns.
• Traceability: a table of administrative actions as an audit log, automatic clean-up of login attempts after thirty days.

The results

The client has a single contact archive for three countries, an import that takes its files without manual clean-up and reminders that go out on their own. Running costs sit inside the basic plans for hosting, database and email, with no per-user licences.

1

week from the first line of code to the version in use (18 to 24 June 2025)

3

languages with local formats (Italian, English, Spanish)

16

fields imported from the existing sheets (with validation and duplicate checking)

0

per-user licences (running costs on basic service plans)

What carries over to a similar project

A custom CRM makes sense when the process is already clear and the existing data has a shape that off-the-shelf products will not take. In that case it costs less than people expect, as long as you do not rebuild what nobody needs.

• Start from importing the real data: if the system will not take today's files, it will not be used.
• Choose the infrastructure on what it costs to keep running, not on fashion: for a few dozen users, pay-per-use serverless is close to free.
• Put the languages and the roles in on day one, not in year two.
• Plan a review after the first year of use, and put it in the quote.

To see how a project like this is put together, from the costs to the phases, read how we work and what it costs. For an overview of what we do on this kind of system, see the custom software development page.

Technologies used

Choices made for a small system, used every day, with minimal running costs and no in-house developer on the client side.

Frequently asked questions

Written by Maximilian Giurastante

Founder and software developer, MAXYMIZE. Designs and builds SaaS platforms, custom business software and automations with language models. Over twenty years as a project leader in technology, audio and video systems integration.

• https://linkedin.com/in/maximiliangiurastante
• https://github.com/Maxymize
• https://youtube.com/@MAXYMIZE

Do you have contacts scattered across spreadsheets that nobody keeps in sync?

Bring us a sample file. In thirty minutes we will see whether a custom system makes sense or whether an off-the-shelf product suits you better, and we will tell you either way.

Book a free consultation