Enterprise software development

It covers the whole lifecycle: requirements analysis, architecture, development, quality assurance, deployment and the support that follows. What separates it from a smaller project is not the number of features but what has to be in place around them.

Three things usually decide whether an enterprise system succeeds: whether it holds the load you actually have, whether access is granular and traceable enough, and whether somebody else can run it later. The features are the easier part.

In practice that means a role-based permission model, audit logs, a data retention policy, load testing before production, and documentation good enough for your own team to take the system over.

Often it does not. If your process is not a competitive advantage and a product covers it, the product is cheaper and faster — and we will say so.

Building pays off when the process itself is what differentiates you; when configuring a product costs more than building one; or when licence fees grow with headcount faster than your revenue does. In a large organisation the third case is more common than people expect.

The other substantial argument is ownership. With a custom system the code and the business logic are yours, you are not dependent on somebody else’s roadmap, and you are not paying per seat. Frequently the right answer is in between: a product for the core, and a custom layer where you actually differentiate.

Yes, and almost always piece by piece rather than all at once. A full rewrite is the riskiest way to do it and we rarely recommend it.

We start from a code and database audit and write characterisation tests that pin down current behaviour — bugs included, because it has to be clear later which behaviour was intentional. Usually there is no original documentation, and that is the rule rather than the exception.

The new system then takes over capabilities one at a time, the old one keeps running alongside, and each part is retired only once its replacement has proved itself in production. Data migration is rehearsed against a copy of production data and every run has a written rollback plan. There is no planned downtime.

We estimate after discovery, not before. Without an architecture anyone has actually thought through, any number is invented — and that is especially true of an enterprise system, where the cost usually sits in integrations and compliance rather than in screens.

Discovery itself is a paid two-week sprint. Its output — process maps, a data model, an architecture, a risk list and a prioritised scope with an order-of-magnitude cost per phase — is yours even if you decide to give the build to somebody else.

From there we fix the budget and the timeline and keep the scope flexible. You know what it costs and when it lands; the priority order decides what fits inside. That is the only one of the three that can honestly be fixed.

Yes — and it is usually the most labour-intensive part of the project rather than a side task, so we plan it that way.

We integrate with ERP and accounting systems, CRMs, warehouse management, payment providers, banking interfaces and public registries, including the Estonian Business Register and eID services. Where there is no proper API, file exchange, database views or a scheduled import all work — and we will be honest about which of those is fragile and what it will cost you in maintenance.

Interfaces are built assuming the other side will sometimes be down, sometimes slow, and will occasionally send something unexpected: retries with increasing back-off, queues, idempotent writes, and monitoring that raises an alert before a customer calls. Versioned contracts mean a partner’s change cannot break you without warning.