For the person who asks how it is built before they ask what it costs. What Staffbook holds, what it refuses to hold, and how the system that keeps your staff records is itself kept. The short version lives on the front page.
The boundaries are structural. They are not settings, and no future update quietly moves them.
Training and DBS renewals, the Schedule 2 recruitment checklist, supervisions, rotas, the home’s own checks, tasks and the audit trail. The working file for the people and the building.
There is no child record in Staffbook and no field intended for one. It does not replace a care records system and does not try to. That is a boundary, and it is also the point: trying Staffbook never puts a young person’s data anywhere new.
Certificate number, dates and status. There is nowhere to type what a disclosure says, on purpose.
Disciplinary and safeguarding records about staff open to the Responsible Individual only, behind a fresh password check, and every open is written to the audit trail.
A support worker sees their own record and the published rota. Wages are visible to the Responsible Individual and nobody else, enforced in the database rather than promised in a policy.
Staff records are the sensitive kind. The protections are in the database and the infrastructure, where they cannot be forgotten by a screen.
Every table in the database carries row level security scoped to your organisation. The screens are a convenience; the database is the control. Even a bug in a page cannot cross the boundary, because the boundary is not in the pages.
Certificates and documents live in private storage. Opening one issues a link that dies after sixty seconds, and the open is logged against the person who did it.
Append only. There is no edit and no delete, for anyone, including the owner of the organisation. That is what makes it worth showing an inspector.
Everything travels over HTTPS, enforced for a year at a time in the browser itself. The app cannot be framed inside another site, and nothing in it is allowed to appear in a search engine.
The database is backed up every day on managed infrastructure, so a mistake is a restore rather than a rebuild.
No privileged key is ever sent to a browser. The scheduled jobs that send the Monday digest carry their own secret and can do nothing else.
Staffbook runs on Vercel and Supabase, the same managed infrastructure used by banks and health services, with alert emails sent through Resend from EU infrastructure. Your data is exported to you and deleted when you leave, in the same month you leave.
Staffbook is built and run by one person in Manchester, which means the person answering a data question is the person who wrote the code. Company registration and ICO details are being finalised and will be listed here, in full, as each completes. Until then, and after, data questions go to colby@staffbook.co.uk and get answered by a person.
No. A support worker sees their own file, their own tasks and the published rota, and can record a premises check. Everything else needs a manager login, and the sealed records need the Responsible Individual.
You can leave any month. Your data is exported to you in files a human can read, spreadsheets and the documents themselves, and then deleted.
An evidence pack: one zip for a named person or the whole home, the spreadsheets plus the certificates, with a plain README. Generating it is itself logged, so the handover is on the record too.
A manager is working in it the same afternoon. Support workers get a login, see their own list, and tick things off. If anything needs explaining, that is a defect, and you tell the person who can fix it.
Bring the spreadsheet you run today. If Staffbook does not obviously beat it, keep the spreadsheet.
Book a lookOr write to colby@staffbook.co.uk.