Vai al contenuto

Custom business software and web applications

Custom only pays where off-the-shelf does not reach. The hard part is working out where that boundary sits.

In breve

Custom business software pays off when the process is your competitive advantage, or when no standard product covers it without distorting it. In every other case off-the-shelf costs less and ages better. Xion starts from analysing the process, builds a minimum working version within weeks and grows it in steps, rather than one release after months. The analysis is free.

First we check it does not already exist

Building what you could buy is the fastest way to spend badly. Custom has to be justified, not assumed.

In steps, with a result each time

A minimum working version within weeks, then extended. No project that asks for months of faith before showing anything.

Whoever builds it maintains it

Software delivered and abandoned stops being useful within a year. Maintenance is part of the project, not an extra.

The right question is not “custom or off-the-shelf”

It is: how unusual is your process?

If it handles something every company does the same way — accounts, payroll, invoicing — a standard product exists that covers it, costs less, receives regulatory updates and has a community of people who know it. Building it from scratch is the fastest way to spend badly.

If instead it handles something only you do, or that you do in a way that is part of your value, the standard product forces you to bend the process to the tool. And the cost of that bending does not appear in the quotation: it gets paid every day, in manual steps that compensate for what the software does not do.

Between those two extremes lies the zone where the correct answer is mixed: a standard product for the bulk, and a custom piece for the part that sets you apart, connected to the rest.

The most frequent case: the spreadsheet that became a system

It is the story we see most often, and it almost always ends well.

Somebody, years ago, built a spreadsheet to keep track of something: jobs, deadlines, stock, production. It worked. Then two people used it, then five. Now it is at the heart of a business process, lives in a shared folder, and has three problems no formula solves.

Versions. Whoever opened the file last wins, and every so often somebody loses an hour’s work without noticing.

Permissions. Everyone sees everything, including the columns they should not.

History. Nobody knows who changed what and when, so when a figure is wrong it cannot be reconstructed.

Moving to a web application preserves the logic you have refined over the years — that is the valuable part — and removes all three problems. It is also the project with the fastest and most visible return that we do.

How we work

First we look at the process, we do not write code. Who does what, in what order, with which exceptions. The exceptions are the important part: they are what makes projects fail when they surface after the work is done.

Then we build the minimum version that genuinely works. Not a prototype to look at: something that gets used, even if it only covers the main case. It is measured in weeks.

Then we extend it with what has been learned from using it. The requests that arrive after first use are almost always different from the ones imagined beforehand, and that is normal.

The code and the documentation are yours from day one. It is the protection against the worst scenario in this trade: custom software nobody can modify any more because whoever wrote it has gone.

What we do not do

We do not build what you could buy. If the analysis shows a standard product covers your case, we tell you — even though it means one project fewer for us.

We do not deliver and disappear. Business software changes along with the company; abandoned software stops being useful within a year. Maintenance is part of the project.

We do not add security at the end. Permissions by role, logging, encryption and retention periods are decided at the start, because taken later those choices force work already done to be redone.

The rest

See also custom software development for the method in full, AI process automation where the part to remove is repetitive rather than complex, and IT consultancy where the question upstream is still which road to take.

The first step

We look at the process you would like to automate and tell you honestly whether something needs building or whether it already exists. Free and without obligation.

Frequently asked questions

When does custom business software beat a standard product?

When the process it has to handle is your competitive advantage, or when no standard product covers it without forcing you to change how you work. If instead the process is a common one - accounts, stock, payroll - off-the-shelf costs less, stays more current and ages better. The useful question is not which is better, but how unusual your process is.

What does it cost and how long does it take?

It depends on the scope, but the principle we work to is proceeding in steps with a useful result at the end of each. A minimum working version is measured in weeks, not months. It is also how the risk gets reduced: if the value is not visible after the first step, you stop having spent little rather than discovering it once the project is finished.

We have a process running on spreadsheets. Can it become software?

It is the most frequent case and often the most worthwhile. A shared spreadsheet works while one person uses it; with three people it becomes a versioning problem, with ten it becomes unmanageable and nobody knows which file is the good one any more. Moving to a web application preserves the logic you have refined over the years and removes the problems of concurrency, history and permissions.

What happens if we need changes a year later?

It is expected, and it is why we build in steps. Business software is not a finished object: it changes along with the company. What we avoid is the worst situation, namely custom software nobody can modify any more because whoever wrote it has gone and left no documentation - which is why the code and the documentation are yours from day one.

Is the software you build GDPR compliant?

The protection measures are designed from the start rather than added afterwards: permissions by role, access logging, encryption where needed, data retention periods. It is not a box to tick at the end - it is a series of technical choices which, taken later, force work already done to be redone.

Tell us about the process you do by hand today

The projects that work start from one precise, repetitive activity rather than from a list of features. Describe it and we will tell you whether automating it is worth it.

Contact us+39 02 40709414