Applications built around your real process, when nothing on the market covers it. The first question we ask is not how it gets built, but whether it should be.
A custom built system does not end at launch. From that moment somebody has to maintain it indefinitely: dependencies acquire vulnerabilities, the systems it connects to change their interfaces, legal requirements shift, and the people who built it leave.
That cost is invisible at the moment of decision, when everyone compares the price of development against the price of a licence. The correct comparison is made over three years and includes, on the building side, maintenance, and on the buying side, the work of adapting your process.
We do that calculation before the contract and show you the figures. Often the conclusion is not to build, and we tell you even though it means a much smaller project for us.
| Situation | Our recommendation |
|---|---|
| Your process is itself the competitive advantage | Build. A generic platform forces you to work like everybody else, which means giving up what differentiates you |
| Per user licence costs have overtaken the cost of development | Build. It happens often to growing teams. The calculation is made over three years, with the expected growth |
| No solution covers a requirement the business depends on | Build only that part, and we connect it to the rest. There is no point replacing everything for one function |
| The data has to stay with you, for legal or contractual reasons | Build or host it yourself. Sometimes it is the only acceptable option |
| Your process looks like everybody else's in the industry | Buy. You will pay less and get a product tested by thousands of users |
| The requirement comes from a single person | Check first. If nobody else feels the problem, it is probably not a systems problem |
| The process changes every quarter | Stabilise the process first. Anything we build will be out of date before launch |
The most frequent mistake in a company project is not undersizing but oversizing: an architecture built for a million users, on a system used by forty people. The result is triple the cost and a system nobody can debug.
We choose the simplest structure that solves the real requirements, with a clear path to growth if the volume arrives. Complexity is added when reality demands it, not pre-emptively.
The data structure is the most expensive decision to change later. A screen is rewritten in a day. A wrong data structure, with two years of real information in it, is corrected over weeks and with risk.
We model first what entities exist, how they relate, what is retained and for how long. Including the uncomfortable questions: what deleting a customer means when there are invoices attached to them.
Roles and permissions defined from the start, two step authentication for high privilege accounts, a log recording who modified what and when, on the data that matters.
Added later, all of this means touching every component. Designed in from the beginning, they are almost free and they resolve half the requirements of any audit in advance.
Predictably structured, commented where the reasoning is not obvious, with automated tests on the critical flows. The tests are not for us, they are for whoever changes the code in two years without knowing what else they are touching.
No proprietary components tying you to us. The test we apply to ourselves: how long an outside developer would need to take the project over.
We sit with the people doing the work, not only with whoever describes it. What actually happens almost always differs from the written procedure.
A three year comparison, with figures. If an existing solution wins, we tell you and we stop there.
A document another supplier could read and evaluate. Without it, any estimate is a guess.
The main case, working, in people's hands within two to four months. From there decisions are taken on real feedback.
Something verifiable every two weeks. You can change direction without losing months of work.
Technical documentation, user documentation, sessions with your team and a period in which we stay close.
The biggest risk in a software project is not technical. It is building something for months that does not match reality. A system delivered whole after a year reaches its users once the requirements have already changed, and the corrections cost a good part of the project. Two week deliveries are not a methodological fashion, they are the only form of insurance against this risk.
We compare total cost over three years, not the starting price. Buying includes per user licences, which grow with the team, plus the work of bending your process to fit the platform. Building includes development, plus permanent maintenance. If your process looks like everyone else's in the industry, buying almost always wins, and we tell you so.
It is expected and we work so that it is possible. We deliver at short intervals precisely so that a change of direction costs weeks rather than months. What cannot be cheap is changing the basic premise, meaning the problem the system solves. That is why we insist so much on the stage before the code.
You do, from the first line written. You receive it as we go, not at the end, in a repository you control. We do not use proprietary components that would tie you to us. The test we apply to ourselves is simple: how long an outside developer would need to take the project over.
Yes, and it is often the best option. We can build and hand over with training, extend the team for a period, or take on a single component. We ask for one thing: a person on your side who can make decisions. Projects do not stall on technical problems, they stall waiting for approvals.
As a guide, between ten and twenty percent per year of the development cost, depending on complexity and how many external systems are involved. That covers dependency updates, security fixes, adaptations to changes in other systems, and monitoring. We give you the figure in writing before you sign, not in year two.
Tell us what is not working in your process. If the right answer is not to build, we tell you in the first conversation.