Service /2
Standard software reflects the process its makers considered the most common one. If your process differs, you have two options: you change your process or you change the software.
We build the second option: server and client applications, database solutions and interfaces. For processes that cannot be bought off the shelf, and for those that have outgrown a spreadsheet. Founded in 2003, today based in Salzburg.
This page answers the three questions that usually stay open on provider websites: from what point tailored work pays off, what the price is made of and who owns the source code in the end. It is deliberately written so that you can decide what to do next without us.
A note on figures: many percentages circulate on the ratio of standard to custom software in mid-sized companies. We reviewed the sources we could find and quoted none of them, because they are either older than five years or come from providers who profit from the result. That is why no percentage appears on this page.
Custom software is not fundamentally the better choice. It becomes the better choice as soon as at least two of these three points apply to you.
There is a work step you handle differently from your competitors, and that is exactly what you earn your money with. Standard software forces that step into someone else’s scheme. What sets you apart then becomes the exception that is reworked by hand every month.
The product was cheap, the customisation is not. Every extension is billed by a partner, every new version calls the customisations into question again. Add up the last three years, not the purchase price.
Between two systems sits a spreadsheet maintained by someone whose job it is not. You know that person by name. If they are unavailable, part of the business stops.
If none of this applies, standard software is the right choice, and we tell you so in the first conversation. We have turned down enquiries for which a ready-made product existed. That costs a contract and spares both sides a project nobody wins.
This question is rarely answered on provider websites. We answer it as far as it can honestly be answered: the price arises from six factors, and you influence four of them yourself.
Reducing the price means, in practice: choosing a narrowly cut first release, naming one contact person with decision making authority, using existing and documented interfaces, doing without functions nobody needs today, and being willing to simplify a process instead of reproducing it as it grew historically. In our projects the last point regularly saves more than any technical decision.
On the amounts
We do not publish a price range here, because a range without your scope says nothing. After the assessment you receive a written estimate with line items you can strike out individually. You learn the rates we work with in the initial consultation, before any effort arises.
Ownership and exit
You do. On payment, the rights to the software developed for you pass to you, recorded in the contract and not sold as an add-on. You receive the source code, the database structure, the instructions from which a running version can be produced, and access to everything needed for operation.
This handover runs alongside the project from the first day. The source code sits in version control to which you have access from the start. If you break off the project, you keep everything built so far, together with the instructions for carrying on.
What does not belong to you we name in advance: libraries used remain under their respective licences, purchased components remain with their manufacturer. We keep these components in a list so that your legal department can review them before anything is signed.
And in case you no longer want to work with us: another company must be able to take over the application without having to ask us. That is why we write the documentation for the successor. At handover we check that it serves that purpose: a developer from outside has to be able to build and start the application from the documentation alone.
A software project needs time on your side, and it needs that time scheduled. These four contributions are ones we cannot take off your hands.
Contribution 01
Someone who really knows the process and is allowed to take decisions. In the early phase expect about half a day per week, later considerably less.
Contribution 02
Open questions cost waiting time, and waiting time appears on your invoice. We collect questions and ask them in batches so that you are not interrupted every day.
Contribution 03
At the end of each stage your people test with real transactions, not with sample data. That takes one or two days and is the point at which a mistake is still cheap.
Contribution 04
Whoever is to use the application has to know about it beforehand. We plan training and switchover together. You should carry them out with your own people, because they are the ones the company listens to.
Planning, implementation, integration, then operation. This order has applied here since 2003, and it is the reason the effort can be stated in advance. The plan comes before the first line of code.
Stage 01
Result: description and estimate, verifiable by another provider as well.
We look at the process where it takes place and talk to the people who carry it out. At the end there is a written description: what will be built, what expressly will not be built and which systems are touched.
Stage 02
Result: an architecture your own IT department can read and judge as well.
Data model, interfaces, roles and permissions, operating environment. This stage is the reason later changes stay affordable. Whoever skips it pays for it twice in the second year.
Stage 03
Result: after every stage a running version in your environment.
Building happens in sections that can be accepted individually. After each section something runs that you can try out. That way you see the state of things instead of having to trust a final deadline.
Stage 04
Result: operation with you, source code with you, contact person with us.
Data migration, parallel operation, training, switchover. Afterwards maintenance and further development with the same people who built it. Whoever built the software is still reachable five years later.
If the new application is to access data that currently sits in an old system, replacing that system belongs in the same plan. And where documents are to be read or enquiries pre-sorted, an AI integration on the same data can be added without needing a second project.
Six questions that should be settled before the contract is placed, not afterwards.
That depends on the cut of the first release, not on the overall vision. A first release that carries one process completely is usually in production within a few months. Anything that needs more than a year to reach first productive use is cut too large. In that case we propose a smaller first step.
Maintenance is not insurance against botched work but work on a living system: security updates, adjustments to changed neighbouring systems, bug fixing and small extensions. We bill it by effort or agree a fixed annual budget. Both are in the contract before the project starts, not afterwards.
Yes, and we build towards that. The source code sits with you, the architecture is documented, and we use widely used technologies rather than in-house constructions. If your IT department wants to take over, we hand over in an orderly training. That is at the same time the most honest test of clean construction.
Through four things: ownership of the source code, documentation a third party can read, widely used technologies and access credentials that sit with you. You should be able to commission another company at any time without asking our permission. That is exactly what we check at handover.
They will change. That is the normal case, and the plan is built for it. This is why we build in sections that can be accepted individually and keep the plan open where a change is likely. What changes is estimated and commissioned as a change, not quietly included and invoiced at the end.
Yes. Public tenders impose their own requirements on traceability, accessibility and documentation. Those requirements belong in the estimate before it is submitted, otherwise they reappear at acceptance. Our clients include mid-sized companies, corporate groups and the public sector.
Describe the process that does not fit today. You receive an outline: what a first release would cover, which systems it would touch and in what order we would proceed. Half an hour, at no cost, and you keep the outline even if you have it built elsewhere.
