What we build
Software integrations and API development
Most businesses do not need another system. They need the four they already pay for to stop being four separate islands with a person rowing between them.
What it is
An integration moves information between two systems so nobody has to. The booking lands in the calendar, the paid invoice lands in the accounts, the enquiry lands in the CRM, and the record in each one agrees with the others.
Where a system has no interface worth using, the work is to build one: an API for your own data, or a webhook that tells another system the moment something changes. That is also what makes your own software something other tools can be connected to later.
When a business needs one
- The same information is typed into two systems by the same person
- A monthly export and import is somebody's recurring calendar entry
- Two systems disagree and nobody can say which is right
- A tool you pay for cannot see the thing that happened in the other tool you pay for
- An automation broke silently and was found out weeks later
What we can build
Capability, not a claim about work already delivered. What we have actually built and run is further down the page.
- Connections between the systems you already run, in whichever direction is useful
- Data synchronisation that survives one side being down, rather than losing the change
- Webhooks, so something happens the moment it happens rather than on the hour
- APIs on your own systems, for your other tools or for a partner to build against
- Import and migration from a system you are leaving, duplicates resolved as part of it
- Monitoring, so a job that stops working says so rather than failing quietly
- A record of what moved and when, for the times when somebody asks
How we approach it
The first question is always whether the integration should exist. Two systems that disagree are often better replaced by one that does not, and the integration would have been an expensive way to preserve a problem.
Everything we build assumes the other side will fail at some point, because it will. Retries, a queue and an alert to a person are cheaper to build at the start than to add after the week somebody lost data.
Things we have already built
Live in software we have delivered, and part of the 123 things we have built.
A booking form that files itself into the system you already run on
An enquiry arrives already filed where the team works, so nothing is retyped and nothing is lost between the two.
The event lands in the calendar you actually check
You turn up, because the thing you committed to is in the calendar you actually run your week from.
Automations that tell you when they stop working
A broken automation announces itself the same day instead of being discovered by a customer.
A reply that finds its way back to the right job
A reply lands against the right job on its own, so a real answer never gets buried.
Multi-step booking with email and planner sync
Every enquiry is captured, confirmed by email, and dropped straight into the booking system, so no lead slips through the cracks.
Everything out to a spreadsheet, without handing over a weapon
Your data is yours to take out, and the file you send a client cannot execute something on their machine.
Your contacts are yours to take with you
You build on something you can walk away from, which is the only kind worth building on.
Related to this
Tell us what you are trying to fix
Describe the job in your own words and we will tell you what we would build, roughly what it would cost, and whether something you can already buy would do it cheaper.