Two of the three people who can approve payments are away the same week and nobody noticed until Tuesday. Here is the model behind a tracker that notices, the prompts to build it, and what it takes to run it.
Your private status link is on its way to your inbox.
A leave and cover tracker needs four things: leave requests with balances, a map of responsibilities to the people who hold them, a coverage check that runs at request time, and a named deputy activated for the duration. Most leave tools stop at the first item, which is why they answer "can this person take the day" and never "can the team survive the week". The coverage check is the part worth building.
Leave and cover
14.5
Days you have left
2
Coverage conflicts
3
Single points of failure
6
Deputies active
October 2026, payments team
You run people operations, or you manage a team where certain responsibilities sit with one or two named people. What you want is for leave approval to consider coverage automatically, and for deputies to actually take over.
What happens when somebody books a week off, and what the app knows that a shared calendar does not.
Entitlement, accrued, taken, booked but not yet taken, and remaining, calculated against that person's own working pattern and public holidays.
Every responsibility they hold is checked for cover across the whole requested window.
Before it reaches the approver. Most people move a day when they can see the problem themselves.
Plus the team calendar for that window, so it is one decision rather than two lookups.
Blocking leave over coverage makes people route around the system. A recorded decision is the thing you actually wanted.
Approval routing, on-call, inbox delegation and system access each move, with a from and to date and a handover note.
This is not a shared calendar. It is four parts, and the second is the one that turns leave from an administrative record into an operational one.
Leave types, entitlements, accruals, carryover, and a balance that accounts for booked but not yet taken. Plus a working-day calculation that respects each person's location and public holidays.
Which responsibilities exist, who holds each, at what level, and the minimum number of holders that must be available. This is the data most companies have only in people's heads.
At request time, evaluate every responsibility the requester holds against who else is available in that window, and warn before approval rather than after.
A named deputy per responsibility for the leave period, and a record of what actually moved: approval routing, on-call, inbox delegation, and system access.
These prompts start from a Helix project, which is what handles sign-in, credentials and hosting. Start with Helix
Paste these into Claude Code, Codex or Cursor in order. Each one leaves you with something that runs, so you can stop after any step.
The administrative half, including the detail that breaks naive versions.
In this Helix project, build me a leave and cover tracker.
Start with the ordinary half. Leave types in a config file: whether each
deducts from a balance, whether it needs approval, notice required,
maximum consecutive days, and any documentation requirement.
Requests with start and end dates, half-days at either end, and the
working days calculated. Calculate those against that person's own
location calendar and working pattern, not a generic one. Public holidays
vary by country and quietly break every naive implementation of this.
Show five numbers on a balance, not one: entitlement, accrued to date,
taken, booked but not yet taken, and remaining. "Remaining" on its own
hides the three weeks somebody has already booked in December.
I sign in through Helix, so do not build a login page. Read the signed-in
user from the runtime. And do not put any key or connection string in the
code: if this needs to reach another system, tell me and I will create the
connection in my workspace.The responsibility map, which is the reason to build this rather than buy a leave tool.
Now the part no leave tool does.
Build a list of responsibilities: things that must always have somebody
available to do them. For each one, a description, a criticality, and the
minimum number of available holders required at any time. Then record who
holds each, and at what level: primary, secondary, or trained.
Seed it with the real ones: payment approval above a threshold, incident
commander, production deploy approval, contract signature, the escalation
owner for a named account, payroll submission.
Then two reports that need no leave data at all. Any responsibility with
fewer holders than its minimum right now. And any responsibility with
exactly one active holder, ranked by criticality.
Most companies find two or three they did not know about, and that alone
justifies the build.Worth knowing. The single point of failure report is worth the whole exercise before a single leave request has been entered.
At request time, and shown to the requester.
Now connect the two halves.
When a request is submitted, take every responsibility that person holds,
count how many other active holders are available across the whole
requested window, and compare against the minimum. Three outcomes: clear,
warning if it sits exactly at the minimum, conflict if it drops below.
Name the responsibility and the dates.
Show that to the requester at submission, before the approver sees it.
Most people move a day when they can see the clash themselves, and that
resolves it without a conversation.
The approver sees the coverage result next to the balance, plus the team
calendar for that window.
Allow approval over a conflict, with a required reason and a named
mitigation. Blocking leave makes people route around the system, and a
recorded decision is what you actually wanted. Then give me a forward view:
any date in the next six months where a responsibility drops below its
minimum given the leave already approved.Deputies, and the handover note nobody writes voluntarily.
For each approved absence, record a named deputy per responsibility,
defaulting to the secondary holder.
Then track what actually moves, as a checklist with a from and to date:
approval routing, on-call rota, inbox delegation, system access, and any
named contact updates. A deputy named on a document changes nothing about
who can approve a payment on Wednesday.
Notify the deputy on activation with what they are covering and until
when, and again on the day it ends.
Prompt for a handover note two days before leave starts, which is the last
moment anybody will write one: what is in flight, what needs a decision,
who to contact.
And report which responsibilities repeatedly cause conflicts. That list is
a cross-training or hiring argument with evidence attached.The step that turns a working prototype into something with your data in it.
Now connect it to the systems we actually run, so it works on real data
rather than the rows you seeded.
Anything in angle brackets is a placeholder. Swap it for whatever we use
instead, and have the app name the connection it wants rather than assume
a vendor, so changing my mind later is a config change and not a rewrite.
<Workday>. Read entitlements, working patterns and public holidays for
each person's location.
<Okta>. Read teams and the manager relationship, so a request routes to
the right approver without a list somebody maintains.
<Google Calendar>. Show the team calendar for the requested window, and
block the days once approved.
<PagerDuty>. Take somebody off the rota while they are away, which is the
deputy step people forget.
<Slack>. Set a status and tell the deputy what they are covering and until
when.
<Jira>. Reassign anything in flight to the deputy rather than leaving it
queued behind somebody away.
<Gusto>. Read the entitlement and accrual rules that actually apply to
each contract type.
Only write where I have said to write. Everything else is read only.
Do not write a key, a token or a connection string anywhere in the code,
and do not ask me to paste one. Tell me which connections you need and I
will create each as an authentication in my Helix workspace. Reference
them by alias.Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.
The last step of every build: a URL, and the right people on it.
Deploy my app.Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL. Leave records are personal data, so set Access Control before sharing: individuals see their own detail, managers see availability rather than reasons.
Leave data is the easy half. Making a deputy real means changing things in other systems.
Workday
Read entitlements, working patterns and public holidays for each person's location.
Okta
Read teams and the manager relationship, so a request routes to the right approver without a list somebody maintains.
Google Calendar
Show the team calendar for the requested window, and block the days once approved.
PagerDuty
Take somebody off the rota while they are away, which is the deputy step people forget.
Slack
Set a status and tell the deputy what they are covering and until when.
Jira
Reassign anything in flight to the deputy rather than leaving it queued behind somebody away.
Gusto
Read the entitlement and accrual rules that actually apply to each contract type.
Each line says whether the app reads, writes or both. Anything not described as writing should be read only.
Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.
Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.
The build gets you a working tracker. It holds personal leave data and controls who can approve what while somebody is away, so it needs to be run properly.
AI Deployment
One command takes the app from your assistant to a live address, so the people who need it get a link rather than instructions for running it locally.
App Security
Leave records are personal data. SSO means people sign in with their existing account, and access is scoped so an individual sees their own detail while a manager sees availability rather than reasons.
App Security
Reading joiners, leavers and entitlements from an HR system, and moving approval routing during an absence, needs real access. Granting it to the app rather than pasting keys into it means credentials can be rotated or revoked without a redeploy.
App Registry
Every app carries a named owner and an entry IT can see, so the tool does not become nobody's problem when the person who built it changes role.
Cost Management
Per-app spend visibility, with budgets and caps, so an internal tool cannot quietly become a line item nobody can explain.
It records leave requests and balances like any leave tool, and additionally maps responsibilities to the people who hold them so approval can consider whether the team is still covered. The second half is what makes it worth building.
A list of the things that must always have someone available to do them, who holds each, at what level, and the minimum number of available holders required. It is usually the first time this information exists anywhere except in people's heads.
At submission, before approval, and visible to the requester. A clash found a month out is a rota adjustment. The same clash found on the Monday morning is an incident, and the difference is entirely about when it surfaced.
No. It should require a recorded reason and a named mitigation from the approver. Blocking leave over a coverage gap makes people route around the system, and the recorded decision is the thing you actually wanted.
Something actually moving: approval routing, the on-call rota, inbox delegation, and system access, tracked as a checklist with a from and to date. A deputy named on a handover document changes nothing about who can approve a payment on Wednesday.
Yes. The prompts here are written for Claude Code, Codex or Cursor and stage the build. The work outside the code is listing your responsibilities and their minimum holders, and that list tends to be revealing on its own.
People
Generate the right task list per role, route each task to the team that owns it, and prove that access was actually removed. Prompts to build it, and what it takes to run it.
IT and Operations
Request access against a defined catalogue, route it to the system owner, grant it with an expiry, and produce the evidence an access review needs. Prompts to build it, and what it takes to run it.
IT and Operations
Record incidents with a consistent timeline, run postmortems to a fixed template, and track the action items until they are actually done. Prompts to build it, and what it takes to run it.
Last reviewed September 2026.
Helix is the governed runtime for AI-built apps. Deploy what you build, put SSO in front of it, connect it to your systems with managed credentials, and give it a named owner.
Your private status link is on its way to your inbox.