HR software handles information that different employees and managers should access in different ways. EidenTech can develop staff records, onboarding, leave requests, and administration around your actual policy and operating process. The scope separates routine self-service from confidential administration and identifies which existing tools remain responsible for payroll or other specialist functions.
How we approach your project
Model employee records and access responsibilities
An employee record can contain contact details, employment context, documents, manager relationships, and information with different sensitivity. We identify the fields needed for the first release and who may read, edit, or export them. An employee’s view should not expose unrelated staff records, while a manager’s access should follow an agreed relationship rather than an assumed hierarchy. Document visibility and retention expectations need explicit ownership. The backend enforces these boundaries, with acceptance checks for role changes, account removal, and attempts to access another employee’s restricted information.
Translate leave and approval policy into tested rules
Leave types, working calendars, entitlement inputs, approval chains, and changes to a request need agreed business rules. We ask the policy owner to approve those rules and representative examples before implementation. Different locations or employment arrangements may require different configuration, rather than a universal default inferred by the software. A pending request is not an approved absence. The interface should explain balances, date conflicts, reviewer ownership, and rejected or revised requests. Rule changes need a plan for existing records so a policy update does not silently rewrite earlier decisions.
Coordinate onboarding, changes, and connected tools
Joining, changing a role, and leaving involve tasks owned by several people. We scope checklists, required documents, assigned actions, and what counts as complete. Connections to payroll, attendance, identity, or accounting tools depend on supported interfaces and explicit record ownership. An exported file needs field validation and an accountable review before use where appropriate. The application should show outstanding work and failed exchanges. It should not treat a checklist tick as proof that a separate provider account has been updated or a payroll calculation has been approved.
Release with privacy-aware administration and handover
The first release can focus on one defined set of employee and approval journeys. We test employee, manager, and administrator roles using representative records and exception cases. Operational guidance includes inviting staff, revoking access, correcting a record, managing confidential documents, and investigating a rejected request. Policy, retention, payroll, and jurisdiction-specific obligations need review by qualified business owners; software implementation does not establish those requirements by itself. Handover records account and configuration ownership, export responsibilities, and the process for requesting changes as the organisation’s policies and structure evolve.
What we can deliver
We agree the requirements and responsibilities before development begins. Your project scope can include:
- An employee data and role model with explicit field visibility, policy ownership, and boundaries with specialist HR systems.
- Scoped employee self-service, leave, onboarding, and administration workflows with validated approvals and understandable status.
- Agreed document and system-exchange handling with access controls, record references, and visible exceptions.
- Role and policy acceptance examples, operational and configuration documentation, and a defined initial rollout and ownership plan.
Technology choices for your requirements
The stack follows your integrations, operating model, and maintenance needs. These are options to review during discovery, rather than a fixed stack promised for every project.
- React and TypeScript for employee, manager, and administrator workspaces.
- Server-side role and record checks, PostgreSQL application records, and scoped document storage.
- Supported identity, payroll, attendance, or business APIs where the agreed workflow and policy owner require a connection.
Planning questions, answered
Can employees request leave and track its status?
Yes. We can scope leave types, calendars, entitlement inputs, reviewers, and changes to a request. The policy owner needs to confirm the rules and examples so the application reflects your operating requirements rather than a guessed default.
Can HR, managers, and employees have different access?
Yes. We define field and record visibility for each role and enforce it in backend reads, writes, documents, and exports. Testing should include a changed reporting relationship and a user who no longer has the role granting access.
Can the software connect to our payroll provider?
Yes, where supported APIs or permitted exports are available. We define the records, approval, and reconciliation requirements before implementation. Payroll rules and any applicable obligations remain subject to review by the people qualified to approve them.
Can we start with onboarding or leave instead of a full HR suite?
Yes. A focused workflow can reduce the initial scope while preserving clear employee records and access responsibilities. We identify dependencies on existing tools and document which HR functions remain outside the first release.
Tell us what needs to work better.
Share your idea, existing workflow, and the outcome you need. We will help shape a practical starting point.
Start a project conversation ↗Read our website, chatbot, and product planning guides →