Home / Product development / Custom employee software development
Custom employee software development for the work your staff do every day
Your staff ask for time off by email, start their first day without logins, or phone the office for job notes because the HR platform does not work on site. We build employee portals and apps around your own request types, approvers and shifts, usable on a phone or at a desk, and connected to the HR, calendar and IT tools you keep. Coding agents help write the forms and phone views; senior engineers decide what each role may see.
A request sent by email has no status. Staff chase it, managers lose it, and HR types it in again.
Time off is agreed in a manager’s inbox, a new starter spends the first morning waiting for logins, and a technician on site phones the office for the job notes. Software built for staff turns each of those into something they start themselves, can follow to a decision, and can do from the phone in their pocket.
- Who approves this request
- Works on a phone, on site
- What this request type asks for
- Where approved leave appears
- When the employee hears back
What we settle with staff, team leads and HR before the build
A picker, a team lead and HR describe the same request three ways. We settle which version the software follows where staff actually work: the shop floor, the office and customer sites.
A shift per role
A shift walked through with one person per role, noting what they look up, what they ask for, who they wait on, and what they still do on paper.
Request types
The requests staff make today by email, paper or phone, counted per month, each with the person it goes to and the system someone updates once it is approved.
Approvers and cover
Who approves each request type by team and site, who steps in when they are away, and where a request goes when nobody has answered it in time.
Devices and places
Office, warehouse, shop floor or a customer’s site: which screens must work on a phone, one-handed, with gloves or on weak signal, and which can stay desk-only.
Notifications and quiet hours
Which messages reach staff by push, by email or not at all, so approvals are not missed and nobody is woken on a day off by a rota change.
An owner per request
One person on your side for each request type, who decides its form, approvers and wording, and signs off changes to it after launch.
Agents draft every form for desk and phone. Who sees a colleague’s record stays with a senior engineer.
On employee software, coding agents take the repetitive part: each request type drawn for desk and phone, with its notifications and tests. Senior engineers keep what staff notice when it fails: who may see a colleague’s absences, and edits made offline that must not overwrite each other.
AI-native product developmentEvery request type gets its phone view
Coding agents draft the phone layout alongside the desk layout, so no request type ships desk-only and leaves site staff waiting for a mobile version later.
New request types reuse the first
Expenses after time off reuse the approvals, notifications and phone view already built. Coding agents draft the new form and its tests, and it is reviewed like the first.
Two offline edits, one winner
A technician and an office colleague can change the same job report while one of them is offline. Whose change wins, field by field, is decided by a senior engineer, never a library default.
Built and tested on made-up staff
Coding agents and developers only ever see generated employees with invented names, rotas and absences, never an export of your people’s records.
Who sees a colleague’s record
A team lead sees their own team’s absences, HR sees the notes behind sick leave, and nobody else sees either. Senior engineers write and test those rules before the first real employee signs in.
What staff, team leads and HR run in custom employee software
Requests and approvals
- Situation
- A picker asks for two days off in the busiest week
- Result
- Sent to the shift lead with that week’s cover shown
- Source
- Shift rota · live
- Leave and time-off requests
- Expense claims with receipts
- Equipment and access requests
- Approvals routed by team or site
Onboarding and training
- Situation
- A new starter joins the Lyon store on Monday
- Result
- Logins requested, checklist and first courses assigned
- Source
- HR record · start date
- Checklists for a new starter’s first weeks
- Logins and equipment requested before day one
- Short courses with progress by person
- Refresher courses when a procedure changes
Field and shift work on a phone
- Situation
- A technician finishes a boiler service on site
- Result
- Report, photos and signature sent to the office
- Source
- Job list · offline sync
- Today’s jobs with site instructions
- Photos, checklists and signatures from site
- Shift swaps approved by a manager
- Keeps working on weak signal
Portals and self-service
- Situation
- A driver’s licence expires next month
- Result
- Reminder sent, new scan uploaded, manager told
- Source
- Employee documents
- Contracts, policies and personal documents
- Personal details kept current by the employee
- Team news and who to ask
- A start page of personal tasks
Where you can start
Six situations, from requests by email to an in-house tool nobody maintains.
Requests by email and paper
Time off and expenses usually carry most of the email traffic, so they become the first two request types, built with their approvers, and the shared inbox for them closes on launch day.
An MVP for one department
One department, one or two request types and a phone view: enough to see whether staff use it before the rest of the company joins, and cheap to change if they do not.
A first app for site staff
Jobs, checklists and photos on a phone for one team, built to keep working on weak signal and tried on the team’s own devices before any wider rollout.
An HR platform staff avoid
When the platform keeps the records but its screens put people off, we build a simpler app on top that reads and writes through its API, so HR keeps one source of truth.
An intranet nobody opens
We rebuild it around the tasks people come to do, such as finding a policy or booking leave, with each page owned by the team that knows its content and keeps it current.
An in-house tool nobody maintains
Staff keep their current logins and find their past requests in the new app on its first day, so nobody needs the old tool to look anything up and it can be switched off.
From the first request type to software every site uses
Five stages, with the pilot at the site whose work is hardest: weak signal, shifts and several approvers. Other sites are simpler after that.
- 01
Design with staff
Request forms tried on the phones staff actually carry, in the places they will use them, with a team lead and someone from HR checking each approval route.
Figma - 02
Build the pattern
Sign-in, approvals, notifications and the phone view are built once, then the first request type on top, each sprint ending in a build staff can try on test accounts.
.NET or Node.js, React or React Native - 03
Pilot site
Staff at the hardest site run real requests through it for a full rota cycle, on their own phones and shifts. Anything they still ask for by email goes on the fix list.
Usage logs - 04
Site rollout
A security review first, then sites join one at a time, each with its approvers and cover confirmed on the day it starts, so no request lands with nobody.
Approver checks, security review - 05
Next request types
Waiting times per approver and requests still sent by email decide what changes next. The pilot site sees each new request type first, then the other sites.
Request and wait-time reports
What sits under custom employee software
Six parts, built around the employee record and its role, because every request, approval and document a person sees depends on them.
Employee submits
From a phone on site or a desk in the office
Identity and role
Checked against the employee’s role, team and site
Routed to approver
The chain for this request type, by team and site
Approver decides
In the app or straight from the notification
Systems updated
Calendar, rota and IT tickets changed together
Status and reports
The employee sees the outcome; the wait is recorded
Waits per approver show HR which routes to change
Sign-in with existing staff accounts
Single sign-on, so there is no new password to forget. The role comes from the HR record, and a leaver loses access when that record changes.
A home screen for every role
Each role sees its own tasks, requests and documents, team leads see the decisions waiting for them, and HR sees the requests stuck longest across every site.
Requests that find their approver
Each request type carries its own chain: a shift swap goes to the shift lead, a laptop goes to IT after the manager, and a request left too long moves up a level.
Usable on site, offline
A web app or an installed React Native app with offline drafts, photo and signature capture, and sync when the signal returns, on company or personal phones.
Mobile app developmentApproved means done elsewhere too
Approved time off lands in the team calendar and the rota, and approved access opens a ticket for IT, so nobody copies the decision into another tool.
Status staff can follow
Every request keeps a timeline the employee can open: sent, seen, approved or returned with a reason. The same timeline answers HR’s questions in an audit.
Questions about custom employee software development.
How much does custom employee software development cost?
It depends on the number of request types, whether site teams need an installed app that works offline, and which systems it writes to. Set it against what you pay now: HR platform seats staff avoid, and the hours HR spends re-typing requests from email. After discovery you get a written figure for the first release; each later request type is estimated when you ask for it.
Should we build this or buy an HR platform?
Often both. Keep the HR platform for employee records and payroll, and build the part staff touch every day where its screens or approval rules do not fit how your sites work. If the platform’s own app already covers your requests and people use it, keep it and spend the budget elsewhere. For one office team, a no-code portal builder can be enough.
How soon can a first team use it?
Once sign-in and the first request type work on their phones, which depends more on access to your identity provider and HR system than on the forms. The plan after discovery names a date for the pilot site and one for the last site, and the other request types are finished while the pilot team uses the first.
What is in the first release?
Sign-in, one or two request types with their approvers, notifications and each employee’s request timeline. Whether offline use belongs in it depends on where the pilot team works: on site it is essential, in an office it can wait. Onboarding checklists and documents follow once staff send their requests through it.
Does it work on staff’s own phones?
Yes. Staff can use a browser or install the app, on company or personal phones. The app keeps as little as possible on the device and signs out after a set time. If a phone is lost, its access is revoked from the employee’s account, so nobody has to put device management on a phone they own.
Can it connect to our HR, calendar and IT tools?
Usually, through their APIs. Approved leave goes to the calendar and rota, new starters to the IT ticketing tool, and role changes come from the HR record. Discovery checks what each system lets us read and write before a request type depends on it, and a system without an API gets a scheduled file exchange instead.
How is employee data protected?
Each role sees only what its work needs: a team lead sees their own team’s requests, and the notes behind sick leave are visible to HR alone. Personal details are encrypted at rest, every view of a sensitive record is logged, and the data can stay in your own cloud account and region.
Who owns the software and the data?
You do. IP assignment is part of the contract. The code sits in your repository, request records in your database, and employee data in the systems and cloud account you choose, so nothing about it is rented from us, and all of it stays with you if we part ways.
Who changes it as we add sites and request types?
Your HR team adds sites, approvers and simple form changes itself. New request types and integrations are built by the named engineer who signed the first release, each scoped and quoted before it starts. As headcount grows, notifications are grouped, so a manager gets one daily summary rather than a message per request.
Beside the employee software
Answers staff can look up for themselves, admin software for the teams serving customers, and a native app for site teams.
Tell us where your staff lose time to requests.
Send the email thread or spreadsheet behind the request people chase most, or tell us which HR platform staff avoid and what they do instead.
In the first call we name the request type we would build first and the systems it touches. If the app your HR platform already has would do the job, that is what we recommend.
- 1Walk us through one request, from asking to approved
- 2Hear which request type we would build first, and its cost
- 3Start with discovery in under a week
We sign an NDA before discussing your data in detail. We reply within 24 hours.