The pieces and their boundaries are settled before code.
Several institutions, one system, records kept apart.
One codebase, both stores: iOS and Android.
We take a running system over and improve it.
AI only where the problem actually calls for it.
Marks on an optical answer sheet are read from the image of the form rather than through a reader's optics. Scoring stops being something that happens at one machine in one office: whoever uploads the sheet gets the result.
Optical mark reading usually belongs to whoever owns the machine. The reader sits at one office, so branches send their answer sheets there and wait. If the device fails, or an exam needs a sheet the device will not accept, scoring stops. Vipkurum removed that dependency by design: the reading happens on the image of the form, through OpenCV, and not inside a machine anybody has to own. It is worth being precise about what went away. The hardware did; the requirement that a mark be filled in properly did not, and a sheet completed carelessly still scores like one.
We go through how the work runs today and what you expect from the software; the scope comes out of that.
We decide what the system is made of and where its information is kept.
We draw the screens and the flow before any code, and start building once you have approved them.
We write and hand over the software so another team could carry it on.
OpenCV extracts the marks from the form image, so the reading happens in the application's vision layer rather than a device's optics.
A new sheet layout is handled on the Python side; no replacement device and no device-specific form stock has to be ordered.
The cropping tool produces the answer key and this tool extracts what the student marked; the two meet on the same exam record.
Sheets are uploaded from the browser, the Python reading service is called through Node.js, and results land in MySQL on the Laravel side.
| Challenge | Result |
|---|---|
| One optical reader sits at head office, so branches ship their answer sheets there | A branch scores its own exam without shipping forms to head office |
| When the device breaks, scoring across the whole institution stops | Scoring no longer waits on one machine being in working order |
| Only forms the reader accepts can be used, which fixes the sheet design | The institution can use a sheet design the old reader would have refused |
| A layout change turns into a procurement question with no answer in software | A new sheet layout is absorbed in software, not in a purchase order |
Our own workshop software, built around the car on the ramp. A work order, the parts it consumes and the invoice it produces run as one chain, and the accounting side hangs off that same record. Maintenance history lives on the plate and chassis, so it travels with the car.
Our own product for HVAC, boiler and appliance service companies. The customer and device records the office works from are the same ones the technician carries into the field. A job can be opened and closed in a basement with no signal, and service history stays tied to the device.
Our own product, still in development and not yet live. How long an appointment runs, what it is booked against and how bookings stack all differ by trade, so we are keeping those rules configurable inside the product instead of fixing them in code.
Tell us how the work runs today and we will look at which step could move into software.
