The company runs on one shared spreadsheet
Several people open it, versions diverge, formulas break, and nobody is certain which copy is current.
An error in a shared file is usually discovered after it has reached the customer or the supplier.
Web & eCommerce
Automation & software
Bookings & scheduling
Sales & operations
Between the spreadsheet that no longer copes and the ERP that costs more than the problem, there is a gap. Most mid-sized companies live in it. That gap is what we build for.
We reply the same working day. No obligation.

Several people open it, versions diverge, formulas break, and nobody is certain which copy is current.
An error in a shared file is usually discovered after it has reached the customer or the supplier.
It covers the accounting side but not the part that makes your business specific, so the real work happens beside it.
Where is that order, what stock is committed, who approved it. The answer exists, but only in pieces.
Stock, orders and status in one place, so the answer is the same wherever it is asked.
The exceptions that make your business work are built in, not worked around.
Accounting, invoicing and eCommerce stay where they are and talk to the new system.
Everyone who needs access gets it, without a cost decision each time.
Not an ERP replacement. The layer that covers what the ERP does not and the spreadsheet cannot.
Multi-location stock, committed quantities, transfers, batches and stocktakes with real reconciliation.
Stages, capacity, materials consumed and deadlines, with the shop floor able to update status itself.
From order to picking to dispatch, with status visible to sales without asking the warehouse.
Purchase requests, expenses, leave or document sign-off, with thresholds and an audit trail.
Equipment, service intervals, interventions and costs, with scheduled maintenance reminders.
The most common starting point. We begin from the file itself, because it documents the real process.
Time in the warehouse, on the shop floor or in the office with the people doing it. The exceptions are never in the documentation.
Data model, rules, roles and integrations, with estimated hours per module and a suggested order of delivery.
The screens people use dozens of times a day, validated before development.
The highest-impact module first, in production and in use before the next one starts.
Existing data brought across, training by role, and close support through the first month.
Every standard product handles the normal case. Companies differ in their exceptions — the customer with different terms, the product measured differently, the approval that skips a step when the value is small. Those exceptions are exactly why the spreadsheet survived.
We do not replace your accounting system and we rarely replace an ERP. We build the operational layer that sits between them and the work — the part that is specific to your company, connected to the systems you keep, and shaped by rules that no vendor could have anticipated.
We have built stock synchronisation between management software and online stores covering hundreds of product lines, and ordering systems where the order reaches the operational screen the moment it is placed.
Worth knowing: if a standard ERP covers your operation, buy the ERP. This is worth building when the specific part of your business is where the value is, and when forcing it into a template would cost more in workarounds than in development.
Stock and prices resolved in one place and propagated to the store and to marketplaces, so you never sell what you do not have.
Suited to anyone selling through more than one channel.
Suppliers confirm orders, upload documents and update delivery dates themselves, in one place with a full history.
Suited when supplier coordination happens across hundreds of emails.
Documents read and filed automatically, unusual orders flagged, demand patterns surfaced from history.
Suited once the operational data is clean and centralised — not before.
| Shared spreadsheet | Standard ERP | Custom system | |
|---|---|---|---|
| Fits your exceptions | yes, manually | no | yes |
| Multi-user reliability | poor | good | good |
| Audit trail | none | yes | yes |
| Initial cost | none | medium to high | high |
| Licence per user | none | yes | none |
| Time to change a rule | minutes, unsafely | vendor dependent | days, safely |
Our rule: The order matters: first simplify the process, then automate it. Building software on top of a broken workflow makes the chaos faster and more expensive. If our analysis finds the process itself is the problem, we say so before quoting the build.
Internal systems rarely fail technically. They fail because the people doing the work found them slower than the method they replaced, and quietly went back.

A concrete example: in an ERP to eCommerce integration we built, stock and prices update automatically across hundreds of product lines — removing the daily reconciliation that used to be done by hand.
Operational systems delivered and used daily by real teams.






We work on an hourly rate: €50 per hour, excluding VAT. The price comes from the number of estimated hours rather than from a fixed package. You receive a proposal in which each module carries its estimated hours and cost.
No. This is a system built around how your organisation already works. We start from your workflow, your rules and your existing software, then build what fits. That is why it costs more than a subscription tool — and why people actually use it.
An approvals or records system takes 8–14 weeks. Stock or production management takes 12–20 weeks. We always deliver in modules, so the highest-impact part is in production and proving itself before the next one starts.
Usually not, and we would be cautious about anyone who says it will. We build the operational layer that covers what the ERP does not, and connect the two. Replacing an accounting system is a much larger decision with much less upside.
If it fits, buy it — that is genuinely the cheaper answer. We build custom when the specific part of your operation is where the value sits, and when forcing it into a template creates the workarounds that keep the spreadsheet alive.
Yes, and we usually start there, because the spreadsheet documents the real process better than any procedure manual. Migration is a separate stage with its own hours, since the duration depends on the state of the data.
By designing the repeated operations first and measuring them against the current method. If an action takes longer than it did before, we rebuild that screen. Adoption is a design problem, not a training problem.
It will, and the system is built for that. Rules that we expect to change are configurable rather than hard-coded, and we stay on for ongoing development. A system that cannot change becomes the next spreadsheet.
You do. Code, database, documentation and integrations, with no per-user licences. You can host it where you choose and move to another developer at any time.
Five steps, under two minutes. The more context you give us, the closer the estimate will be to reality.
ProjectStep 1 din 5
You can pick more than one.
You do not need a specification. Send us the spreadsheet everyone opens, or describe the process that keeps breaking. We reply with what we would build, in what order and with the estimated hours.
Get an estimateOr email us directly: contact@divasweb.ro+40 755 336 514