What this costs you today
The processes below are the ones that consume the most hours in this sector. Work out which apply to you, and the annual figure is the budget the manual version is already spending.
| Done by hand today | Hours / week | Cost / year | After automation |
|---|---|---|---|
| Retyping orders into the accounting system | 4–8 hrs | €4,600–€9,200 | Automated invoicing. The bigger saving is the transcription errors that currently surface at month end. |
| Reconciling stock across sales channels | 3–6 hrs | €3,450–€6,900 | Event-driven inventory sync, which also removes the overselling that estimated availability produces in peak weeks. |
| Answering “where is my order” | 3–5 hrs | €3,450–€5,750 | One order record with real status, so the answer takes one lookup instead of three. |
Annual figures are the stated weekly hours multiplied by 46 working weeks at a €25 hourly loaded cost. They are arithmetic on a typical range, not results measured at a client — substitute your own hours and rate for a figure that means something.
Operations platform with accounting and webshop sync
I have built an internal operations platform covering orders, inventory availability, reservations, warehouse work, accounting-system invoicing orchestration and webshop synchronisation, on a Next.js and ASP.NET Core stack with PostgreSQL and a dedicated connector for the on-premises accounting system.
Where the time actually goes
Overselling stock you do not have
When channel inventory updates on a schedule rather than on an event, you sell items that left the shelf an hour ago. The cost is refunds and reputation, not just the order.
Manual invoice creation
Orders retyped into an accounting system by hand. Slow, error-prone, and the errors are financial ones that surface at month end.
No single view of an order
Status lives in the webshop, the courier portal and someone’s inbox. Answering “where is my order” takes three lookups.
Reordering by intuition
Purchasing decisions made from memory and a stock count, rather than from actual velocity and lead times.
What gets built
Order orchestration end to end
One pipeline from checkout through availability check, reservation, warehouse task and invoice, with each step recorded and retryable rather than fire-and-forget.
Live inventory sync across channels
Stock levels reconciled between the warehouse and every sales channel on events rather than on a nightly cron, so availability is true when the customer sees it.
Automated invoicing into your accounting system
Orders posted into the accounting package automatically, with failures surfaced and requeued instead of silently dropped.
Purchasing and reorder signals
Velocity, lead time and current cover computed continuously, so reorder points come from data rather than from a hunch.
Operations dashboard
Orders, exceptions, stock cover and integration health on one screen, so the failures are visible before a customer reports them.
Services that fit this sector
The service lines that solve the problems above, in the order they usually get built.
Making the tools you already run behave as one system.
Operations software for businesses that have outgrown spreadsheets but not into SAP.
Decision-ready dashboards built on reliable data, not another layer of spreadsheet confusion.
Production-grade pipelines that ingest, transform, and serve data reliably at scale.
Visual automation that a developer can maintain and a non-developer can understand.
How a project runs
The same sequence every time, whichever service or market is involved. It is deliberately front-loaded: most of the risk in an automation project sits in understanding the process, not in building it.
Map the process before writing anything
The first session is spent on how the work actually happens, which is almost never how the documented process says it happens. Who touches what, in which order, and where the time really goes. Most failed automation projects failed here rather than in the build, because they automated the described process instead of the real one.
Measure the cost of doing nothing
Hours per week, error rate, and what those hours would otherwise be worth. This is what decides whether a process is worth automating at all — and it is also the number you compare against afterwards, which is why it gets recorded before anything is built rather than estimated after.
Build the smallest useful version
One process, working end to end, in production, before anything else starts. A narrow system that people actually use beats a broad one that waits on a second phase, and the edge cases that matter only surface once real work runs through it.
Run it against reality
The first two weeks of live use produce more design corrections than any amount of planning. Failures get surfaced loudly, retried and logged, because silent failure is the most expensive property a workflow can have and the one noticed last.
Hand it over properly
Documentation, credentials, and a walkthrough with whoever will maintain it. A system only one person understands is a liability regardless of how well it runs, so handover is part of the work rather than an optional extra at the end.
Ways to work together
Three arrangements cover almost every engagement. Most start with the first or the second; the third only makes sense once something is live.
Fixed-scope project
One defined process, a fixed price and an agreed definition of done. The right fit when the problem is clear and bounded — an order flow to connect, a CRM to build, a reporting pack to automate. Most first engagements are this, because it lets both sides find out how the other works without a long commitment.
Assessment first
One to two weeks mapping processes and measuring where the hours actually go, ending in a ranked list with effort and payback estimates. Useful when there is a backlog of automation ideas and no agreement on which matters. The document stands on its own and is yours whether or not you build anything with me.
Ongoing retainer
A recurring block of time for maintenance, extension and new automations once systems are live. Integrations break when the systems either side of them change, and a retainer means that gets fixed before it becomes an outage rather than after.
How the working relationship is set up
Remote, with real overlap
Work is delivered remotely. Across Europe and the Nordics the working day is effectively identical; in the Gulf it starts three hours ahead, which still leaves your full morning covered. There is no local office in any market, and none is claimed anywhere on this site.
You own what gets built
Source code, infrastructure and data stay yours. Systems are deployed on infrastructure you control — your server, a European provider, or a VPS in your own account. There is no per-seat licence and no dependency on me continuing to be involved.
Self-hosting is a first-class option
Self-hosted n8n, self-hosted databases and locally run models are all supported and, in several of these markets, preferred. Where no data may reach a third-party API, that constraint shapes the architecture from the start rather than being retrofitted.
Direct contact, one person
You deal with the person building the system. There is no account manager relaying requirements, which is the main practical advantage an independent consultant has over an agency at this size — and the main reason scope stays honest.
Frequently asked questions
Do you work with our existing webshop platform?
Yes. The integration layer is built against whatever your platform exposes — REST, webhooks or a database. Replacing the shop is almost never the right first move; making it talk correctly to the warehouse and the accounting system usually is.
What happens when an integration fails at 2am?
It retries, and if it still fails it lands in a queue with the error attached and an alert raised, rather than disappearing. Silent failure is the single most expensive property of hand-rolled integrations, so the systems I build are designed to fail loudly and recover.
Can this connect to an on-premises accounting system?
Yes, through an isolated outbound connector rather than by exposing the accounting server. That pattern keeps the finance system behind its own boundary while still letting the order flow reach it.
What if we are not sure automation is the right answer?
Then the assessment is the right starting point, and it is designed to be able to conclude that you should not automate something. A process that is broken should be fixed before it is automated, and one that runs twice a month rarely earns the build. Receiving that answer in week one is far cheaper than discovering it after a project.
We have been burned by a failed automation project before.
That is common, and the cause is usually scoping or adoption rather than technology — a system built for the documented process rather than the real one, or one nobody was trained to maintain. Both are addressed by mapping the real process first and treating handover as part of the work.
How do we avoid depending on one person?
By owning everything: source code, infrastructure, credentials and documentation, with a walkthrough for whoever maintains it. The test is whether another developer could pick the system up from the repository and the documentation alone, and that is the standard handover is written to.
Is our data safe?
It stays where you need it to. Systems can run entirely inside your own infrastructure, including self-hosted models where no data may reach a third-party API. Where GDPR applies, data stays in the EU by default, with named access control and audit logging as standard rather than as an upgrade.
How quickly can something be running?
A first working version of a single process is typically weeks rather than months. Larger platforms are sequenced as modules so something is in production early and the rest builds on a foundation that already survives real use.