IN DEVELOPMENT - OPEN TO EARLY COMPANIES
Work orders, clients and equipment records in one place - with a record of who did what, and when. The office side works and is already being used. The phone side, for technicians on site, is what we are building now.
Open an account and use it as it grows. What you tell us goes into how the application works - while changing it is still cheap.
Open an account What it does today
We are not selling a finished tool. This page says exactly what works today and what is still being built.
A service company doesn't buy a "work order module". It buys an end to nobody knowing who went where and what they did. Here is what that looks like while it's run on notebooks and messages:
| Today | What it means in practice |
|---|---|
| Nobody knows who went where and what they did | The write-up happens in the evening, from memory - or never. |
| Nobody knows what the technician took and brought back | Parts "disappear" between the van and the store room. |
| Periodic servicing doesn't schedule itself | A job that gets forgotten is a job that never gets invoiced. |
| The history of a unit lives in paper folders | On a warranty claim, nobody knows what was done before. |
| Clients get entered when someone remembers | Duplicate clients and wrong invoices. |
None of this is fixed by handing people one more form to fill in. It is fixed by making the entry faster than writing it on paper - otherwise the application simply gets bypassed.
Everything below exists as a screen you log into and use. Each item names the address of that screen in the application - so it's clear this is not an announcement.
If the form asks for ten fields, the dispatcher fills it in later - and "later" means a scrap of paper. So only the client and a description are required. Type defaults to "service" and priority to "normal" until told otherwise; the deadline and the technician sit folded away below, for whoever already knows them.
A new client is entered in the same form - no second screen, no interrupting the call.
screen: /app/nalozi/nov
A technician opens the list and sees his own orders - including the ones where he is only helping out, marked as such. Dispatchers and administrators see every order in the company.
Deadline and priority can only be changed by whoever schedules the work. A technician isn't shown those two as editable fields - otherwise "urgent" would mean whatever each person decides it means.
screen: /app/nalozi
Big jobs go out two or three handed. When everyone is assigned, nobody is - and the order stays open because each of them assumes the other will close it.
The crew is picked when the work is scheduled, but there is exactly one holder. That rule lives in the database itself, not in screen code: two holders on one order physically cannot be recorded.
screen: /app/planiranje
"How many hours do we have to be there?" is usually known by one person in the company - which becomes a problem the week they're on holiday.
Contract type, validity, coverage and the agreed response time in hours sit on the client's record. The response time also shows as a column while work is being scheduled - right where you decide whose job goes first.
screen: /app/klijenti
A deleted client takes the history of every order done for them along with it. So nothing is deleted: clients, units of equipment, vehicles, external repair partners, units of measure and mailing lists are archived and can be brought back.
An order isn't deleted either - it is cancelled, with a reason that is mandatory and stays on record. Only a dispatcher or an administrator may cancel.
screens: /app/klijenti · /app/oprema
Not "12 readers", but twelve units, each with its own label. Your internal label is unique across the company - including archived units, so a number can never be issued twice.
Each unit carries the manufacturer's serial number, make and model, location, condition (in use / in for repair / scrapped) and which client it is installed at.
screen: /app/oprema
A unit goes off to an authorised repair shop and vanishes from view - while the client still calls you.
So there's a directory of external repair partners and a company-wide decision on who services what. A forwarded order gets its own state - "forwarded", neither finished nor on hold - and a "waiting on an external service" row appears in scheduling, with the number of days. The report that comes back is written onto that same order.
screen: /app/spoljni-servisi
Nobody types a sixteen-character password standing in the rain. An administrator prints a QR code for that person; scanning it with the phone opens the sign-in.
The code is valid for 72 hours, can be used once, and issuing a new one immediately kills the old - a lost printout stops working that second. The code is drawn inside the application itself: no data goes to a third party to produce the image.
screen: /app/korisnici
None of this shows in a screenshot, and all of it decides whether the software can be trusted once it holds three years of work.
The most expensive failure in software like this is one forgotten condition in one query - and one company's data shows up in front of another.
So the per-company filter is not in the screens but in the data access layer: a single place assembles every query, and after reading, each row is checked against the company it belongs to. Every entity ships with a test that "a user of company A cannot see a row of company B" - a condition for the work to be accepted, not a recommendation.
An application that pulls a library off the internet doesn't run on a closed network at the client's site, and doesn't run on the day somebody else's server goes down.
So the application serves no JavaScript at all, and no external fonts or images. Everything that reaches the browser comes from our own server.
Passwords are stored through PBKDF2 with 600,000 rounds; the database holds only a hash of the session key, never the key; every form is protected against cross-site submission; and a wrong password slows the next attempt down instead of locking the account - because a locked account is a weapon in the hands of whoever is guessing.
A client's bank account and the contract fee are shown only to the "finance" role and administrators. Scheduling is the dispatcher's view.
The dashboard is set up per person - ten tiles (urgent, unassigned, waiting on a part, overdue…), and the numbers narrow by role: a technician's "urgent" counts his own, not everyone's.
The dispatcher opens an order, sets priority and deadline and assigns a technician - or leaves it unassigned, where it shows up as a dashboard tile. Works today.
He opens the order himself, on the spot, and enters the client in the same form if they aren't on file yet. From the office this works today; from a phone, with no signal - being built.
The system opens an order every N months by itself. It is the only revenue that doesn't depend on the client remembering to call. Contracts are recorded and visible today; opening orders automatically is still to come.
None of this works yet. It's here because it has been decided and designed, so you can see where this is going - and know what you will not get today.
In development
On site, a technician doesn't edit the order - he adds a visit: arrival and departure time, and what he found on that visit. That way one fault stays one order across three trips, instead of being torn into three pieces of paper. An order already displays its visits; the screen for entering one arrives with the field view.
In development
Pump rooms, underground garages, concrete buildings. The rule was set in advance and is not up for negotiation: offline you only ADD, you never change what already exists on the server. That keeps syncing as "send what was created", not "merge versions" - conflicts aren't resolved, they're made impossible. The database is already built for it: every record carries both the time it was written in the field and the time it reached the server, and anything created in the field comes in "for confirmation".
In development
Both optional and never a condition for closing a visit. Only the time and the findings are required. Anything that can't be filled in on the spot must not be mandatory - otherwise the procedure gets bypassed, and a false record is worse than none.
In development
A unit is found by scanning its label, not by searching a list of a thousand rows. The code carries only the internal label - never a web address, because a sticker on somebody else's wall outlives ten years of URLs and must not lead anywhere.
In development
Three kinds, three rhythms: tools are signed out permanently and checked by stocktaking, equipment for installation per order, spare parts by quantity, through consumption. A unit installed at a client isn't consumed but relocated - it changes owner and carries on with its own history.
In development
Once visits are in, the findings go into that unit's history: what was done to it, how many times the same part failed, when it was replaced. On a warranty claim you read it, you don't guess.
Module, later
Our terminals and our licence server work and understand each other - devices report in, licences are issued and tracked. That module does not exist in this application yet: it will be switched on only for the companies that need it, because the core must not know about any particular kind of device.
The application is live and being used, and it is still in development - it gets added to almost daily. The office side works. The field side does not exist yet - today the entry happens from a computer.
We have no customer testimonials, no numbers about how many companies use this, and we are not going to invent any. Pricing towards service companies hasn't been set, which is why there are no plans and no price list on this site.
Why that might still suit you: a company that comes in now shapes how the tool works. What bothers you gets changed while changing it is cheap - later, those same things get explained away as "that's just how it works here".
If this looks like the work you do every day, get in touch - what you tell us goes into how the application will work.
Notify me when it launchesLeave your email and we'll let you know when the application is ready - and what got done along the way. No newsletter, nothing every week.
Logger