How to Build an App Like Workday (HR and Finance)

Workday HCM costs $100 to $250 per employee per year. For 500 people, that is $50,000 to $125,000 annually, every year. Add Workday's financial management module and the cost reaches $300 to $500 per employee — $150,000 to $250,000 per year for a 500-person company. A modular HR and finance platform built to your workflows costs $200,000 to $320,000 once.

But cost is not the right starting point. Most mid-market companies using Workday actively use fewer than a third of the modules they pay for. The ROI argument for building your own is not the subscription fee. It is that you are paying for a platform designed around a standard corporate org structure, and your structure is not standard.

This guide covers what it takes to build a modular HR and finance platform, which modules to build, the technical decisions that matter most, and who should actually pursue this.

The right framing: do not build all of Workday

Workday is not one product. It is a platform with HCM at its core, surrounded by financial management, workforce planning, learning management, talent acquisition, payroll for 150+ countries, and an integration layer that took 20 years and billions of dollars to build.

You are not building any of that. If you tried, you would spend $5 million and four years.

What companies building their own HR system actually need is the 20% they use every day: employee records, org chart, time and attendance, leave management, performance reviews, basic expense reporting, and an applicant tracking system for open roles. That scope is well-defined and buildable in 20 to 26 weeks.

The exercise before you write a line of code: list the Workday modules your HR team opens every week. Then list the workflows those modules cannot handle correctly because your org structure is unusual. The gap between what you pay for and what actually works for you is the build case.

Who builds this instead of buying Workday

Three categories of company regularly build their own.

Companies with non-standard org structures: project-based staffing firms where employees bill to client matters, multi-entity groups where an employee may work across two entities in the same month, franchise operators where each franchisee has its own HR requirements but the parent needs consolidated reporting. Workday is built around a traditional functional hierarchy. When your structure is not that, the workarounds accumulate.

Industries with unique workforce compliance: healthcare organizations that track clinician credentialing and state licensing alongside standard HR; construction companies that handle union rules, prevailing wage, and certified payroll reports that are legally required for government contracts; transportation companies that need HOS compliance data connected to their workforce records. These compliance requirements are not features you add later. They define the data model from day one.

Companies that acquired multiple HR systems: after an acquisition, the acquiring company ends up with three different HR systems running in parallel — none of which talk to each other. Building one unified system is often cheaper than licensing Workday and migrating three legacy systems into it.

Core modules to build

Core HRIS

The foundation is the employee record. Each record holds personal information, emergency contacts, employment history, compensation history, and a document store (offer letters, performance reviews, signed policies). An employee has a position: a job code, a grade, and a salary band. Positions are distinct from people — a position can be filled or vacant, and tracking vacant positions is how headcount planning works.

The org chart maps reporting relationships. Manager to direct report. This is not just a display feature — it drives who can see what. Build the org chart as a recursive data structure in PostgreSQL so you can query the full reporting chain of any employee in a single database call.

Role-based access control is the hardest technical decision in this module, and it cascades through every module that follows. Admin can see all employee records. An HR business partner sees a specific subset of employees. A manager sees their direct reports and their reports' direct reports. An employee sees their own record only. This permission model must be applied at the database query layer, not as a frontend filter. If it lives only in the UI, any API call or data export bypasses it. Design the RBAC schema before you build anything else.

Time and attendance

Timesheets are how hourly and salaried-plus-OT employees report hours. The timesheet covers a pay period — weekly or bi-weekly. Employees log hours by day and project or cost center. Managers approve before the pay period closes. Unapproved timesheets do not move to payroll.

Clock-in and clock-out can be web-based (employee opens the app and taps) or connected to a physical time clock. Meal break rules are jurisdiction-specific — California's 30-minute meal break after 5 hours of work, for example. These rules must be configurable by location, not hardcoded.

Overtime calculation is where this gets complex. Federal US overtime kicks in over 40 hours per week. California pays overtime over 8 hours per day and double-time over 12 hours. Some union agreements have their own OT rules. Each rule set is a separate calculation path. Design a rule engine rather than hardcoding overtime logic — you will need to add new jurisdictions and agreements as the company grows.

Approved hours feed directly into payroll. This is the most critical integration in the system. The data contract between time and attendance and payroll — exactly what fields are exported, in what format, at what point in the approval workflow — must be designed before you build either module. Most HR builds break down here because the modules were built in sequence rather than designed together.

Leave management

Employees accrue PTO, sick leave, and any jurisdiction-specific leave (FMLA in the US, shared parental leave in the UK). Two accrual models: periodic accrual (1 day per month, calculated on the first of each month) and lump-sum grant (the full year's balance posted on January 1 or the employee's anniversary date). Accrual policies are configurable by leave type and employee group.

The leave request workflow is an approval chain: employee submits, manager approves or declines, balance updates on approval. The leave calendar shows the team's upcoming approved leave so managers can spot conflicts before they approve a request.

Carry-over limits matter. Many companies allow employees to carry over unused PTO up to a cap (say, 5 days). The balance calculation must handle carry-over, forfeiture, and negative balances (when an employee takes leave before accruing enough to cover it) without manual intervention.

Performance management

