METHOD / HOW WE WORK
Most systems do not fail on the code.
They fail where the software has to meet reality: the existing systems, the exceptions, and the people who use it every day. This page is about how we work at that point.
01 / The starting point
First we look at what is actually there.
There is no operating company where the process runs exactly as the documentation says. There is an ERP nobody has touched for years. There are interfaces whose author no longer works here. And there is a spreadsheet without which operations would stop tomorrow.
WHAT YOU ACTUALLY HAVE
And a new system has to fit into this — without downtime.
This is not a failure — it is the starting state. Every growing company looks like this, and design has to begin here rather than from an ideal picture.
02 / The gap
The demo was good. The consultant explained it. The specification exists. And it still does not work.
It was built, and in its own environment it is flawless. But your ERP was not among the test data.
An accurate assessment and a roadmap. But implementation remains someone else’s job.
It describes what is needed. But nobody wrote down the exceptions, because those only appear in use.
All three are useful. None of them carries the system into production.
03 / The work
We go in among the systems.
- 01
We talk to the people who use it
Not only to the decision-maker. To the dispatcher, the technician, and the colleague who retypes data from one system into another every morning.
- 02
We look for the exceptions
The normal case is usually simple. Projects stand or fall on the exceptions: the incorrect order, the returned shipment, the one client whose billing works differently.
- 03
We work inside your existing systems
Not remotely, from a specification. On your database, with your interfaces, inside your access model — within the real constraints.
- 04
We finish in production
Not at handover. Real users, real data, and during hypercare we fix things instead of you reporting them.
04 / The outcome
A working system — and a capability you can take over.
FROM INTERFACE TO INFRASTRUCTURE · ONE LINE OF ACCOUNTABILITY
01 / INTERFACEWEB + MOBILEUSERS AND DEVICES
HTTPS
02 / COREAPI + BACKENDBUSINESS LOGIC
SQL
03 / INTEGRATIONEXISTING SYSTEMSERP · SQL · LEGACY
CLOUDPRIVATE SERVERON-PREMISE
Running in production, integrated with the existing environment, documented, in your own repository.
The organisation understands how it works. There is a runbook, an architecture description and an operational handover. That is a design goal, not a by-product.
05 / Three roles
THREE ROLES, THREE DIFFERENT JOBS
- A SOFTWARE ENGINEERBUILDSthe product.
- A CONSULTANTEXPLAINSthe product.
- A FORWARD DEPLOYED ENGINEERMAKES IT WORKfor your exact problem.
A forward deployed engineer is an established role in the technology industry — it became known at Palantir and is now common at AI companies. It is the engineer who does not build remotely from a specification, but works inside the client’s real systems and processes, and takes the solution to a working state there. That is how Tokodi Software works.
06 / Comparison
Four ways to solve a business problem. They are not interchangeable.
| Off-the-shelf SaaS | Development capacity | Project agency | Tokodi Software | |
|---|---|---|---|---|
| Best when | the process is standard | the task is narrow and specified | a large team is needed quickly | integration, complexity or data location is the hard part |
| Custom web and mobile | limited | yes | yes | yes |
| Dedicated API and backend | no | depends on scope | yes | yes |
| Legacy ERP / SQL integration | limited | depends on scope | yes | yes |
| Private infrastructure / on-premise | rarely | depends on scope | depends on vendor | yes |
| Senior engineering ownership throughout | — | depends on capacity | depends on team | yes |
| Supplier-readiness evidence | depends on vendor | rarely included | depends on vendor | yes |
| Transferable documentation and runbook | depends on vendor | must be requested | depends on project | yes |
This comparison is a decision aid, not a ranking: for a standard process, a packaged product is often the right choice. Tokodi Software adds the most value where system boundaries, integrations, operations and compliance requirements must be handled together.
07 / Infrastructure
The same system, on whichever infrastructure you are allowed to use.
| Operations | Data location | Choose this when | |
|---|---|---|---|
| Managed cloud | fully managed | selected EU region | Fastest start and flexible scaling |
| Private / VPS | managed or shared | dedicated infrastructure | Greater infrastructure and data control |
| On-premise | internal IT or supported | entirely within the organisation | Data or systems cannot leave the organisation |
| Hybrid | shared responsibility | sensitive data stays local | Cloud interfaces with local ERP and sensitive data |
08 / Next step
Show us how you work today.
We are not asking for a presentation or a specification. It is enough to walk us through one day: what happens in the morning, where it stalls, and what has to be filled in by hand. Thirty minutes is enough to establish whether building anything is justified at all.
Book a 30-minute technical call← All work