Supabase · Practical guide
Which version of Tuesday is the real schedule?
A plumbing shop has three job lists. Start with one dependable record before adding another app.
A note from the studio
The office spreadsheet says six jobs. A technician's text thread says seven. The owner has a photo of a whiteboard with eight. The cost shows up as a wasted drive, a missed customer, and an awkward call that starts, ‘I thought we moved that appointment.’
Featured podcast / The Deeper DiveThree versions of TuesdayWatch the illustrated story or listen after the guide
Settle the rule before the database
Pick who owns the schedule. For this shop, the dispatcher should change the job record when a customer moves a visit. The technician sees the new time in the same place. A text may alert the team, but it should point back to the job instead of becoming a second schedule.
Supabase can provide the shared database, sign-in, and access rules behind a custom dispatch tool. It cannot decide which of the eight jobs is real. We would map the current process first, including what happens when a technician's phone loses service. If the field-service software the shop already pays for handles this well, use that system instead.
What we would prove in a small pilot
Move one test job from Tuesday to Wednesday. Check that the assigned technician sees the new time, another technician cannot see customer details they should not, and the office can tell who changed the record. Then export the jobs and confirm the business can recover its own data.
The owner should see fewer duplicate updates and fewer calls asking which list is current. A custom app is only worth building if it removes a real gap in the tools already on the desk.
A practical first step
What we would put in place
- Choose who owns the schedule.
- Pilot one shared job record and the right access for each role.
- Test a moved visit, an offline phone, and a data export.
Starting tool cost
$0 Free tier; Pro from $25/monthFree projects have limits and can pause after inactivity. Pro includes one small paid project through compute credits; usage and additional projects can add cost. App development is separate.
Check Supabase pricing USD, checked September 25, 2026. Tool fees are separate from design, development, and ongoing care. See how Mata.Works quotes the build and care.Featured podcast / The Deeper Dive
Three versions of Tuesday
A plumbing shop has three different schedules. The owner needs one job record the office and technicians can trust.
Read the episode transcript
AI voices perform a script reviewed by Mata.Works. Landon and Tam are the illustrated hosts. The business scenario is an example.
Landon: Tuesday morning at a small plumbing company. The office has six jobs on a spreadsheet. A technician has seven in a text thread. The owner has a photo of a whiteboard with eight. Which one is the schedule?
Tam: At the moment, nobody knows. And that is expensive in a very ordinary way. Someone drives to an address after the customer has moved the appointment. Another customer never gets a call back.
Landon: So we buy Supabase and the three lists become one?
Tam: Somebody still has to build the workflow. Supabase can hold the shared records behind a custom tool: each job, address, status, and update in one database. It can also handle sign-in and rules about who may see or change a record. It does not decide which of those eight jobs is real.
Landon: Who decides that?
Tam: The business. Start with one rule: the dispatcher owns the schedule. When a customer moves a visit, the office changes the job record. The technician sees that change in the tool. A text can alert somebody, but it should not become a second schedule.
Landon: Give me a test that would catch a bad build before we put the team on it.
Tam: Change a job from Tuesday morning to Wednesday afternoon. Can the technician see the new time? Can a different technician see that customer's phone number when they should not? Can the office tell who changed the job? And if the internet drops in the van, what does the technician see?
Landon: That last one matters. A database in the cloud does not make a phone work offline.
Tam: Right. The app has to handle that. The owner also needs to know how records are backed up and how to export them. A database is where the truth lives; the team still needs a clear way to use it.
Landon: What if their current field service system already keeps one good schedule?
Tam: Keep it. We would only propose a custom tool when a real gap survives a look at what they already pay for. The decision is simple: can everybody act on the same job record, with the right access, without another round of copying and guessing?
Would this fix a real snag at your shop?
Get one reliable schedule