Records with a real permission model
Who can see a salary, who can see a disciplinary note, who can see neither. A spreadsheet has exactly one answer to that question and it is the wrong one.
Enterprise · Internal tools
HR Management Portal
The software was never the hard part. The hard part was that the process being replaced had a dozen undocumented exceptions everybody relied on and nobody had written down, and you only find those by sitting with the people who do the work.
Sector
Enterprise
Replaced
Spreadsheets and email
Shape
System of record
Hosting
Their own IT team
Status
Running and supported
The problem
What it replaced.
Employee records lived in a shared spreadsheet with no permission model, approvals lived in email threads that stopped being findable after a few months, and reporting meant somebody rebuilding the same pivot table every month and getting a slightly different answer than the person who built it last time.
What we built
The pieces, and why each one exists.
Approval flows that carry their own audit trail
Who asked, who approved, when, and on what basis, attached to the thing being approved rather than reconstructed later from an inbox.
Reporting on defined views
So that two managers asking the same question get the same number, and the definition of that number is written down somewhere other than in one analyst’s head.
Deliberately ordinary technology
React, Node and SQL, deployed the way their IT team already deploys things. Nothing exotic, because the people maintaining it after us are theirs, not ours.
The hard part
Where the time actually went.
Every internal process has exceptions that exist for real reasons and appear in no document: the approval that skips a step for one department, the field that means something different in the field office, the report that is wrong in a way everybody has learned to correct for. Build the process as specified and you break all of them on day one. Finding them is not a technical exercise. It is sitting with the people who do the work and asking why, which is exactly the step the standard delivery chain removes.
What we took from it
Carried into later work
- The specification describes the process. The exceptions describe the job.
- Boring technology is a feature when somebody else maintains it.
- Defined views are how a reporting argument stops recurring every month.
The stack
What it runs on.
Front end
ReactJSRole-aware interface
Back end
Node.jsRole permissionsAudit trail
Data
SQLDefined viewsMigrations
Delivery
Self-hostedClient IT maintainableDocumentation
What is not on this page
No client name, and no numbers we were not given.
Most of our contracts ask us not to name the client, and we would rather keep the work than the logo. We have also not put a percentage improvement on this page, because we would be estimating it and you would be right to discount it.
What we will do is arrange a reference conversation with the client, with their agreement, for work that resembles yours. Ask on the first call.
Next step
Bring us the problem, not the spec.
Thirty minutes. If your problem rhymes with this one we will say what we would do differently the second time, which is usually the more useful half.