Challenges
Off-the-shelf tools stop fitting; processes live in email and spreadsheets; integrations are fragile and unaudited.
Industry
Enterprise
Off-the-shelf tools stop fitting; processes live in email and spreadsheets; integrations are fragile and unaudited.
What we build
Processes leave the spreadsheet; AI and systems ship with owners and audit trails; staged rollouts so the business never stops — in BiH, Europe or further.
How we approach it
Companies rarely come to us wanting software. They come with a process that has outgrown the tool holding it — usually a spreadsheet that started as somebody's private convenience and is now, quietly, the system the business depends on.
That spreadsheet is worth taking seriously rather than mocking. It survived because it fit the work exactly, and any replacement that fits less well will lose, no matter how much better it looks in a demo. So the first phase of any engagement is understanding what the spreadsheet actually encodes — including the rules nobody wrote down and the exceptions one person handles by hand every Friday.
The honest question before building anything is whether you need custom software at all. Often the answer is no: an existing product covers eighty percent, and the right work is configuration plus one integration. We would rather say that early than sell a build. Custom becomes the right answer when the process is the thing that makes the company money, when no product fits without distorting how the business works, or when the integration surface — accounting, fiscalisation, suppliers, an existing ERP — is where the real difficulty lives.
When it is the right answer, the risks are predictable. The system launches and nobody uses it because it was designed from a specification rather than from the working day. Or it launches all at once, breaks something, and the business stops. Both are avoidable with staged rollout: one process at a time, with the old way still available until the new one carries itself. That is slower on paper and faster in practice.
Integrations deserve their own attention. A fragile integration that nobody owns and that logs nothing is a future outage with a date already set. Anything that crosses a system boundary gets an owner, an audit trail, and a defined behaviour for when the other side is down — because the other side will be down.
AI belongs in this picture, but late and narrowly. A process that is not yet reliable does not become reliable by adding a model to it. Once the core system works and the data is trustworthy, the useful applications are specific: extracting structure from documents that arrive as PDFs, drafting routine correspondence, and surfacing the exceptions a person should look at — always with the person still deciding.
Common questions
How do we know if we need custom software or an existing product?
The test is whether the process is what makes you money. If an existing product covers most of it and the gap is configuration plus one integration, buy the product — we will say so, and it is a shorter conversation than a build. Custom earns its cost when no product fits without distorting how the business actually works, or when the integration surface is where the real difficulty lives.
Will the business have to stop while we switch?
No, and a plan that requires it is a plan worth refusing. We roll out one process at a time and keep the old way available until the new one carries itself. It reads as slower on a timeline and turns out faster in practice, because the alternative — everything at once — is how projects produce a week nobody in the company wants to remember.
Can it connect to the ERP and accounting program we already use?
That is usually the core of the work rather than an afterthought. What matters is not whether a connection is possible — it almost always is — but who owns it, what it logs, and how it behaves when the other side is unavailable. We treat every system boundary as a place that will fail eventually and design the behaviour for that day in advance.
Enterprise
