Custom web applications
When what you need isn't a website but a tool: quoting, bookings, contracts, an internal panel. Software written around your process, not the other way round.
Where I workFormenteraIbizaSpainEurope
Almost everything I've built over these years has been this: web applications solving one concrete problem for one concrete business.
Not pretty websites. Tools someone opens on Monday morning to get their work done.
The pattern I keep finding
There's a task done by hand, every day, that nobody questions because it has always been done that way.
Someone copies data from an email into a spreadsheet. Someone hunts for a contract in a shared folder. Someone has to ask a colleague, because what they need isn't written down anywhere.
Each of those costs little. Added up, they cost a full-time person.
At a packaging factory in Slovenia, quoting an order took three to four days. The maths wasn't the problem: the problem was that the rules for doing it lived in two people's heads. I wrote about it on the blog, because it's the same pattern I've been finding ever since, in businesses of every size.
What I build
- Internal tools. Admin panels, fleet control, order tracking — whatever your team needs to stop working inside a shared spreadsheet.
- Calculators and configurators. Automatic quotes, pricing simulators, with your business's real rules inside them.
- Booking and contract systems. Reservation, confirmation, signed document, notification. The whole circuit, not just the form.
- Portals and private areas. Each client or department logs in and sees their own thing, and only their own thing.
- Integrations. Connecting what you already use so you stop copying data from one place to another.
How I work
Process first, code second. The first conversation isn't about technology. It's about what you do today, step by step, who does it and where it jams. Most of the work in a custom application is understanding the problem properly; writing it is the easy part.
A fixed quote agreed before we start. In writing, with what's included and what isn't. If something falls outside the scope we talk about it then, not on the invoice.
Delivered in pieces, used early. I'd rather you used something small and real in two weeks than waited three months to see a whole product. What gets corrected early is cheap.
You talk to me. There's no account manager between you and the person writing the code.
Real work
I don't work with sample projects. These are real projects, and for each one I say which part was mine:
- Cetis Flexo App. A packaging factory in Slovenia took three or four days to give a price. Now it takes seconds: the customer picks material, ink, quantity and dimensions, sees the box in 3D and confirms. I was the one facing the company on behalf of the team and setting the pace, and I worked on both halves: the screen the customer uses and the calculations running underneath.
- APP Ibiza Circular. The application the Consell d'Eivissa uses to run vehicle regulation on the island: the data laid out in charts and lists you can read at a glance. I built the entire visual side — what the person actually sees and clicks on — and made part of the engine behind it faster.
- Savia. My own product, still in development: a second brain for companies. It learns how the business actually runs and answers anyone on the team instantly, always saying where each answer came from. And when it's asked something the company hasn't written down, it spots that and learns it, instead of staying the same. Here I do all of it, start to finish.
There's detail on each one in the projects section.
When you don't need this
If what you need is a presentation site, this isn't it — that's web design. If it's selling online or taking bookings on a standard platform, that isn't it either — that's an online store.
And if software that already exists covers your case, buy it. It saves you money and saves me a project that shouldn't exist.
Getting started
Tell me which task is eating your time. That alone is enough to tell whether you need an application, whether connecting two tools you already have would do, or whether you need nothing at all.
Frequently asked questions
What is a custom web application, and how is it different from a website?
+
A website tells people what you do. An application does something: it calculates, stores, notifies, generates a document, controls who sees what. If your team logs in every day to work inside it, it's an application. If your customers visit to find out about you, it's a website.
Wouldn't off-the-shelf software be cheaper?
+
Often yes, and I'll say so. If a product on the market covers your case, the sensible thing is to buy it. Custom development makes sense when your process is what sets you apart, when nothing fits without contorting it, or when you've spent years paying licences for something you use at 20%.
How long until something works?
+
It depends on scope, but I don't do blind deliveries. The first thing that ships is the part that solves the main pain, so you can use it and correct it early. Everything else gets built on top of something that already works, not on top of a document.
What do you build with?
+
Whatever suits your project. They're the industry-standard tools, the same ones large applications are built with, and I choose on two grounds: what your case needs, and what will be easy for you to maintain afterwards. I'll happily give you the technical detail if you want it, but you don't need to understand it to work with me — that part is my job.
Do I own the code?
+
Yes. The code, the database and the access are yours, in your repository and your infrastructure. I don't build in dependencies that force you back to me for every change.
Can you work on an application that already exists?
+
Yes. I've joined projects already under way, both to add features and to rebuild the interface. The first step is reading the code and telling you honestly whether it's worth continuing or starting over.
