Job-tracking software for service companies, built in 25 working days
25
working days
src · days with commits, 2.07–3.09.2026
876
automated tests, all passing
src · 81 test files, run on the 3.09.2026 state
53,070
lines of code, generated files excluded
src · ts/tsx/prisma/sql in 345 files, generated code excluded
The problem
A service company runs on jobs. A customer calls, someone writes it down, a technician goes out, papers get signed, and months later someone needs to find them. When that lives in notebooks, email and spreadsheets, jobs get lost between steps.
I built this system to keep each job in one place, from the first request to the archive.
What it does, in plain words
| What’s in it | What it means for the business |
|---|---|
| Stages for every job | You see where each job is, without asking anyone. |
| Workflow editor | The steps of a job can be changed on a diagram, not in code. |
| Documents and signatures | The paperwork lives inside the job. |
| Customer access without an account | Customers don’t have to sign up for anything to take part. |
| Polish, German, English | The same system for staff and customers in three languages. |
| Several companies, separate accounts, roles | Each company sees its own data. Each person sees what their role allows. |
| Archive and GDPR documents | Old jobs stay findable. Data-protection paperwork is built in from the start. |
| Two different trades on one system | The system isn’t hard-wired to one kind of work. |
Numbers
All numbers below describe one state: the code as it stood at the end of 3 September 2026, the last day of the build window that started on 2 July.
- 25 working days — days with committed work, 211 commits in total.
- 876 automated tests, all passing, in 81 files. A test is a small program that checks the software does what it should, every time something changes.
- 53,070 lines of code in 345 files. Generated files, such as the database client, are left out of the count.
- 36 data models, 20 enums, 20 tRPC routers, 11 REST handlers — for the technical reader.
- 68 commits on the busiest day, 22 August.
Lines of code only measure size. The tests are the number that matters: they’re how I know a change on Friday didn’t break something from July.
After the build window
On 18 September 2026 I ran a production audit: 0 critical vulnerabilities in dependencies, 0 critical accessibility errors.
Since 17 September 2026 there’s a demo running on made-up data.
What this doesn’t show
- 25 working days means days with commits, not calendar days. The calendar window was about two months.
- These numbers describe the software. They say nothing about who uses it.
Last checked: