Custom software development
When the tool doesn’t fit, the work bends to the tool. I build software around the process you already have: the same operations, without the steps that only exist for the program’s sake.
What it looks like
It usually starts like this
- Three versions of the same spreadsheet
- Data copied by hand from one tool to another
- Business software that covers half the job
- Steps that exist only because the program asks for them
Generic software is built on the average of thousands of companies. If the way you work is the reason clients come back, bending it to that average means switching off exactly that, and paying every month to do it.
What I build
Web platforms and applications
Tools that open in the browser and work on desktop and phone, with nothing to install. Separate access for each role, data always up to date, no local copies to keep in sync.
Business software and internal tools
The place where work gets recorded as it happens: records, statuses, tasks, history. Whoever logs in the next day finds things exactly as the person who left the evening before left them.
Dashboards and reports
The numbers you need to make decisions, calculated from real data instead of rebuilt by hand every Monday. And exportable, because sooner or later someone will ask for them in another format.
Private areas and portals
Spaces where clients, collaborators or departments see only what concerns them. Permissions are explicit and readable in the code, not a convention everyone has to remember.
Database and data model
What a client is, which statuses it can go through, which transitions are allowed and which aren’t. The model comes before the interface: when it’s right, the interface becomes almost obvious; when it’s wrong, no interface can save it.
How it works
The system, not just the screen
How custom software comes to life
- Process
- Software
- Data
- Integrations
- Control
Real example:Valsusa BIOS
The business software the company uses every day.
ClientCalendarSurveyQuotePDFSupplierInspection
Process first, technology second
The initial request is almost always a solution in disguise. Before writing a single line, I look at how the work really gets done, where time is lost and what gets redone every day: technology chosen too early decides what you’ll be able to build later.
Built in usable parts
Not a single block delivered at the end. Each part works before the next one starts, so the system can be used (and corrected) while it grows.
Integrations fail visibly
A fragile connection is worse than no connection: it builds trust and then quietly betrays it. Every integration is built to say when it hasn’t worked, instead of leaving data half-written.
Launch day should be boring
Real devices, slow connections, wrong data, people clicking where they shouldn’t. It all gets tested first: if going live is an exciting event, something was skipped.
Use cases
- Replacing a spreadsheet shared by several people with a tool that has permissions, history and no “final (2)” version
- Giving a business a single source of truth, instead of four tools that contradict each other
- Bringing online a process that today lives on paper forms or PDFs filled in by hand
- Building the first version of a digital product, with only what’s needed to find out if it holds up
- Adding the missing piece to existing software, instead of rebuilding everything from scratch
Technologies
Next.js, TypeScript, Node.js, PostgreSQL, Supabase, Vercel
The tools I use most often on this kind of project. They aren’t affiliations: they’re choices I revisit when a project calls for something else.
Questions
- When does custom software make more sense than an off-the-shelf product?
- When the way you work is an advantage and off-the-shelf software asks you to give it up, when you pay for licenses for features you don’t use while the one you need is missing, or when you hold two tools together with copy and paste. If instead there’s a product that already does 90% of the job, I’ll say so: building for the sake of building isn’t a service.
- Can I start with a smaller first version?
- Yes, and it’s almost always the right call. I decide with you what goes into the first version (the minimum that makes the system useful) and add the rest after seeing it in the hands of the people who use it, not before.
- What happens after launch?
- That’s where the real product starts: I watch how it’s used, remove the friction nobody anticipated and improve what usage points to. How to continue (work on request or an ongoing relationship) is something I agree on with you, based on the project.
If yours isn’t here, see all the others.
