When should you choose custom software over a market product?

When what differentiates your organisation does not fit the standard product, your access rules cannot be expressed in it, or each vendor update breaks customisations you have already paid for. In short, when important needs cannot be represented correctly without expensive workarounds.

How soon can people start using it?

Sooner than the time needed to deliver everything—and deliberately so. We deliver by business domain, allowing teams to work in the first part of the system while the next is built. The condition of current data usually has the greatest effect on this timeline.

How is our data migrated?

We identify every source, write the quality rules the data must meet, run migration rehearsals and compare results before cutover. Incorrect data entering the new system can remain incorrect for a long time.

Can we keep tools we already use?

Yes, provided they can exchange information. We define exactly what moves, who owns each responsibility, what happens on error and how recovery works.

How do you handle complicated access rights?

Every role is connected to permitted actions and visible data. Sensitive cases—such as approving a value or viewing confidential information—receive dedicated controls and audit records.

What if our needs change during the engagement?

That is expected. Delivery is progressive, and every stage is decided using what is known at that point. Changing direction between stages costs far less than freezing every decision at the start.

Business management systems

Custom CRM and ERP systems

A CRM follows commercial relationships: who contacted you, where every opportunity stands, who needs to follow up and when. An ERP runs the organisation behind them: orders, inventory, purchasing, production and billing.

When off-the-shelf software forces you to work in ways that do not reflect your business, we build a system around your processes, responsibilities and data.

Standard or custom

Why not use an off-the-shelf product?

That is the first question to answer before committing to a build. A market product is usually enough when your processes resemble those of your sector, required changes fit its intended configuration and you can accept the way it expects work to be done.

Custom development is justified in four situations.

What differentiates your organisation does not fit the standard product.
You have already paid for several customisations that break whenever the vendor updates the product.
Your permission rules cannot be expressed through the roles provided.
Your teams maintain a spreadsheet alongside the software—the most dependable warning sign.

What we build

Your operating cycles

Modelling for sales, operations, purchasing, billing and service, limited to the cycles that actually concern your organisation.

Records and automation

Work views, alerts and automations, with a safeguard whenever a machine makes a decision in someone’s place.

Access rights

By role, team, operating scope or confidentiality level.

Dashboards

Built from definitions everyone shares, so two departments do not calculate the same indicator and produce different results.

Connections

Your accounting, communications, reference data and partner portals.

Data migration

A migration plan, quality rules and verification before cutover.

Data and permissions

Data, access and traceability

Every piece of information has one authoritative source, and we make dependencies visible. Without that rule, the same value exists in three places and nobody knows which one is correct.

Authorisation is verified on two levels: what someone is allowed to do and which data they are allowed to see. These controls remain separate because a misplaced read permission can expose salaries across an organisation.

Sensitive events can be recorded: who viewed, approved or changed something and in what context. This provides evidence for an audit—or simply explains what happened.

Adoption

The system must survive its first Monday

A technically perfect CRM or ERP that nobody uses is worthless. It is the most frequent way these projects fail, and the cause is not technical. We work with the people who will use the system, not only those purchasing it.

Representative users validate journeys during construction, not at delivery.
Everyday actions repeated dozens of times take priority over rare functions.
Cutover happens in groups so the first users can support those who follow.

Documentation covers business rules, administration, interfaces and the procedure to follow when something is blocked.

The stages

Assessment

Your processes, daily sources of friction and where your data currently comes from.

Prioritisation

Together we decide which domain comes first and what the target looks like. Everything does not need to arrive at once.

Prototyping

Critical journeys are modelled and tested with operational owners.

Delivery

Staged launch, controlled migration and support for your teams.

What it costs

What determines the budget

We do not publish a list price. Two projects that look similar from a distance can differ fourfold in effort.

The number of business domains covered.
The level of detail in your business rules.
The complexity of access rights.
The number of reports and indicators.
The systems to connect and their condition.
The condition of your current data—usually the most underestimated item.

We make these factors explicit so you can distinguish the essential foundation, optional capabilities and work that belongs in a later phase.

Systems delivered

Association BVH

Members, donors, projects, tasks, accounting and document management in a single system where no market product covered the complete need. A multi-user SaaS platform built with React and an integrated AI chatbot.

Beton en ligne

Remote concrete sales for individuals and small contractors. The public website and order-management back office were designed together. React development, managed operations and maintenance.

“It made it possible to deliver my project exactly as I imagined it—if not better.”

Questions

When should you choose custom software over a market product?: When what differentiates your organisation does not fit the standard product, your access rules cannot be expressed in it, or each vendor update breaks customisations you have already paid for. In short, when important needs cannot be represented correctly without expensive workarounds.
How soon can people start using it?: Sooner than the time needed to deliver everything—and deliberately so. We deliver by business domain, allowing teams to work in the first part of the system while the next is built. The condition of current data usually has the greatest effect on this timeline.
How is our data migrated?: We identify every source, write the quality rules the data must meet, run migration rehearsals and compare results before cutover. Incorrect data entering the new system can remain incorrect for a long time.
Can we keep tools we already use?: Yes, provided they can exchange information. We define exactly what moves, who owns each responsibility, what happens on error and how recovery works.
How do you handle complicated access rights?: Every role is connected to permitted actions and visible data. Sensitive cases—such as approving a value or viewing confidential information—receive dedicated controls and audit records.
What if our needs change during the engagement?: That is expected. Delivery is progressive, and every stage is decided using what is known at that point. Changing direction between stages costs far less than freezing every decision at the start.

Clarify your processes and priorities

Tell us about your processes, current tools and what is blocking progress. We will explain whether a market product is sufficient—and, if not, which domain should come first.