Home

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:

Get started