Someone on your team is the integration between two systems
Integrations, approval flows and document processing for companies paying for systems that do not talk to each other.
3–8 weeks from €16,000
This is for you if
- Somebody re-types the same data into a second system An order, a request or an invoice lands in one place, and a person copies it into another. Twice a day, most days. Once a week they get one wrong, and nobody finds out until it matters.
- Approvals live in email and chat You know a request was approved because someone remembers approving it. There is no list of what is waiting, no deadline on any of it, and no record of who decided what when somebody asks six months later.
- Documents arrive as attachments and a person files them Invoices, contracts, forms. Someone opens each one, reads the same three fields, types them somewhere, and moves the file to the right folder. The work is not hard, which is why nobody has ever costed it.
- You pay for two systems that do not know about each other Both licences are current. Both systems work. The connection between them is a person with a spreadsheet, and that person is the only one who knows which fields matter.
- A report exists because someone rebuilds it every month Same source, same steps, same day of the month. When they are on holiday the report is late, and when they leave the steps leave with them.
What we actually build
Records created in one system appear in the other without anyone re-typing them, with the matching rules written down and a list of what failed, so a mismatch is something you look at rather than something you discover.
A request moves through named states, each with a person responsible and a deadline, and every decision is recorded with who made it and when.
Files read on arrival, the fields you care about pulled out, checked against rules before they are accepted, and filed against the right record.
The report produced on a schedule from the data you already hold, in the format the recipient needs, delivered without anyone opening a spreadsheet.
Limits, thresholds and checks enforced by the software as something happens, rather than remembered by whoever is on shift.
Two systems kept in step, with the differences between them surfaced on a screen instead of found at the end of the quarter.
Work we have delivered in this category
Work in this category rarely produces something to look at. It produces an absence: the step nobody does any more, the email nobody sends, the spreadsheet nobody rebuilds. The clearest example is the transaction approval flow we built for Bitcoin Romania. A transaction goes into a pending list, appears in real time on a screen, and the approval comes back within seconds — instead of someone checking, deciding and telling the next person. The same client's ATM software was integrated with the systems around it and applies the limits Romanian legislation requires at the moment of the transaction, rather than leaving them to whoever is watching.
Bitcoin Romania
ATM for cryptocurrencies
Bitcoin Romania
Display for pending transactions
Bitcoin Romania
Romanian ATM Map for cryptocurrencies
How a project runs
-
Scoping Three to five days
We follow one case end to end — one order, one approval, one document — and write down every place a person touches it. That list is the work; the rest is deciding which parts are worth removing.
What you get: A written scope with the steps listed, the systems named, what happens on failure decided, and a price.
What we need from you: Access to whoever does this by hand today, and to someone who can get us into the systems involved.
-
The first flow, running Two to three weeks after scoping
We automate the single step that costs the most time, and run it beside the manual process rather than instead of it, so the two can be compared on real data.
What you get: One flow running in production, with the manual process still in place and a record of what the two produced.
What we need from you: Someone who will check the first week of output and tell us where it disagrees with what they would have done.
-
The rest, and the cases nobody mentioned The remainder of the project
Most of the work in this category is the exceptions: the supplier who sends a different format, the request that skips a step, the day the other system is down. We handle them one at a time, with you deciding what each should do.
What you get: The remaining steps automated, each with a defined behaviour when something is missing or wrong.
What we need from you: A decision on each exception. We can guess, but you know which ones matter.
-
What happens when it stops Ongoing, on a monthly agreement you can end
Automation fails quietly, which is what makes it dangerous. Before handover, every flow gets a check that it ran, an alert when it did not, and somewhere to see what it did.
What you get: Monitoring and alerting with a named recipient, a log of every run, and the code and infrastructure in your own accounts.
What we need from you: A decision on who receives the alert, and whether your own team takes it over.
What it costs, and what moves the number
Projects in this category start at €16,000 and run three to eight weeks. That is the shortest work we do, because it usually replaces a small number of steps rather than a whole system. You get a price before each phase begins.
- How many systems, and whether they will let us in
- A system with a documented API is one kind of work. A system where the only way out is a scheduled export is another, and one where the vendor charges for access is a third. Which of the three you have is the first thing we establish.
- What happens when something goes wrong
- The path where everything works is the quick part. Deciding what the system does when a record is rejected, a service is unavailable or a file arrives in the wrong format is most of the build.
- Whether the records match
- Two systems calling the same customer by two different names is normal. Deciding the rule that says these two are the same is a conversation with you, not a technical detail.
- Volume, and how often it runs
- A flow that runs nightly over a few hundred records and one that runs on every transaction are different systems, mostly in what happens when they fall behind.
- What has to be provable afterwards
- Where an auditor or a regulator will ask what happened and why, the record of each run is part of the build rather than something added later.
Questions we get at this point
Every flow reports that it ran, and raises an alert when it did not, to a person you name. The log shows what it processed and what it rejected, so the first question after a failure is answered before anyone has to ask it.
That is the common case, and it changes the method rather than the outcome — a scheduled export, a database read, or a file drop the system already produces. What it does change is the cost, so it is one of the first things we establish during scoping.
The parts that change most — thresholds, recipients, which cases need a human — are settings rather than code, so your own team edits them. When the process itself changes shape, that is a small piece of work, and you own the code either way.
If this is not quite your problem
Dashboards, admin platforms and workflow systems that give your team one place to work. Or a replacement for t...
Customer portals & platformsApplication flows, account areas and partner portals for companies whose customers, students or resellers curr...
New products & first versionsArchitecture, build and launch of a first version that goes into production — not a prototype that demos well...
