The same data has two truths
Stock is 42 in the shop system and 39 in the online store. Someone reconciles it by hand every evening, and both numbers are wrong by morning.
Services
Software integrations and existing-system customization
Most businesses do not need another system. They need the two they already own to agree on what a customer, an order and a payment are. Integration work starts with that agreement — the data contract — not with the API call. When the systems disagree, no amount of retrying fixes it.
Who it is for
- Businesses already running two systems that hold overlapping data.
- Teams exporting to a spreadsheet every morning to bridge a gap.
- Companies told by a vendor that the system cannot be extended.
Problems it solves
A person is the integration
Export, rename, upload, retype. It works until that person is away, and it silently breaks long before anyone notices.
The system is declared closed
A vendor says there is no API. There is often a database, a scheduled export, or a webhook that was never documented.
Use cases
Stock between the shop and the online store
One direction decided, one written rule for the other, and a nightly reconciliation report that names every difference.
Requests into the CRM
Website forms, chat and phone notes create one record, with a source field that tells you what works.
Payments and accounting
Invoices and payments reach the accountant in the format they already accept, with a reference back to the order.
Notifications that mean something
A customer gets a message when the status actually changes — not every time a row is touched.
What is in scope
Fixed scope. Fixed price.
Agreed in writing before anything is built. You approve before we start.
- A written data contract: fields, owners and the canonical record
- Field mapping, including the edge cases that break naive mappings
- The integration itself, with retries, backoff and idempotency
- A visible failure state, with an alert someone actually reads
- A dry-run mode and a parallel run before the switch-over
- Documentation: what syncs, when, in which direction, and what to do when it stops
How it is delivered
- 01
Name the canonical record
One system owns the customer, one owns the stock. Deciding this first prevents an endless argument later.
- 02
Map the fields, including the ugly ones
Two date formats, a phone number stored three ways, a status that means something different in each system.
- 03
Run it dry before it runs live
A dry run that logs what it would have written, and a parallel period where both systems are checked against each other.
- 04
Make failure loud
An integration that fails silently is worse than a manual step, because nobody knows to do the manual step.
FAQ
Questions about this service.
What owners usually ask before requesting a quote for it.
What if the system has no API?
There are fallbacks: a read-only database view, a scheduled file export, or screen-level automation as a last resort. Each has a cost, and we will tell you which one we are recommending and why.
How do you prevent duplicate orders?
Every write carries a stable key, and the receiving side refuses a key it has already seen. Retrying then becomes safe instead of dangerous.
Will you customize the existing system or replace it?
Customize when the system is sound and the change is bounded. Replace only when the workaround costs more than the migration — and we will show the comparison rather than assert it.
Who owns the integration code?
You do, including the field mapping document — which is the part that is actually hard to reproduce.
Start a project
Want this scoped for your business?
Send the brief. It comes back as a written scope and a fixed quote before anything is built.