HR Platform: one approval trail behind every people decision
A multi-tenant HR platform where every people decision leaves one approval trail.
In developmentMulti-tenant HR and workforce platform, in development
Our role
BitsSolved, in house
- Product design and build, in house
- Multi-tenant platform and approval engine
Why HR systems go wrong between the parts, not inside them
Very few HR mistakes are arithmetic. They happen in the gaps: leave approved over a message and never recorded, an employee record updated in one place and not another, an access request granted verbally and still live two years after the person changed teams. Each individual system is defensible. Together they guarantee the same fact exists in four places and at least one copy is wrong.
The second problem is that approvals get bolted on. A product ships leave requests with an approval step, then expenses with a different one, then access requests with a third, and none of them can answer the same question in the same way. A year later nobody can produce a straight history of who authorised what.
The third is that the rules are never generic. A factory rosters night shifts across midnight; an office has no roster at all and treats a Sunday as unusual. A leave policy accrues monthly for one employer and annually for another. Software that assumes one shape makes the other employer wrong twice a month.
- Status
- In development, not publicly available
- Sector
- HR and workforce operations
- Architecture
- Multi-tenant, one approval engine
- Built by
- BitsSolved, in house
What is built
One approval engine, five record types
Leave, access requests, expenses, hiring requisitions and offers all move through the same transition engine. A module contributes only what its approval should do at the end; it does not implement its own workflow, so every approval behaves and reads the same way.
An audit entry written in the same transaction
The history is committed with the change rather than logged after it. A record that exists therefore has a trail by construction, and there is no failure mode where the change lands and the history does not.
Attendance and shifts in the tenant timezone
Punch times and shift windows are evaluated in the employer timezone, which is what makes a night shift that crosses midnight land on the right day and late minutes come out right for an employer that is not on UTC.
Leave balances that survive a cancellation
Accrual, usage, adjustments and closing balance are modelled so that cancelling approved leave unwinds what it consumed instead of posting a second correcting entry that double counts.
Recruitment through to offer
Applications, interviews, feedback from whoever sat in the room, and an offer that rides the same approval engine as everything else.
Assets, expenses and project work
Equipment tracked against the person holding it, expenses through approval, and project and task records so that time is recorded against something real.
Industry packs as data
An industry configuration is a JSON file that is validated by tests, not a schema migration, so supporting a new kind of employer does not mean changing the database.
The decisions being made
- 01
One approval engine, or five that disagree
The single largest architectural decision here is that approvals are a platform capability rather than a feature each module implements. Five entity types ride the same engine, and a module supplies only the effect that its approval produces. The alternative, which is what most HR products end up with, is five workflow implementations that drift apart until no report can span them and every new approval type is a fresh build.
- 02
Authorise the subject, never trust the request
Every action names the employee it concerns, and the platform resolves whether the caller may act on that employee rather than accepting the identifier the request supplied. It sounds pedantic until you notice that the alternative lets anybody file a record against anybody. The same principle puts the tenant in the signed token rather than in the hostname, so a request cannot reach into another employer by asking nicely.
- 03
Multi-tenant means every link carries the tenant
Foreign keys between records are composite with the tenant, not single column. Without that, the database will cheerfully accept a task in one employer pointing at another employer record, and it is correct to do so, because nothing told it otherwise. This is the kind of thing that is cheap at the schema stage and close to unfixable once there is data.
- 04
Payroll last, and only when it is right
Payroll calculation and payslips are deliberately not built yet. A payroll module that is nearly right is worse than a spreadsheet, because people trust it, and the inputs it depends on, attendance in the right timezone and leave balances that do not drift, had to be correct first. Those are now in place, which is the order this was always going to happen in.
How it is built
- Frontend
- ReactViteTypeScript
- Backend
- Go
- Data
- PostgreSQL
- Platform
- Approval engineScoped authorisationAuditOutbox
How the engagement ran
- 01
Discovery
A working session on your product and its architecture, written up as scope, screens and a fixed quote for the first phase. Nothing is chargeable before that document exists.
- 02
Build in the open
Working software you can open while it is being built, instead of a status report, so the brief can change while changing it is still cheap.
- 03
Launch
Deployment with monitoring, backups, TLS and security headers, on infrastructure the client owns.
- 04
Scale
A maintenance window for fixes, monitoring and improvements, or a full handover to your own engineers with documentation. You can stop after any phase and keep everything built so far.
If you need HR or workforce software built for how you actually run
Most companies do not need a different HR product. They need the one they have to stop being an island, or they need the rules their business actually follows, which no off the shelf product encodes exactly.
Find the re-entry step
Wherever a number is typed into a second system each month, that is where the errors come from and where the return is.
Write down the real rules
Every employer has leave, shift and approval rules that do not match the product it bought. Those rules are the specification, not an edge case.
Build the audit trail first
It cannot be added retrospectively, because the history it would need was never recorded.
The services behind it:Custom SaaS DevelopmentWeb Application DevelopmentCloud and DevOps
Questions people ask before starting one of these
More case studies
Want something like this built?
The first call is free and is mostly us asking questions. After it you get the scope in writing and a fixed quote for the first phase.
What happens next
- You send the formTell us the problem.
- We reply by emailWith any questions.
- A free first callThen the scope in writing.