A six-person installation company and four spreadsheets. A model walkthrough of one afternoon: what to put in the prompt, what comes out by itself, what needs adjusting by hand, and what actually changes in the first month.
This is a walkthrough of a single afternoon - from four spreadsheets to working job tracking. It's written as a model case for a small installation company, but the sequence of steps, and the places where it usually snags, match what we see most often when someone sets up their first workspace.
Starting point: four spreadsheets and a pinboard
Six people. Two technicians in the field, one salesperson, one administrator, the owner and his wife on invoicing. Jobs: interior fit-outs, usually 15 to 40 running at once.
Where it all lived before that afternoon:
- jobs_2026.xlsx - the main sheet, which nobody was allowed to open at the same time as anyone else
- contacts.xlsx - clients, occasionally duplicated
- deadlines.xlsx - what's due when, updated irregularly
- hours.xlsx - technicians' timesheets, reconstructed at month end
- a pinboard in the office with paper orders on it
The pain that decided it: twice in six months the company forgot to invoice a completed job. Once for €2,700.
What went into the prompt
Nothing technical. Literally this:
I need job tracking for an installation company. For each job I want to know who the client is, the installation date, which technician is on it, how many hours they logged and whether it's been invoiced. I want to see what's due this week, and I want an alert when a job is finished and has no invoice.
No “relational database”, no “workflow engine”. A description of what the system should do, in the order it came to mind.
The prompt produced a plan, not a finished thing
The system first showed what it intended to create - databases, relations and automations. It built them only once that was approved.
What came out (and what needed fixing by hand)
In about twenty minutes there were three connected databases - Jobs, Clients, Technicians - plus timesheets linked to jobs. On top of that, three views: an installation calendar, a table of uninvoiced jobs, and a kanban by status.
What was right straight away:
- the relations between job and client (one job, one client; a client has many jobs)
- timesheet entries attached to both the job and the technician
- a “this week” view as a calendar
What needed adjusting by hand:
- Job statuses. The generated ones were generic (New / In progress / Done). We have five, including “Waiting for materials”, which is our single most common cause of delay. Renaming and adding took a few minutes.
- Who sees what. Technicians shouldn't see prices. That's set separately - which is right, because it isn't something a machine should decide.
- Reminder wording. The automated email had generic copy. I rewrote it so it sounds like us.
Overall: the prompt did 80% of the structure, the rest was configuration rather than construction.
The hardest part wasn't technical
What took longest was deciding what a “job” actually is. Whether a job is one installation, or a whole client order that may contain three installations. No tool will answer that for you - but it's an hour of thinking, not a month of development.
The automation the whole thing was for
One rule, two conditions:
When a job has been in “Done” for more than 3 days and has no invoice attached, email me.
That's the entire solution to a problem that cost the company €2,700. Setting it up took about six minutes.
A second rule appeared a week later, once it turned out technicians were forgetting to log hours:
Every Friday at 15:00, send each technician a list of jobs they worked on this week that have no timesheet.
What changed in a month
Three things, measurable:
Invoicing. In the first month, two jobs that would previously have slipped were invoiced on time. That alone paid for the system for several years.
No more spreadsheet versions. The question “which sheet is current” stopped existing. Not because people improved, but because there's only one.
The morning stand-up. Down from twenty minutes to five, because nobody has to read out where things are. The installation calendar shows the same thing faster.
What didn't change: technicians still sometimes forget to log hours. The system just reminds them on Friday. A tool doesn't change habits, it only shortens the time before a mistake surfaces.
What I'd do differently
Three things:
- Start smaller. I tried adding materials stock right at the beginning. Pointless - after two weeks nobody was using it. You can add things whenever.
- Involve people sooner. I built it alone and then showed them. Asking the back office first would have saved me two rounds of rebuilding views.
- Not import all the history. I loaded three years of old jobs. The last year would have been plenty; the rest just cluttered the views.
For a more detailed, step-by-step approach to the sales side, see Build a CRM without a developer. The practical data-migration route is in Migrating from Excel or Notion. And if you're wondering when it's time to leave spreadsheets at all, that's When a spreadsheet stops being enough. The whole process from decision to first month live is covered in the guide to a custom business system.
Common questions about getting your own system going
Can a non-technical person really do this?
Yes, provided they can describe how their company works. That's the harder part - and nobody can do it for you. The technical execution is now secondary.
How much time should I set aside?
For a first usable version, budget one afternoon. For a version the team is happy with, two to three weeks of ordinary use and gradual tuning.
What if it turns out I designed it badly?
That happens almost every time and it's fine. Fields, statuses and relations can be changed while the system is in use - unlike a developed app, where a change to the data model is a job for a developer.