VMTech
Discuss a project
← All services
VMTECH · SERVICE

When ready-made products no longer fit and the spreadsheet gives up

People rarely arrive here by choice: the process rests on one spreadsheet that one person understands, and as the business grows that becomes a risk.

Discuss the task
app.example.rs
The company's internal system
LIVE
in production
Mapping the process 7 roles
Scope of version one scope fixed
Prototype approved
A working version in trial use
Refinement from feedback 14 changes
Handover and evolution in production
HOW WE WORK
  1. Mapping the processWe walk the whole workflow: who does what, where data lives and why it is awkward today
  2. Scope of version oneWe agree what goes in now and what waits — so launch is not postponed indefinitely
  3. PrototypeClickable screens where the logic is visible before code exists
  4. A working versionThe core of the process runs on real data and part of the team starts using it
  5. Refinement from feedbackWe fix what gets in the way in real work rather than what looked important on paper
  6. Handover and evolutionCode, documentation and access are yours; further stages happen as they are needed
HOW WE WORK

From mapping the process to a system in use

app.example.rs
The company's internal system
OK
Mapping the process 7 roles
Scope of version one scope fixed
Prototype approved
A working version in trial use
Refinement from feedback 14 changes
Handover and evolution in production

Mapping the processWe walk the whole workflow: who does what, where data lives and why it is awkward today

Scope of version oneWe agree what goes in now and what waits — so launch is not postponed indefinitely

PrototypeClickable screens where the logic is visible before code exists

A working versionThe core of the process runs on real data and part of the team starts using it

Refinement from feedbackWe fix what gets in the way in real work rather than what looked important on paper

Handover and evolutionCode, documentation and access are yours; further stages happen as they are needed

WHEN THIS IS NEEDED

Signs the process has outgrown improvised tools

How it works now

  • A key process lives in a spreadsheet several people edit at once
  • One person does the calculation, and nobody can cover them on holiday
  • Data is copied between three programs and at some point they diverge
  • An off-the-shelf system is expensive and still misses the main thing — your specifics
  • Every new employee learns from verbal explanations rather than from the system

Once the process lives in a system

  • The calculation rules are written in code rather than in one person's head
  • Every action is visible: who changed what, and when
  • Data is entered once and does not drift between systems
  • A new employee learns by using the system — it sets the order of steps
  • The system can evolve: it is yours rather than rented from a vendor
WHAT THE PROJECT INCLUDES

Scope of work

Process mapping

Interviews with the people doing the work and a description of how things actually run.

Version one scope

What ships now to deliver value quickly, and what is postponed on purpose.

Data model

Entities, relations, access rights and change history — the foundation that is expensive to redo later.

Role-based interface

Different screens for different roles: each sees what they need rather than everything.

Integrations

Links to the site, CRM, accounting, payments or equipment — as required.

Reports

The numbers the whole thing was started for — with export for those who live in spreadsheets.

Tests

Automated checks of the key calculations and journeys, so updates do not break what works.

Handover and support

Code, documentation, access and training — the system can be handed to another team.

HOW WE BUILD IT

Principles rather than a pile of fashionable tech

A maintainable stackPHP, PostgreSQL and a conventional front-end — another team can maintain it
Change historyWho changed a record and when — in a dispute that matters more than any report
Role-based rightsAccess is limited by role rather than by how much an employee is trusted
Data exportYour data can always be exported — the system does not hold it hostage
Tests and releasesUpdates are verified automatically and can be rolled back
DocumentationA description of the model and the decisions — so in a year it is clear why it is built this way

Code, data and access belong to you from day one. We do not build systems that cannot be handed to another contractor: that is bad engineering, not client retention.

QUESTIONS

What people usually ask

How do you estimate when the task is not fully clear yet?

As a small separate stage: mapping the process and describing version one. It produces a clear scope, an estimate and a prototype you can either build on or stop at. That is more honest than naming a figure blind and later explaining why it doubled.

Would buying a ready-made system be simpler?

Often yes, and we will say so if we see a product that fits: custom development for a problem someone already solved is wasted money. A bespoke project is justified where the specifics are the substance of your advantage, not where someone simply wants it their own way.

What if we want to change contractor?

Nothing dramatic. The code is in your repository, the documentation describes the data model and the decisions, and the access is yours. We deliberately avoid exotic choices that would require hunting for a rare specialist.

How long until it is actually useful?

We aim to launch the core of the process within the first weeks, even in a narrow form: one role, one scenario, real data. That shows whether the idea works before months are sunk into it. The rest is added on top of something working rather than instead of it.

Who maintains the system afterwards?

Usually we do, under a separate agreement with a defined scope and response times. But it is not a condition: the system is built so your own developer can run it. We hand the project over with its documentation rather than locking it to ourselves.