01 / Perimeter
Primary offer
Custom software development: when no product covers your process
Some companies lose hours every week bending the way they work to a product they bought. Others keep the most important part of the business running on a spreadsheet only one person can open. The cost is the same in both cases: time nobody decided to spend, and a risk concentrated in a single point.
Kinds of project
- Custom business system
- Internal application
- Narrow vertical tool
- Customer portal
- Private area
- Product configurator
- Quoting tool
- Replacing spreadsheets
This is not a catalogue: it is the kind of project that comes up most often. The test is always the same — if your process is unusual and no product covers it, you build. If a product covers it, you buy the product.
- What I deliver
- An application in production with its own database, its own users and its own permissions, plus source code, technical documentation and credentials held in your name.
- What I don't do
- I don't resell licences and I don't start without an analysis. If a product on the market covers your case, I say so and we stop there.
- Indicative time
- An estimate, not a contractual commitment: eight to twenty weeks from analysis to the first version in use, depending on how many processes it covers.
- Where I work from
- Italy, on Central European Time: a working day that overlaps with the whole of Europe, the UK and the first half of the US day. Remote by default, on site where the analysis needs it.
02 / Diagnosis
The cost of software that doesn't look like you
The wrong software doesn't show up in the accounts. It shows up in people's hours.
Nobody budgets for «time spent working around the system». Yet it is the line that grows fastest, because every workaround becomes a habit, and every habit becomes a dependency on the person who knows it.
The process that sets you apart is the one no product handles
Off-the-shelf products cover well what every company does the same way: invoices, ledgers, standard stock control. The part that makes customers choose you is by definition unusual, so it is not in the product. And so it ends up outside the system, handled by hand by whoever knows it.
A spreadsheet works until the person who wrote it leaves
A file holding the rules of the business is software with no author, no controls and no backup. Nobody knows who changed what, two people cannot work in it together, and a broken formula produces plausible numbers instead of an error. It is the most underrated risk I see in companies.
Customisations on top of a product are the spend that gets out of hand
The product is cheap at the start, then comes the extra module, the per-user subscription, the customisation done by the reseller and the one after that because the first didn't survive an upgrade. In the end you have spent what a bespoke project costs, without owning either the code or the control.
Nobody can improve a process that lives outside the systems
If the information sits in files, emails and people's heads, there is nowhere to read how much a step costs, how often work is redone, where errors pile up. It is not a reporting problem: the data is never recorded in the first place.
Before and after, on the same processes
These are not results measured on clients: they are the process changes custom software produces, described for what they are.
| Process | Before | After |
|---|---|---|
| Working rules | In the heads of two or three people, and in a file updated by whoever remembers. | Written into the software, applied the same way every time and changed in one place. |
| Status of a job | Reconstructed by asking around and cross-reading emails. | It is a screen, updated by the person doing the work at the moment they do it. |
| Who sees what | Anyone with access to the shared drive sees everything, including what they don't need. | Each role sees its own data and can take its own actions, and there is a record of who changed what. |
| A data entry error | It goes through, and turns up downstream once it has already produced a wrong document. | It is stopped at the point of entry by the process checks, with a message to the person making it. |
| A key person missing | The work stops or is redone, because the method was theirs. | The method is in the software: whoever steps in follows the same screens. |
| Measuring what a step costs | Impossible: the data is not recorded anywhere. | Each step leaves a timestamped trace, so the duration can be read. |
03 / Solution
The software around the process
It is built around the process you already have, not the one you ought to have
If your process is unusual, the software should bend to it. Not the other way round.
A bespoke project does not start from a list of features: it starts by watching how people actually work, which is almost always different from what the written procedure says. Out of that comes the list of the steps that cost the most, and from there we decide what goes into the first version and what waits — because the first version has to be in use early, not complete. What I deliver runs on cloud infrastructure in your name, on technologies with a deep pool of developers: that is the condition that keeps the project yours even if one day you hand it to somebody else.
Flusso dei dati
A narrow first version, in use early
We start from the process that costs the most manual work today, and that goes live first while the rest is being built. A narrow first version that somebody actually uses teaches more than six months of specification: the things that don't add up surface there, when fixing them is cheap.
Rules become checks, not reminders
«That customer needs approval», «below that quantity we don't sell»: today those are things somebody has to remember. In the software they become constraints applied at the point of entry, with a message a working person can understand instead of an error discovered downstream.
It lives alongside the ERP, for as long as that makes sense
In the large majority of cases the ERP stays where it is: it does the finance side well and holds years of history. The custom software covers the missing part and connects for customer records, products and documents, so the data stays single. When the analysis instead shows the ERP itself is the bottleneck, replacing it is a project I take on — declaring first where the real cost sits, which is in migrating the history and retraining people, not in the software.
Documents live where the work lives
Quotations, orders, delivery notes, certificates, drawings and test reports are attached to the job or the customer they belong to, with versioning, permissions and full-text search. A document is found by starting from the work it is part of, not by remembering which shared folder somebody saved it in.
Migration from the files you have
The data sitting in spreadsheets today is imported with the mess it carries: duplicates, free-text fields, codes written three different ways. The minimum necessary clean-up is part of the project and is one of the items sized during the analysis, because it is almost always longer than it looks.
What kind of software I build
- Custom business systems for processes that don't exist as a product: make-to-order production, rental, laboratories, field service
- Narrow internal applications that do one thing well, sitting alongside the ERP you keep
- Portals and private areas for customers, resellers, agents or branches, each with their own data and permissions
- Replacing systems held together with spreadsheets, shared drives and macros written by someone who has left
- Product configurators and quoting tools that apply your commercial rules without anyone having to remember them
- Custom software connected to SAP Business One, Dynamics 365 Business Central, NetSuite, Odoo or Sage for customer records, products and documents
- Document management: quotations, orders, delivery notes, certificates and drawings attached to jobs and customers, with versioning, permissions and full-text search
- Planning and scheduling tools for teams that today work off a whiteboard or a sheet printed every morning
What is inside the application
04 / Specifications
What you buy, and on what terms
The specifications, before the promises
What follows is what decides whether a bespoke project is a sensible choice or an expensive mistake. It is the same set of things I will tell you in the first half hour.
What gets delivered
- Application
- A web application reachable from a browser, with nothing to install on workstations, usable from tablet and phone where the process calls for it.
- Archive
- A single database in place of scattered files, with automated backups and the ability to export everything in open formats.
- Users and permissions
- Roles with distinct visibility and actions, and a record of who changed what and when on the entities that matter.
- Documentation
- An architecture document with the technical decisions and the alternatives I rejected, plus the technical documentation of the code delivered.
Ownership and continuity
- Source code
- Yours, repository included. No encrypted components, no usage licence, nothing that stops working if you stop working with me.
- Infrastructure
- Cloud in your name, with the credentials yours from day one. Not mine with a delegation: the difference shows on the day you want to change supplier.
- Technologies
- Chosen from the widely used ones with a deep pool of developers, not from the ones only I know. It is the constraint that makes portability real.
- After release
- A support period agreed before we start, with a written scope. It is not an open-ended retainer in disguise.
Integration with the systems you run
- ERP
- In most cases it stays where it is. The custom software connects for customer records, products and documents, so nothing is entered twice.
- How it connects
- The ERP's APIs where they exist; otherwise reading the database, or scheduled file exports and imports dropped on SFTP.
- Third-party platforms
- Shopify, WooCommerce, warehouse systems and shipping services are integrated as sources or destinations of data.
- Data migration
- Import from the spreadsheets you already have, with the minimum necessary clean-up sized during the analysis. It is the item most often underestimated.
How we work
- Delivery
- In milestones you can try: at every delivery there is a part you can use on real data, not a percentage of progress.
- Who does what
- Analysis, architecture and code review stay with me. Development I delegate to a small network of people I have worked with for years: it keeps costs sane and lets me open more fronts when a project needs it.
- Changes of priority
- Taken on at the next milestone, not halfway through one in progress. It is the rule that keeps dates and budget together.
- Price
- No price list: after the analysis the project has a fixed figure, not an open hourly rate. If the spend makes no sense against what the manual work costs you today, I tell you.
Working across borders
- Time zone
- Central European Time: a full working day overlapping with Europe and the UK, and the afternoon overlapping with the east coast of the United States.
- Data residency
- Hosting can be pinned to an EU region, or another region if your own rules require it. The choice is written into the architecture document, with what is logged and for how long.
- Contract and currency
- An Italian sole trader invoicing in euros, at a fixed price against a written scope. I am happy to work under your contract and your NDA.
- Working language
- English for documents, code, commit messages and calls. The architecture document is written in English, not translated afterwards.
Off-the-shelf product or custom software
The comparison that matters is not the starting price. It is the rows below, and it is the judgement the analysis produces before any quotation.
| Item | Off-the-shelf product | Custom software |
|---|---|---|
| Fit to the process | Covers well what every company does the same way. On the unusual part, the process is bent to the software. | Built on the process you have. The unusual part is the reason it exists. |
| Initial spend | Low. You buy it and start, often within weeks. | Higher and concentrated at the start: there is analysis, design and building to do. |
| Recurring spend | A subscription that grows with users and with the modules you switch on. | Hosting of the infrastructure, plus the changes you decide to make when you decide to make them. |
| Customisations | Paid for, and to be rechecked at every product upgrade. | They do not exist as a separate line: they are the product. |
| Time to be operational | Short on installation, long on getting people to adapt to the software. | An estimate, not a commitment: eight to twenty weeks from analysis to the first version in use, covering the most expensive part. |
| Ownership | A usage licence. The code is not yours and portability depends on the exports the vendor grants you. | Source code, database and infrastructure in your name, documentation included. |
| Evolution | Depends on the vendor's roadmap: what you ask for arrives if other people ask for it too. | Depends on your priorities, with whoever you choose to develop it next. |
This is not a table in favour of building. It is the test for choosing. If your process is standard, the left-hand column is the right answer and costs far less. If the part that sets you apart is also the part no product handles, the left-hand column makes you pay for it in people's hours instead of on an invoice.
Included in a bespoke project
- Process analysis and a map of how people actually work, not of what the procedure says
- An architecture document with the technical decisions, the alternatives rejected and their limits
- Development in milestones you can try, testing and code review done by me
- Connection to the systems you keep, ERP included, and import of the data you already have
- A gradual release with the old process still running as a safety net
- Technical documentation, handover of code, database and credentials, and an agreed post-release support period
Not included, and I say so up front
- Licences for your own systems and subscriptions to third-party services
- Hosting and infrastructure, which stay in your name and are billed to you by the cloud provider
- Tax, legal or employment advice on the rules the software applies
- Clean-up of historical data beyond what the migration needs, unless agreed separately
- Extended staff training beyond the handover and the documentation
- Any promise of a financial result: it cannot be guaranteed and I don't make it
05 / Route
Four phases, three of them mine
How you get from a need to software in use
The durations are estimates to help you plan, not contractual commitments. The calendar is one of the first things we discuss on the call, so the dates are set together rather than discovered once the work has started.
- 01
Analysis
I look at how people actually work and where the process costs. The first output is the answer to the question that matters: do you need custom software, or does a product on the market cover you?
- Cosa ricevi
- A process map, a list of the most expensive steps in hours, and a judgement on build versus buy.
- Durata
- 1–2 weeks (estimate)
- 02
Architecture
I define the archive, the roles, the rules to apply, the connections to the systems you keep and the scope of the first version. I also document the limits: what will not be possible, and why.
- Cosa ricevi
- An architecture document with diagrams, limits, the scope of the first version and a release plan.
- Durata
- 2–3 weeks (estimate)
- 03
Development
Built in milestones you can try, starting from the process that costs the most manual work today. At every delivery there is something you can use on real data.
- Cosa ricevi
- Milestones you can try in a test environment, one part of the process at a time.
- Durata
- Varies by project
- 04
Code review and release
Every line that reaches production passes through my review. The release is gradual, and the previous way of working stays live as a safety net until the new one has proved itself on your data.
- Cosa ricevi
- Software in use, data migrated, documentation and credentials handed over.
- Durata
- 1–3 weeks (estimate)
The variable that moves these dates most is not the code: it is how quickly access, credentials and answers arrive from your side and from the vendors of the systems you already run. Working across a border does not change that, but it does make it worth agreeing at the start who chases whom.
06 / Frequently asked
The same ones I get on the phone
Questions about custom software development
Here are the answers to what nearly everyone asks in the first half hour, awkward objections included. If yours is missing, write to me.
01If you build the software, do I end up dependent on you?
It is the right objection and it is defused before signing, not after. The source code, the database, the documentation and the infrastructure credentials are yours from day one: no encrypted components, no usage licence, nothing that stops working if you stop working with me. I use widely adopted technologies, with a deep pool of developers, precisely so that another supplier can pick the project up by reading the architecture document. A technical lock that keeps a client tied is a choice made by whoever builds it, and I choose not to put one in.
02How does the cost compare with an off-the-shelf product?
Higher at the start, almost always. But the honest comparison is not the starting price: a product has a subscription that grows with users, extra modules are paid for, and customisations on top of the product are the line that gets out of hand, because they have to be rechecked at every upgrade. Custom software has its spend concentrated at the start, then hosting plus the changes you decide to make. I have no price list and I would be wary of anyone who has one for bespoke work: after the analysis the project has a fixed figure, not an open hourly rate. And if the analysis shows a product on the market covers you, I say so and I don't sell you a project.
03How long before I can use it?
As an estimate and not a contractual commitment: eight to twenty weeks from analysis to the first version in use, depending on how many processes it covers. You don't wait until the end to see something, and that is deliberate: we start from the part that costs the most manual work today and that goes live first, while the rest is being built. The calendar is one of the first things we discuss on the call, so the dates are set together and you know in advance when your own time will be needed for testing.
04Who maintains it after release?
The post-release support period is agreed before we start, with a written scope: it is not an open-ended retainer in disguise. After that there are three routes and you choose: a maintenance agreement with me, your internal IT, or another supplier. For the third to be genuinely workable you need up-to-date documentation and ordinary technologies, which is why they are inside the project scope rather than among the nice-to-haves.
05Is the code mine? The source too?
Yes, source included, and it is not a concession: it is the condition that makes everything else credible. The repository, the database, the cloud infrastructure and the third-party services are in your name, not in mine with a delegation. The handover also includes the architecture document and the technical decisions with the alternatives I rejected and why, which is the part that lets whoever comes next work on it without calling me.
06Who writes the code? Do you do all of it yourself?
Analysis, architecture and code review stay with me: that is where it is decided whether the project holds up over time. Development I delegate to a small network of people I have worked with for years, and that is deliberate — it keeps costs sane and lets me open more fronts when a project needs it, instead of queueing everything behind one person. Every line that reaches production passes through my review, and the person you deal with is still me: there is no account manager in between and no handover.
07Do I have to throw away the ERP we use today?
In most cases no, and anyone who proposes that first is selling you something. The ERP does the finance side well and holds years of history: the custom software covers the missing part and connects for customer records, products and documents, so the data stays single. When the analysis does show it is the bottleneck — because it is no longer maintained, because the vendor has disappeared, because every change costs more than it is worth — replacing it is a project I take on. In that case the expensive part is not writing the new software: it is migrating the history and putting a different tool into people's hands. I size that for you first, so the decision is made knowing what it really costs.
08What happens to the data that lives in spreadsheets today?
It gets imported, with the mess it carries: duplicates, free-text fields filled in three different ways, codes written however. The minimum necessary clean-up is part of the project and is sized during the analysis, because it is almost always longer than it looks and it would not be honest to discover that afterwards. During the release the spreadsheets stay live as a safety net: they are switched off when the software has proved itself on your data, not on the day of delivery.
09Is my project too small to be built bespoke?
It can be, and in that case I tell you. A bespoke project has a minimum cost of analysis and architecture that cannot be compressed: below a certain size you are better off with an off-the-shelf product, even an imperfect one, or with automating only the single step that costs. The test is not the size of the company: it is what the process you want to cover costs you in hours today. If that number is low, the right answer is not to do the project.
10You are in Italy and we are not. How does that work in practice?
I work on Central European Time, which overlaps with the whole of Europe and the UK for a full day and with the east coast of the United States for the afternoon. Work is remote by default: repository, ticket tool and calls on whatever you already use, in English. For the analysis phase I travel where it is worth it, because watching people work is worth more than ten calls — but it is a few days, not a permanent presence, and travel costs are agreed in advance rather than appearing on an invoice.
11Where does our data live, and what are the contract terms?
The infrastructure is in your name from day one, so the data stays with you: I am a processor working on your systems, not a place where your data is kept. Hosting can be pinned to an EU region — or another region if your own rules require it — and that decision goes into the architecture document together with what is logged, for how long and who can read it. On the commercial side I am an Italian sole trader invoicing in euros, at a fixed price against a written scope; I am happy to work under your contract and your NDA, and I confirm the VAT treatment before the first invoice rather than after it.
12Do you also build websites or e-commerce stores?
No. Here I build custom software and integrations between business systems: internal applications, bespoke business systems, portals and private areas. E-commerce platforms such as Shopify or WooCommerce I treat only as systems to integrate — products, stock and orders that have to reach the ERP — not as something I design and sell.
07 / Related
The specialisations of this work
The three specialisations that come up most often
They are particular cases of custom software, not different services: if your problem is already one of these, the dedicated page goes further into it.
08 / Contact
Half an hour, no automated quotation
Tell me about the process no software covers
There is no automated quotation to generate, and I won't send you a brochure. We spend half an hour: you tell me how you work and where the process jams, I tell you whether you need custom software or whether a product on the market covers you, and with what order of magnitude of spend. If the answer is that you don't need it, I say so straight away.
Or write to me: I answer, usually within one working day. An NDA before we go into detail is not a problem.
All the contact detailsHow the call works
- Length
- Thirty minutes, video call or phone, in English.
- Who is there
- Me. No salesperson, no handover afterwards.
- What I need
- To know how the process works today, who carries it out and which systems or files you use. You don't need a specification document.
- What you get
- An honest view on build versus buy, on the scope of the first version and on the order of magnitude. The quotation comes after the analysis, not before.