The annual review cycle runs in three phases. First, goal-setting: managers and employees agree on objectives for the year — OKR format or KPI format, both are common. Goals are stored with due dates and measurable targets. Second, mid-year check-in: a lightweight progress update, no formal rating. Third, annual review: the manager rates the employee against their goals and on competencies, the employee provides a self-assessment, and optionally peers provide input (360-degree feedback). The calibration session is where managers from the same level review ratings across their teams to ensure consistency — this is an admin workflow where HR can view and adjust ratings before they are finalized.

Performance ratings connect to merit increase workflows. A rating of "Exceeds Expectations" triggers a higher increase percentage than "Meets Expectations." This link between ratings and compensation adjustments is often where manual spreadsheets live today — it is the workflow that most companies want automated.

Recruiting: basic ATS

A job requisition is the formal approval to hire. The recruiter opens a req, links it to a position, and the req goes through an approval workflow (manager, HR, sometimes finance). Approved reqs post to an internal job board and optionally to external job boards.

Applications are tracked through stages: Applied, Phone Screen, Interview, Offer, Hired or Rejected. Each stage transition is logged with a date and the user who made the change. Offer letter generation pulls from a template library — the offer letter populates automatically with the candidate's name, title, salary, and start date.

This is a basic ATS. It is not LinkedIn Recruiter or Greenhouse with AI matching. It handles the core workflow that most companies do on spreadsheets and email threads today.

Financial management: the operational layer

The financial management module is the operational finance layer — not a general ledger. Use QuickBooks or Xero for accounting. Build the layer that connects operational activity to accounting.

The chart of accounts defines the categories expenses are coded to. Cost center structure maps teams and departments to budget owners. Expense reporting is the daily workflow: an employee submits an expense (receipt upload, amount, category, description), the manager approves, and finance processes the reimbursement. Budget-versus-actual by department shows every cost center owner their spending against their budget for the current period.

What this does not cover: journal entries, accounts payable, accounts receivable, bank reconciliation, multi-currency consolidation. Those belong in your accounting system. This module sends approved expense data to your accounting system via an API sync — it does not replace it.

Integration requirements

Three integrations are not optional.

Payroll system. Approved timesheets, salary changes, and new hire data must flow to your payroll processor. ADP and Paychex both provide APIs. The integration sends a payroll file at the close of each pay period. Map your data schema to the payroll system's field requirements before you build time and attendance. Getting this wrong means a payroll error on day one, which is a trust-destroying event.

Identity provider. Employees log in with their work credentials — the same ones they use for email and other company tools. SAML 2.0 or OIDC (OpenID Connect) handles this. Your HR platform is the service provider; your identity provider (Azure AD, Okta, Google Workspace) is the identity source. Single sign-on also means that when an employee is terminated, disabling their account in the identity provider revokes their access to the HR system automatically. This is a security requirement, not a convenience feature.

Benefits carrier. Health insurance enrollment data must sync to the carrier. New hires who enroll during their onboarding window need their data sent to the benefits administrator. Life events (marriage, new dependent) trigger changes. Most carriers accept an 834 EDI file for enrollment transactions. This is the unglamorous integration that most HR builds delay — do not delay it. HR teams manage open enrollment manually on spreadsheets until this is done.

Tech stack

Frontend: React. Single-page application with module-based navigation. Each module (HRIS, time, leave, performance) is a separate route group.

Backend: Node.js. REST API. Each module has its own service layer, but they share the same database and authentication context.

Database: PostgreSQL. Employee records, org structure, timesheets, leave balances, performance data, requisitions, expense reports. One database, separate schemas per module. PostgreSQL's row-level security policies can enforce RBAC directly in the database query layer — this is the cleanest implementation.

Authentication: SAML 2.0 or OIDC integration with your identity provider. Do not build your own auth. Use passport.js or a managed auth library that handles SSO, session management, and token refresh.

Email: SendGrid for transactional email. Every workflow step triggers a notification: approval request, leave decision, offer letter ready, performance review due. Transactional email should be templatized and auditable.

Redis: Session management and short-lived token storage for the OIDC flow.

Timeline and cost

Timeline: 20 to 26 weeks for a modular HCM covering core HRIS, time and attendance, leave management, performance management, basic ATS, and expense reporting. The longer end reflects the SSO integration and payroll sync, which require coordination with third-party systems and their testing cycles. Full financial management — multi-entity cost center allocation, full budget workflow, and accounting system sync — adds another 10 to 14 weeks.

A typical phasing: weeks 1 to 4 cover RBAC architecture and core HRIS; weeks 5 to 10 cover time and attendance with payroll integration design; weeks 11 to 16 cover leave management, performance management, and the ATS; weeks 17 to 22 cover expense reporting, SSO integration, and reporting; weeks 23 to 26 cover QA, payroll parallel-run testing, and deployment.

Cost: $200,000 to $320,000. The range reflects org complexity (multi-entity builds cost more), the number of jurisdictions in the time and attendance module, and whether full financial management is in scope. Ongoing hosting and maintenance runs $2,000 to $4,000 per month.

Build versus buy

Keep Workday if you need global payroll, multi-currency financial consolidation, advanced workforce planning, or the depth of its talent management suite. Workday earned its market position with those capabilities.

Build your own if your org structure does not fit the standard model, if your industry has compliance requirements that Workday handles generically rather than specifically, or if you are consolidating multiple HR systems after an acquisition. At 500 employees paying $125,000 per year, the custom build pays back in under three years — and you end up with software that actually matches how your business operates.

The strongest signal that you should build: when your HR team spends more time working around Workday than working in it.