Job intake and work sheet
The vehicle arrives and the sheet opens: details, mileage, reported fault, photos. Whoever is on the floor sees straight away what needs doing and how far along it is.
Built around the way your workshop works, not around the assumptions of a packaged product. The code stays yours for good.
The workshops we meet almost always show the same picture: an accounting package that handles invoices well and nothing else, quotes rebuilt by hand every time, spare-parts stock kept aligned from memory, and a vehicle's history scattered across paper sheets, messages and people's heads.
The problem is not a lack of software. It is that the available software is written for an average workshop that does not exist. A tyre shop thinks in seasons and storage; a garage thinks in services and spare parts; a bike workshop thinks in components and maintenance cycles. Forcing three different flows through the same screen means none of the three is served well, and nobody comes out ahead.
Custom software starts from the opposite end: first you look at how the workshop works, then you write the system. Custom does not mean expensive.
The vehicle arrives and the sheet opens: details, mileage, reported fault, photos. Whoever is on the floor sees straight away what needs doing and how far along it is.
Labor, parts and standard times combine on their own. The quote goes out in minutes, stays attached to the job and is reconciled against actuals once the work is closed.
Real stock levels, reorder points, supplier orders and parts committed to a job. Without the double work of keeping two systems in step.
Every job stays attached to the vehicle and the customer: what was done, when, with which parts. That is the basis for recall calls and for the relationship over time.
The accounting system you already use stays where it is: we connect through APIs or scheduled exchanges instead of replacing it and starting over.
People at the bench or under the lift work from a tablet or a phone, not from the office machine. Same information, on a screen usable with dirty hands.
For one workshop we built a B2B2C ecosystem holding together the CRM, dynamic quoting and a digital record of the vehicle updated at every visit, with dynamic predictive maintenance fed by usage data pulled in through a Strava integration. The measured result: 40% less time spent on administrative work and 25% higher customer retention.
We do not work on license fees. Source code belongs to the client in full, together with API documentation and repository access. If one day you want to take the work elsewhere, you can: it is an architectural choice, not a sales promise.
We build simple solutions for investments of around fifteen thousand euros, as well as advanced systems costing several tens of thousands. It starts with an analysis of the workflow, which produces a proposal with a cost range, the scope of what will be built, deadlines and recurring costs stated explicitly (hosting, for example). A first working module costs far less than a complete platform, and is often exactly the right way to begin.
The proposal gives you a price range. With the initial requirements unchanged, we cap the maximum rate: anything beyond it is absorbed by us.
Yes, and it is what we recommend. You pick the point that hurts most (usually quoting or intake), release that and use it in the workshop for a few weeks. What comes next is decided by real use, not by a document written six months earlier.
Yes, it is one of the things we do most often. We connect to existing ERPs and accounting packages through REST APIs, scheduled exchanges or other secure channels, so accounting stays where it is and the workshop stops entering the same data twice.
Yes, and that is exactly why custom makes sense here. A tyre shop needs seasonal storage and per-customer tyre tracking; a bike workshop reasons in components and maintenance cycles. These are different flows, and software built on the flow follows them instead of forcing them.
The data is yours and stays accessible: no closed formats, no export lock. Source code belongs to the client and is handed over with documentation and access, so the supplier is replaceable without rebuilding the platform.
We talk, we work out what is holding you back and we start with the first implementation.