ERP–CRM sync: what happens when the API fails
A flow with fictional data showing a successful sync, an API failure and the recovery of the affected record.
Custom software development that connects your operation
When the process that runs your operation does not fit any tool on the market, building it is not a luxury. We write the scope down, deliver in phases, and the code is yours from the first one.
When building custom makes sense
And when it does not. If an existing tool fits your case we will say so: it is cheaper for you and avoids a project nobody wants to maintain.
The process lives in spreadsheets
Several people maintain by hand what should be a system. Errors surface at close and nobody knows which version is the good one.
The current tool hit its ceiling
The ERP or SaaS covers 70% and the remaining 30% is solved with manual exports, macros and email.
The process is your competitive edge
Bending it to fit a generic product means giving up exactly what sets you apart.
You need to connect systems that do not talk
The custom system is often, in truth, the layer that integrates what you already have.
Scope
What we build
Internal operations systems
Operations, inventory, quoting, approvals: the real flow, with the roles and permissions your organisation already has.
Integrations with what you already run
ERP, CRM, billing, logistics and payments. With error handling, retries and duplicate control, not a script that runs overnight.
See integrations : Integrations with what you already runCustomer and supplier portals
External access with authentication, role-based permissions and an audit trail of what each party did.
See web applications : Customer and supplier portalsOperational reporting
Information leaves the system without anyone exporting it and pasting it somewhere else.
Bounded automation and agents
When part of the process can run unattended, with explicit criteria and human review where it matters.
See AI agents : Bounded automation and agentsCustom commerce and catalogue
When the standard store cannot carry your pricing model, your stock rules or your logistics.
How we work
Five phases, each with its own deliverable. You can stop at the end of any of them and keep what was delivered: the code and the documentation are yours throughout.
- Written, accepted scope before the first line of code
- Code and infrastructure ownership for the client
- No dependency that forces you to stay with us
-
Discovery
We walk the process with the people who run it, not only with those who describe it. The edge cases surface — and edge cases are what sink projects.
Deliverable: Process map, risks and a build-or-not decision.
-
Phased scope
What goes into each phase, what stays out and how it will be accepted. Dates are committed per phase, never for the whole before discovery closes.
Deliverable: Scope document with phases, dates and acceptance criteria.
-
Build
We deliver reviewable increments. Each phase ends in an environment you can use, not in a recorded demo.
Deliverable: A deployed, working phase.
-
Validation
Tested against the agreed criteria, error paths and data migration included.
Deliverable: Executed tests, fixed issues and migrated data.
-
Handover and support
Repository, technical documentation, access and a handover session. Ongoing support is agreed separately and in writing.
Deliverable: Repository, documentation and a support agreement if there is one.
What it includes and what it does not
Written down before we start, so there are no surprises in the invoice or in the operation.
What it includes
- Discovery and a scope document with acceptance criteria
- Development, testing and deployment of each phase
- Agreed integrations with existing systems
- Technical documentation and handover of repository and access
- Defect fixes on delivered work during the agreed warranty period
What it excludes
- Third-party licences and external service subscriptions
- Infrastructure and its usage, billed by the provider directly
- Content, data and migrations from systems without documentation or access
- Scope changes that were not agreed: estimated as a new phase
- Ongoing support and operations without a support contract
Custom development is quoted by scope, not by a published rate: the same system can vary by an order of magnitude depending on integrations, migration and service level. The quote follows discovery and states what is included, what is excluded, and the phases with their dates.
Recurring third-party costs: Infrastructure, third-party licences and, if the project uses AI models, their usage. We estimate them before starting and present them separately from development.
Evidence
What we can show you
Internal demos built by Neterius and labelled as such. Client projects are under NDA.
A RAG AI agent that admits what it does not know
Queries the company knowledge, answers with sources, admits when it lacks enough information and hands off to a person.
Should I build custom or adapt an existing tool?
If a market tool covers the process with reasonable configuration, adapting it is cheaper and easier to maintain. Building custom is justified when the process is your competitive edge, when no tool supports your rules, or when the cost of workarounds exceeds the cost of building. We assess it during discovery and say so even when it means not selling the project.
How much does custom software development cost?
It depends on scope, which is why we publish no rate. The variables that move the price most are the number of integrations, data migration, security requirements and the service level afterwards. The quote follows discovery, broken down by phase.
Who owns the code?
The client does, from the first phase. At the end of each one we hand over the repository, documentation and access. We use no proprietary components that force you to stay with us.
What happens if the project stops midway?
You keep everything delivered and working up to that phase, plus its documentation. That is the reason for phased delivery rather than one final milestone.
Related services
API, ERP and CRM integrations that hold up when something fails
Synchronisation between systems with error handling, retries, duplicate control and monitoring.
Web applications that do something, not just get read
Portals, internal applications and platforms with roles, data, security and maintenance.
AI agents that are bounded, evaluated and hand off to a person
Agents connected to your sources and processes, with bounded actions, evaluation and human handoff.
Build it or adapt it?
Describe the process and what you expect to change. We will tell you whether a custom system, a bounded integration, or neither is the right call.