Custom software development
For the business problem that no off-the-shelf product actually solves — because the way you work is the thing that makes you competitive.
Most companies reach custom software the same way. A spreadsheet became the system of record. Then it became three spreadsheets and a shared inbox. Then someone left and took the only working knowledge of it with them. The off-the-shelf products you evaluated all assume a process slightly different from yours, and adapting your process to the tool costs more than the tool saves.
That is the point at which building something is cheaper than continuing to work around everything. I take that business problem and build the product around it — backend, web and mobile — from the first requirements conversation to a live system your team relies on daily, and I keep maintaining it after launch rather than handing over a repository and disappearing.
I have done this as a freelancer, as an employed engineer owning a product end to end, and as the founding engineer of a startup — which means I have also lived with the consequences of my own architecture decisions for years. That tends to make a person conservative in useful ways.
What you get
A working system, not a prototype
Deployed, monitored, backed up, and documented well enough that another engineer could pick it up. A demo that only runs on my laptop is not a deliverable.
The whole stack from one person
Database schema, backend services, web frontend, mobile app where you need one. No integration seam between vendors, because there is only one vendor.
Your domain modelled honestly
I spend real time on what your business actually does before writing code. Software that models the wrong thing elegantly is worse than software that models the right thing plainly.
Maintenance after launch
Launch is when a system starts generating requirements, not when it stops. I stay on for the fixes, the changes and the things nobody could have predicted.
How it works
- 01
Understand the operation
A conversation about what the business does, where the manual work is, and what breaks today. I want to see the spreadsheet. The spreadsheet is always the truest specification anyone has.
- 02
Scope the first useful version
Not the whole vision — the smallest system that replaces a real piece of the current pain and can be extended. You get a written scope, a sequence and an honest estimate before anything is committed.
- 03
Build in visible increments
You see working software regularly, not status reports. Direction changes are cheap early and expensive late, so early is when I want your opinion.
- 04
Launch, then keep it running
Deployment, monitoring and a handover of what matters — followed by ongoing maintenance and the next increment.
Typically built with
Where I have done this
Smart Steel Technologies
The Material Allocation product — matching surplus steel inventory to new customer orders — owned from the data model to the user interface.
Read more →Benzigo
The customer-facing app with card payment for invoices, and a fleet of autonomous bots that carry out fuel-card operations on the provider's own platform.
Read more →fjalla
A streaming platform that pays artists per play — architected and written from nothing, then grown with a team.
Read more →Common questions
How much does custom software cost?
It depends entirely on scope, and anyone quoting before understanding the problem is guessing. What I can tell you early is the sequence — which piece is worth building first, what it will roughly take, and where the genuine uncertainty sits. Most engagements start with a scoped first version rather than a full-system quote, precisely so you are not betting a large budget on an estimate made before anyone understood the domain.
How long before we have something usable?
A focused first version is typically weeks rather than quarters, because it deliberately replaces one real process rather than everything at once. Full systems grow from there over months. I would rather you have something imperfect in production early than something complete in six months that turns out to model the wrong process.
What happens if you become unavailable?
A fair question to ask a single freelancer, and the reason I write documentation and use ordinary, widely-known technology instead of clever things only I understand. The code, infrastructure and accounts are yours throughout. Another competent engineer can take over a system built this way without archaeology.
Do you work with existing codebases?
Yes. A good share of my work has been taking over, extending or rescuing something already running. I will tell you honestly whether it is better repaired or replaced, including when the answer is inconvenient for me.
Do you work remotely, and in which languages?
I work remotely with clients across Europe, and I work in English, German and Serbian. I am based in Serbia, which puts me in Central European time and inside comfortable overlap with the whole continent.
Have a project like this?
Tell me what the system has to do and what it has to talk to. You get a straight answer about scope, sequence and what I would build first — before any commitment.
Start a conversation