A day in the user's boots
A few future users walk us through today's routine on a video call, phone in hand or screen shared. Quite often the real bottleneck turns out to be somewhere other than the one named in the meeting room.
Take a Murska Sobota civil engineering contractor running seventy machines across sites in Pomurje. Foremen report breakdowns on Viber, by email or over coffee in the site cabin, mechanics receive printed lists from a spreadsheet, and the only person who knows when each excavator is due for servicing goes on leave in two months. The managing director says, “We need an app.” Perhaps. Perhaps a well-built list in Microsoft 365 and a clear rule about who logs what would do. So our opening move is questions, not code. Where does information go missing? How long does it currently take from breakdown to mechanic? What would have to change for you to call the spend worthwhile? Only with answers and a baseline figure in hand do we propose the leanest release that already fixes the pain, give it to a handful of real users and grow it according to what the numbers show. Each phase carries its own quote and its own deliverable, which you keep. It all runs over video calls and shared screens; nobody needs to visit a site when phone clips and a chat with the people doing the job tell us what we need.
What the road from concept to daily tool involves. Each piece is documented clearly enough for a different supplier to follow.
A few future users walk us through today's routine on a video call, phone in hand or screen shared. Quite often the real bottleneck turns out to be somewhere other than the one named in the meeting room.
Before building, we quantify the status quo: weekly hours lost to retyping, jobs that slip through, days until a response. Without that starting point nobody can later prove the new tool helped.
Would a Pantheon or Metakocka module, a SaaS product or Microsoft Lists with Power Automate be enough? We test those seriously and only recommend bespoke work once they clearly fall short.
Who uses it, the three to five things it must do and what it deliberately leaves out, all on one sheet. Everything else waits its turn.
Tappable screens are tried by users on their own devices. Fixing a broken flow here takes hours rather than weeks.
Laravel and Vue, PostgreSQL, automated tests and a CI pipeline, with every significant choice logged alongside a short reason. Whoever maintains it five years on will know why it looks the way it does.
Where personal data is involved, roles and retention are part of the GDPR-aware design. Where invoices are produced, they follow eSLOG 2.0 for sending through the exchange provider you already use.
You call it at the close of each phase: continue, adjust or stop. The next phase is only estimated once the findings of the current one are known.
Interviews, baseline, cheaper options checked and the release-one scope. The document stays yours whether or not we continue.
Clickable screens and two rounds of user testing, then sign-off on release one.
A small group uses the system for real work, with a new build and a brief demo every fortnight.
We remeasure what was measured at the start and decide jointly on further features and upkeep.
Measure where you stand before ordering anything. Spend a week recording how long the target task takes and how often something is lost or duplicated. Without that figure, six months from now you will only have a feeling that things improved. With it, you will know whether the investment paid back and have firm ground for deciding on the next phase.
It is a fixed, pre-agreed price that depends on how many users and processes we examine, usually a few days of effort. You receive the quote after a short introductory call, before committing to anything.
That is fine. The findings, baseline and release-one scope belong to you and can go to any supplier or to your own developers.
We encourage it. Your administrator or developer gets repository access, the test environment and the fortnightly demos, so knowledge of the system stays inside your company too.
That depends on the scope fixed during research. We keep release one deliberately small so it reaches users early. A firm timeline comes with the estimate at the end of research, not before.
Transfer of the right to use and modify the code is written into the contract before development begins. The repository sits in your account, so you can see and keep the code at all times. Have your lawyer review the scope of rights before signing.
Which task eats up the most time, and who handles it today? We will reply with a research proposal and its price.
Enquiry received
An engineer will write back no later than the following working day. Faults that leave your staff unable to work are always looked at first.
No town by that name here. Check the letters, or settle for the nearest larger place. Our engineers work only over the internet, so Kočevje and Koper get precisely the same treatment.