01Mapping the processWe walk the whole workflow: who does what, where data lives and why it is awkward today
02Scope of version oneWe agree what goes in now and what waits — so launch is not postponed indefinitely
03PrototypeClickable screens where the logic is visible before code exists
04A working versionThe core of the process runs on real data and part of the team starts using it
05Refinement from feedbackWe fix what gets in the way in real work rather than what looked important on paper
06Handover 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 itChange historyWho changed a record and when — in a dispute that matters more than any reportRole-based rightsAccess is limited by role rather than by how much an employee is trustedData exportYour data can always be exported — the system does not hold it hostageTests and releasesUpdates are verified automatically and can be rolled backDocumentationA 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.