Skip to main content
Updated September 2026

Guide

Building custom business software for an SME: a practical guide

Custom business software is not a product you buy, it is a project you run. The difference between software the team opens every morning and software nobody touches is not the technology — it is three decisions taken before any code is written: which scope to cover, which method to follow, and who is accountable for the data. This guide puts those decisions in the order an Italian SME meets them, with the figures and the documents needed to settle each one.

What drives the cost, line by line

Functional scope

How many processes the software covers. A single module — orders from the dining room to the kitchen, a property register, access control — costs a fraction of a platform spanning sales, inventory and administration.

Integration with existing systems

Every system to connect — accounting suite, e-commerce, industry portals, machinery — adds analysis, development and testing. Integrations over documented APIs cost less than those over proprietary formats or hand-exported files.

Migrating historical data

Bringing in years of spreadsheets requires cleaning, reconciliation and quality checks. It is the line item most often forgotten at quoting time, and the one that most often stretches the schedule.

Roles and permissions

An application with a single user profile is simpler than one separating operator, manager and administrator, each with their own views and authorisations. Permissions are application logic, not a checkbox.

Context of use and devices

A desk interface costs less than one used standing up, with gloves on, or on a tablet in the warehouse. Where and how people work is a technical requirement, not a cosmetic detail.

Ongoing development

After go-live there are fixes, technology updates and new features. Budget it as a recurring line and put it in the contract with defined response times, rather than treating it as a surprise.

Standard or custom: the decision upstream

Before planning a build, check that you need one. If your administrative and logistics processes follow industry practice, a standard ERP covers breadth and keeps compliance current for you. Custom makes sense when the process that generates your margin is also the one no suite models, or when the customisations you would ask the vendor for cost more than the value they bring. The full comparison, dimension by dimension, is in a dedicated guide.

What it costs and how long it takes

The ranges we publish, VAT excluded. A first custom module runs €5,000–€12,000, with go-live in 8–10 weeks. Automation between systems you already own starts lower: €2,000–€6,000 in 3–5 weeks for an automation package, €3,000–€7,000 in 4–6 weeks for integrations. A custom B2B portal sits between €8,000 and €18,000 one-off. A full platform spanning several areas — sales, inventory, administration and the accounting integration — typically runs €20,000–€50,000 depending on the sector. If you prefer day rates, ours are published: €48–€60 per hour and €384–€480 per day, which puts a first module in the order of 12–30 development days. The final figure comes from a free analysis of your process and the tools already in use, not from a price list.

How to plan the project, step by step

Custom business software is built in increments: start with the process that weighs most, release, measure, extend. This sequence is also what lets you stop after the first module if the numbers do not add up.

  1. Map the manual processes. List the activities that today run through spreadsheets, email and re-typing, with how many people perform them and how many hours they absorb each week. That list is the basis for both the scope and the return calculation.
  2. Pick the first module. Take the process with the highest ratio of time lost to technical complexity: it delivers a measurable result in weeks and funds the steps that follow.
  3. Fix the scope in writing. State what the first release does and, above all, what it does not. Excluded features go on a separate list rather than being dropped: that list becomes the roadmap.
  4. Have a clickable prototype validated. The key screens should be seen and corrected by the people who will use them before development, when a change costs hours instead of weeks.
  5. Work in sprints with interim demos. Short cycles with a working demo at the end of each: that is how a wrong requirement surfaces while fixing it is still cheap.
  6. Check the incentives before signing. Some Italian schemes — Transizione 5.0, Nuova Sabatini, regional calls — cover part of a software investment, but the paperwork has to start before the order, not once the work is done.

The software is for the people using it, not the people signing for it

Jakob Nielsen has been making the point for decades: enterprise software is almost always designed to satisfy the buyer, not the user. It is the most common way to waste a project — the specification is met, acceptance testing passes, and the staff keep their parallel spreadsheet because it is quicker. Four habits reduce the risk.

Listen to whoever will use it, not only whoever approves it

Run the initial interviews with the people who perform the process daily. They are the ones who know the exceptions, and it is the exceptions that break requirements written in a meeting room.

Count the steps on repetitive actions

An operation performed two hundred times a day has to fit in a minimum number of clicks. The time to complete the three most frequent actions is a measurable requirement, to be verified at acceptance alongside the features.

Respect the company's own vocabulary

If the warehouse says "bolla" and not "delivery note", the label in the software says "bolla". Translating internal jargon into textbook terminology moves the cost onto training every new hire.

Open a feedback channel after go-live

The first two weeks of real use reveal more usability problems than any acceptance test. Collect them in one channel and queue them with the other priorities, rather than handling them verbally in the corridor.

Data security and compliance: what belongs in the contract

Handing custom software development to an outside supplier means giving them access to personal data about employees, customers and suppliers. Under the GDPR your company remains the controller and the supplier becomes a processor: the relationship has to be governed in writing and the security measures have to be verified, not assumed. Six things to ask any supplier, us included.

Processor appointment (Art. 28)

A written instrument listing purposes, categories of data, duration, the instructions given and confidentiality obligations. Without that document the arrangement is not compliant, however solid the supplier is.

Stated technical measures (Art. 32)

Encryption in transit and at rest, access assigned by role, development and test environments separated from production, backups with documented restore tests, access logging.

List of sub-processors

Every third-party service involved — hosting, mail, monitoring, development tooling — has to be declared along with where it processes data. It is the information most often missing from proposals.

Place of processing

Knowing which country holds the data and the backups. Transfers outside the European Economic Area require the standard contractual clauses approved by the European Commission.

Breach procedure (Art. 33)

Who notifies whom, within what deadline and with what information. Notification to the supervisory authority is due within 72 hours of becoming aware of a breach: agree the communication chain beforehand, not during.

Code ownership and exit plan

Who owns the source code and the data, where the repositories live and how they are handed back at the end of the relationship. It is the clause that makes every other choice reversible.

How we answer those six points

Nesso Labs is an Italian company based in Brescia: the contract, the invoicing and the processor appointment all stay under Italian and EU jurisdiction. Our information security management system is certified to ISO/IEC 27001, with the ISO/IEC 27017 and ISO/IEC 27018 extensions for cloud services and for personal data in the cloud: access assigned by role, development, test and production environments kept separate, tracked credential management, defined incident response procedures and recurring audits, with the resulting evidence available during due diligence. The source code is yours, in your repository, with access defined together: if you later choose to bring development in-house or change supplier, the handover is planned rather than negotiated. For data protection enquiries, the address is [email protected].

Frequently asked questions

A first custom module runs €5,000–€12,000, with go-live in 8–10 weeks; a platform covering several business areas typically runs €20,000–€50,000. The variable is not company size but scope: how many processes are covered, how many existing systems have to be integrated, and how much historical data has to be migrated. On a day-rate basis, our published rates are €384–€480, VAT excluded.

Ready to kick off the digital transformation of your business?

Talk directly with our technical lead.