RTS — Routine Tentative Scheduler¶
A scheduler built for lives that don't fit a calendar. Born from a real need — Luiz's own — with a real chance of becoming an Absolutely Plausible product.
Status: Concept · Created: 2026-05-16
The problem¶
A normal calendar assumes your time is made of fixed events — a meeting at 3pm, a flight on Tuesday. That model works for a salaried 9-to-5.
It does not work for a gig / freelance / multi-stream life. That life is made of three different kinds of time:
- Fixed anchors — genuinely immovable. Choir Mondays (Aug–May). HBI Electrician school (Jul–Sep). A client deadline.
- Routines — recurring, semi-flexible. Weekly review. Gym. The Sunday plan. They should happen, on a rhythm, but the exact slot flexes.
- Tentative / variable work — the income that pays the bills but never sits still. Lyft hours. Instawork shifts. Evolution Kart client work. These shift constantly, get picked up and dropped, and have to be slotted into whatever gaps the anchors and routines leave.
Standard calendars have no concept of "tentative." Everything is either a hard event or it doesn't exist. So the variable layer — the part that actually needs managing — gets managed in your head. That doesn't scale, and it's exhausting.
The idea¶
RTS = Routine Tentative Scheduler.
A scheduler that models all three kinds of time honestly:
- You define your fixed anchors once.
- You define your routines and their rhythm.
- RTS shows you the real gaps — and helps you slot tentative work into them, mark it tentative-vs-confirmed, and re-plan fast when something moves (because something always moves).
The core insight: the tentative layer deserves first-class support, not a mental juggle. Make the maybe visible.
Why now¶
This isn't theoretical. It's Luiz's actual May 2026 reality:
- Fixed: Choir Mondays · HBI school starting July 13
- Routine: Sunday planning · weekly reviews · content batching
- Tentative: Lyft · Instawork gig shifts · Evolution Kart client work · the DJ Pallet Table build
Five+ moving streams, two countries of family, one head holding it together. If a tool would help here, it would help.
Build for ourselves first. If RTS solves Luiz's scheduling problem, that's already a win. If it then solves it for other gig-economy workers — that's a product.
Build approach¶
Consistent with AP's core principles:
- $0 infrastructure to start — static app, local-first (the AP Ops stack is a proven template: static HTML/JS, localStorage, optional Sheets sync)
- Build the prototype for one user (Luiz), then watch if it generalizes
- Don't over-design. A scheduler that models fixed / routine / tentative and nothing else. Resist feature creep.
Product potential¶
The gig economy is enormous and growing, and "my schedule is chaos" is a near-universal complaint within it. RTS would not compete with Google Calendar — it would sit next to it, owning the layer calendars ignore.
This is a Decision-Gate question, not a commitment. Prototype first. Use it. If it earns its place in Luiz's own week, then evaluate productizing.
Status & next steps¶
- Concept captured (this page)
- Sketch the core model — how a "tentative block" is represented
- Decide: standalone prototype repo, or a module inside an existing app
- Build a v0.1 prototype Luiz can actually use for a week
- Review: did it help? → decide whether it's a product
RTS is a candidate, not a commitment. It earns its place by being used.