Capability · Software
Software built for the way you already work, not the other way round.
Some of what a company needs does not exist yet. Not a setting in a product, not two systems that need connecting — a tool that has to be written, because the job it does is yours. We build those: internal apps, portals, dashboards, the thing that finally replaces the shared spreadsheet. And we build them around the systems you already run, so nobody has to move.
Free, 30 minutes, no obligation.
What gets built
- Internal web apps and admin portals for work no product covers
- Client portals and self-service tools, with your rules inside them
- Dashboards and calculators that read from the systems you already run
- A replacement for the shared spreadsheet three people fight over
The problem
The process that matters most is the one nobody sells software for.
Every company that has been trading a while does one thing in a way no product has ever heard of — how a job is scheduled, how a price is worked out, a record that has to be made where the work happens rather than back at the office. It is usually the part that works. It is also the part running on a spreadsheet, because nothing on the market fits it and the platform that comes closest would mean moving all the data and teaching everybody a new system.
Today
- 1The process the business depends on is the one no product covers
- 2It lives in a shared spreadsheet, a group chat and one person's memory
- 3Only that person can say what state the work is actually in
- 4The platform that would cover it would mean migrating the data and retraining the team
- 5So the workaround stays, and the next workaround gets built on top of it
With Reviamo
- 1A small tool exists for that one job — your rules, your vocabulary, and nothing else in it
- 2It reads from and writes to the systems already in use, so nobody moves platform and nobody learns a second way of working
- 3The state of the work is visible without asking anyone, and what the tool records feeds whatever has to happen next
Custom software is not a bigger product. It is a smaller one — the part of the job you actually do, and none of the parts you don't.
How it works
Scoped to one job, built around what you already run.
-
1
Scope
The first decision is how much not to build. A job can be scoped like this: staff need their attendance recorded; the vehicles they already take out carry QR codes; a small web app on a phone scans one; the scan writes an attendance record; and those records then feed the travel-order documents — in Italy the rapportini and the mileage records — that somebody is otherwise typing up at the end of the month. Three small pieces, each doing one thing. That is the size of a sensible first build, not a system.
-
2
Fit
Before anything is designed we work out what the tool must not disturb. People sign in with the Microsoft 365 or Google Workspace accounts they already have. Master data is read from the gestionale rather than typed in again. What the tool produces goes back where that record belongs. The real test of a custom tool is how little else has to change for it to be useful.
-
3
Build
We build in small, visible pieces, on your real data, so you can change your mind while changing it is still cheap. The technology is deliberately ordinary — a standard web stack, a standard database, nothing exotic — because the person who opens this code in three years might not be us, and that is a requirement rather than a risk.
-
4
Run it alongside
New software runs next to the old way, not instead of it, until people prefer it. The spreadsheet stays open as long as anyone still wants it; the day nobody opens it is the day the build is finished. Training is a conversation rather than a course, because a tool that needs a course was scoped wrong.
-
5
Hand it over
You get the code, the repository, the hosting accounts and documentation written for whoever comes next. Then the honest part: bespoke software has to be maintained, and someone has to own it — either us, on an agreed support arrangement, or a named person on your side with the access and the time. Software with no owner rots quietly, and it is better to settle that at handover than to discover it a year later.
Illustrative, and deliberately generic — the shape a job record takes, not any one company's. The flagged row is the point: a missing scan stops and waits for a person instead of being filled in with a guess.
Plugs into
What a custom tool has to reach on day one
- Gestionali & ERP
- TeamSystem, Zucchetti, Danea EasyFatt, Odoo
- Invoicing & SdI
- Fatture in Cloud, FatturaPA XML through the Sistema di Interscambio
- Accounts & workplace
- Microsoft 365, Google Workspace — people sign in with the account they already have
- Shops, sites & data
- PrestaShop, your own website, and the databases and spreadsheets the work lives in today
A custom tool is only as useful as what it can reach. If a system has an API, or exports XML or CSV, it is almost certainly fine; where there is no API, a scheduled file drop or a mailbox usually does the job. The one exception is SAP — we don't integrate with it, and we say so up front.
Who it's for
-
Companies whose best process is nobody's product
The way you do one thing is the reason clients stay with you. It is also the reason no software on the market fits.
-
Teams living in one shared spreadsheet
Three people, one file, and a version that is correct for about an hour a day. Everyone knows it is fragile; nobody has time to replace it.
-
Anyone who has been quoted a platform migration
The product would cover it, at the price of moving every record and retraining every person. Often a smaller build around what you have does the same job.
-
Work that happens away from a desk
Site visits, deliveries, installations — where the record has to be made where the work is, on a phone, or it gets written up badly hours later.
Solutions in this area
The specific processes this covers, each compared before and after.
Operations
Documents that write themselves
A custom tool captures the facts of a job; this is where those facts become the paperwork that has to follow it.
Read moreKnowledge
An assistant over your own documents
When the thing to build is a way to find what the company already knows, this is the shape it takes.
Read moreHR
CV screening for a real hiring round
One of the smallest internal tools a company asks for, and usually the easiest first build to scope properly.
Read moreQuestions
The questions people ask before commissioning software.
How is this different from automating the systems we already have?
Automation connects software that already exists; custom software is the part that has to be written because nothing exists to connect. In practice the two meet constantly — a custom tool is usually the missing step in the middle of an otherwise automated flow, and the flow is what makes the tool worth having. If your problem is that two systems don't talk to each other, start with connecting what you already run; it is cheaper, and often it is the whole answer.
Do we have to move off the systems we already use?
No — the tool is built around them, and that is the entire point of building it. Your gestionale stays where it is, whether that is TeamSystem, Zucchetti, Danea EasyFatt or Fatture in Cloud; people sign in with the Microsoft 365 or Google Workspace accounts they already have; and the new tool covers only the job nothing covered before. Nobody is asked to learn a platform in order to keep doing what they were already doing.
Who owns the code?
You own it — the code, the data and the accounts are yours from the first commit. The repository sits in your organisation, the hosting and the database are in your name, and there is no licence to keep paying us for. If you ever want another supplier to take it on, you hand over a repository and its documentation, and nothing of yours has to be extracted from a platform first.
What happens when it breaks, or when the process changes?
Someone has to own it — bespoke software does not maintain itself, and that is the honest cost of having it. That means either an agreed support arrangement with us, or a named person on your side with the access and the time to keep it current. We keep the surface small and the technology boring precisely for this reason: fewer moving parts to follow, and a change to the process is usually an afternoon rather than a rebuild. If nothing about the process is stable yet, we will tell you it is too early to build anything.
Is there AI in it?
Usually not, and we will say so plainly. Most custom software is ordinary software — forms, records, rules, permissions, a report at the end of the month — and calling that AI would be both dishonest and harder to maintain. We reach for a model only where the work is genuinely reading unstructured language or documents, which is what an assistant over your own documents is for, and we leave it out everywhere else.
We are not sure what should be built. Where does this start?
With a free consultation, before anything is designed or costed. Then a paid process audit that ends in a fixed price, and the audit fee comes off it in full if you go ahead. The audit is where the harder question gets answered honestly: sometimes a product already covers it, sometimes the process needs fixing before any software is worth writing, and sometimes the answer is a connection rather than a build. The steps are set out in how we work, and the decision itself is an advisory conversation before it is a project.
Related solutions
Two conversations worth having before anyone writes code.
Capability
The systems you already have, finally talking to each other
A surprising amount of what looks like missing software is two systems not speaking. Worth ruling out before commissioning a build.
Read moreCapability
Deciding what to automate, and what to leave alone
Build, buy, connect or leave it: the sequencing conversation. Not everything that annoys you is worth writing software for.
Read moreAll solutions
See everything we automate
Six of the processes we're asked for most, each compared before and after.
Back to services
Free consultation
Tell us about the job that still runs on a spreadsheet.
One process, who does it, and which systems it touches. Thirty minutes online is enough to say whether it should be built, connected, or left alone. No preparation needed.