How to Build Custom HR Software in 2025

Custom HR software development is the work of building the employee record, the roles that may see it, and one hiring, leave, or onboarding workflow around the way the company already works. A packaged product is the right start when that workflow fits the product. A custom build is the right start when the roles, the approval chain, or the systems around payroll and contractors do not.

This page is a scope guide: what the first release should contain, how permissions differ from a login, what has to move from the old system, which integrations are real, and what belongs in an estimate. It does not publish a price, a week count, or a ranking of HR brands. A conversation that starts from a logo ends in a feature list. A conversation that starts from one workflow ends in a scope. The same material is available as Episode 22, How to Build Custom HR Software.

What is custom HR software development?

It is a system your company owns for the employee file and the processes that change that file: a hire becomes an employee, a manager approves leave, a status change reaches payroll, and a departure closes access. It is not a slogan for “digital HR”, and it is not every module a vendor brochure lists.

Four products get mixed up in the same search, and they do different jobs.

Two buyers show up with the same words. An operations lead wants an internal tool for one company. A founder wants a product other companies will pay for, with a separate tenant, a billing account, and an admin who is not your HR team. The second job is SaaS development, and the application work is SaaS web development. The first job is an internal system. Putting both in one backlog is how a leave tracker grows a subscription engine it does not need.

Shakuro’s published work does not present an HR system. The screens in this article are interface concepts from Shakuro and Conceptzilla. They show how a directory, a task list, or a dashboard can be drawn. They are not evidence that a client runs payroll, hiring, or reviews on that screen.

Which process belongs in the first release?

One workflow that already hurts, plus the employee record that workflow needs. Not onboarding, reviews, recruiting, time, benefits, and analytics in the same release. A first release that tries to cover the whole HR department ships none of it in a form HR will trust on a pay week.

The record itself is small and strict. Each person needs a stable id that is not the work email, a legal name, a work email, a start date, a status, a manager, a department, a location, and an employment type: employee, contractor, or another type the policy names. Email changes. The id should not.

Payroll tax is the boundary most briefs cross too early. The custom tool can send approved hours, a status change, and a compensation change. Tax tables, filings, and garnishments stay with the payroll provider. A first release that calculates multi-country payroll is a payroll product. This page is not that product.

Project-based firms, including architecture and construction teams, often outgrow a generic directory for a different reason: a person holds a certification with an expiry, a site assignment, and a contractor record that is not the same as an employee record. That is still one workflow, not a reason to rebuild the whole suite. A clinic or hospital that must track license expiry and a shift roster is a healthcare software problem with an employee file inside it, not a startup leave tracker with a medical label.

Training status is the other boundary. Who finished a safety module, and which role should be offered the next course, belongs on the learning side: LMS development for the course and the completion record, and a corporate training platform when the audience is employees rather than a school. The HR record can store “completed on this date”. It should not host the player. A suggestion engine that picks the next course from a role is an AI learning platform decision. It is a poor first feature inside the employee file.

How should roles and access work?

A shared HR login is not a permission model. Each sensitive field needs a named role that may read it, a named role that may change it, and a second person where the change is pay, status, or access itself. Page-level access, “managers can open the HR app”, still lets a manager export a salary column if the column is on the page.

Three rules keep this from becoming a spreadsheet of exceptions.

• The person who changes a salary, a status, or an access role is not the only person who can approve that change.
• A manager sees direct reports. “Everyone in my department” is a different rule, and it needs its own name.
• Offboarding closes the identity account, the tokens, and the shared mailboxes in the same change as the status. Hiding a menu item is not offboarding.

Single sign-on tells you who the person is. It does not tell you which field they may see. A group called Managers can be allowed into the application and still blocked from compensation. If the only control is the group, you do not have field-level access. The screens people actually use, the request, the approval, and the audit line, are UI/UX design work. A permission matrix that exists only in a ticket will not survive the first exception.

What has to move from the old system?

The current employee file, the history you are legally or operationally required to keep, and the requests that are still open. A migration that copies a contact list and calls it done leaves HR in two systems on the next pay week.

Move these, and name the source of each:

• Stable id, legal name, work email, start date, status, manager, department, location, employment type.
• Compensation history, if the payroll provider is not already the system of record for it.
• Documents with a type and a date. A folder of unnamed scans is not a document type.
• Open requests: leave, onboarding tasks, and any approval that has an owner and a due date.
• The org as of the cutover date. Previous managers only if a report or a dispute still needs them.

Do not move rejected candidates, duplicate emails, test users, or a “notes” column nobody can explain. Those rows become tickets. They do not become history.

Run the import against a copy first. Compare counts: people, open requests, documents, and the number of people with no manager. Cut over in a window that is not the day the payroll file is produced. Until the counts match, the old system still accepts writes. A migration with no rollback is a bet that the first import is perfect. It will not be.

The import, the field map, and the comparison report are part of the build, not a favor after launch. That work sits with the application: custom web application development, and the connectors that read the old export are usually Python app development.

Which systems should HR software connect to?

Identity, the payroll provider, and the one other system that already holds a fact the employee record must not invent. A diagram with twelve logos is not an integration. An integration is a field, a direction, and a rule for which system wins when the two disagree.

• Identity. The HR status change creates, suspends, or closes the account. The identity provider does not become the org chart.
• Payroll. Approved hours, status, and compensation changes go out. Tax and filings do not come back as something the HR tool recalculates.
• Directory or chat. A department name can sync. A salary must not.
• Contractor tool. A worker profile, a compliance document, and an expiry date can sync into the HR record. If the contractor system is the source for the site safety file, the HR copy is a status, not a second original. Write down which side wins.
• Learning. Completion date in, course content out. See the learning pages above rather than rebuilding a classroom inside HR.

A file export on a schedule is a valid first integration when the payroll provider has no API you are allowed to call. An API is better when the status change must close access the same day. A no-code connector can move a notification. It should not be the only copy of the employee record if you cannot export history, enforce the field rules above, or delete a person from every place the connector wrote them. That limit is the useful part of a low-code development conversation, not a reason to skip the record.

Employees are not customers. Do not copy the employee file into a customer data platform so a campaign, an ad audience, or a sales tool can read it. A customer profile and an employee record have different purposes, different access, and different deletion rules.

Managers who approve requests from a site, not a desk, may need a phone view of the queue and nothing else. That is a narrow mobile app development scope. Two native apps in the first release, with the full record on the phone, are a second product. The leave request and the approval queue themselves are closer to a productivity web app than to a marketing site.

Should you build, buy, or customize?

Buy when the workflow fits the product and the product can export the employee file. Customize when the product allows the approval chain and the field rules without a private fork. Build when the roles, the contractor mix, or the handoff to payroll cannot be expressed in the product you would otherwise rent.

An off-the-shelf tool is not a failure. It is the right answer when you have not yet found a workflow the product cannot run. Custom HR software development is the right answer when you have. A demo that looks close is not a test. The test is a real approval, a real contractor expiry, and a real export of one leaver.

Analytics belongs in this choice. A reliable HR report is a count you can trace to the same employee rows: headcount by status, open requests past a due date, certifications past expiry, time from “hired” to “start” if you store both dates. A turnover score with no written definition is not a report. Uptime badges and “AI insights” do not make the count reliable. If the number cannot be opened into the people it names, it does not belong in the first release.

What belongs in the estimate?

The estimate is the workflow, the roles, the migration, and the integrations. A license line is not the estimate. A week count without that list is a guess, so this page does not publish one, and it does not publish a price.

Ask for these lines before you compare proposals:

• The one workflow, and the person who receives the result.
• The roles, the sensitive fields, and which change needs a second person.
• Countries and employment types in scope. A second country is a second policy, not a checkbox.
• Documents, who may read them, and what must be kept when someone asks for deletion.
• Integrations: identity, payroll, and any contractor or learning system, each with a winner when the two sides disagree.
• Migration: volume, a dry run, and a cutover that avoids payroll close.
• A phone view, if managers are not at a desk. Not two native apps by default.
• Who trains the HR administrators, and who answers after launch.

Permission tests are part of the estimate, not a later wish. Someone has to try the employee role, the manager role, and the payroll role against the same record and show what each one cannot see. That is QA on the rules, not a visual pass.

If the work continues after the first workflow, a second release for the next process is a staffing question. An extended development team fits when the same people should keep the record, the roles, and the integrations. It does not fit when the first workflow is still unnamed.

Get in touch with the current system, the one workflow, and the payroll provider you will not replace. That is enough to say whether the next step is a product you can rent, a customization, or a build.

The calculator below is a starting scope for a software project. It does not know your countries, your payroll provider, or your document rules. It is not a quote.

Which rules apply to employee records?

Employee data is regulated where the person and the employer are, and the software has to be able to find, export, restrict, and delete a person without deleting the records a statute still requires. This page is not a legal opinion. Counsel names the basis and the retention period. The build has to be able to follow that instruction per field, not per mood.

In the European Union, Regulation (EU) 2016/679 is the general rule. Article 6 lists the lawful bases, including a contract, a legal obligation, and legitimate interests. Article 9 prohibits processing health data, trade union membership, and the other special categories it names, unless an exception applies. One exception, Article 9(2)(b), is employment, social security, and social protection law, where Union or Member State law or a collective agreement authorizes it and sets safeguards. Article 88 lets Member States set more specific rules for employee data in the employment context, including recruitment, the contract, organisation of work, health and safety, and termination. A leave reason that records a diagnosis is not the same field as a leave balance. Do not store the diagnosis because the form had a free-text box.

Article 17 gives a right to erasure where a ground applies, including where the data are no longer necessary for the purpose. Employment files often have a separate legal reason to keep a subset. The product needs a deletion path that removes the fields counsel says can go, and keeps the fields counsel says must stay, including the copies an integration wrote.

In California, the exemptions did not survive. The state Department of Justice states that the exemptions for employment-related personal information and for business-to-business transactions in Civil Code section 1798.145(m) through (n) expired on December 31, 2022. The page is the California Consumer Privacy Act overview. A California employee file is not outside that statute by default. The software still needs a way to locate a person’s records and to act on a request counsel has accepted.

Hiring software that scores people is a discrimination problem, not a feature. The U.S. Equal Employment Opportunity Commission’s April 2024 sheet, What is the EEOC’s role in AI?, states that federal employment discrimination laws apply to AI and other new technologies in employment just as they apply to other employment practices. It names recruiting, screening, and hiring, and also monitoring, productivity, wages, promotion, and firing. It gives the example of a resume screener programmed to reject people on a protected characteristic, and of a neutral tool with an unjustifiable disparate impact. A first release should not include a resume score, a speech-pattern interview score, or a termination recommendation. If a later release adds any automated selection step, the adverse-impact question is part of the scope, not a blog footnote.

Some enterprise buyers will ask for an information security management certification before they share an employee file. Ask which certificate, which scope, and whether they need it from the vendor, from the host, or from your own company. A logo on a slide is not a control. Access reviews, encryption of the document store, and a trail of permission changes are controls the application can actually ship.

How do you roll this out without breaking a pay period?

Pilot with one team whose payroll calendar you understand. Run the new workflow and the old one in parallel until the counts match: people, open requests, and the file the payroll provider accepted. Train the HR administrators on the roles before you train the whole company. Then close write access in the old system.

Three conditions before that close:

• The dry-run counts matched, including people with no manager and documents with no type.
• One real leaver was processed, and the identity account actually closed.
• The payroll file for the pilot was accepted by the provider, not merely exported.

After launch, someone has to answer when a sync stops or a role is wrong. That is support on a system that holds pay and access, not a ticket queue with a three-day silence. Put the response expectation in the estimate. A tool HR cannot call during a pay week will be abandoned for the spreadsheet it replaced.

What should you ask a development company?

Ask for the workflow they will ship first, the fields each role cannot see, and the payroll provider they will not replace. A company that answers with a module catalog, a guaranteed week count, or a client story it cannot show on a work page is selling a template. Shakuro designs and builds custom software. This article does not rest on a published HR case, because the works list does not show one. The useful next step is a scope, not a borrowed story.

Bring this list when you get in touch:

1. The one workflow the first release must finish, and the person who receives the result.
2. The current system, and whether you have exported one employee, one document, and one open request from it.
3. The roles, and the one field a manager must not see.
4. The payroll provider, and the file or API it already accepts.
5. Any contractor system that must sync a profile, a document, and an expiry.
6. The countries in the first release, and who will name the retention rule.

Get in touch when that list exists, even as notes. We will say whether the next step is a product you can rent, a customization, or a build, and what the estimate has to include. We will not invent a price from a headcount.

FAQ

What is custom HR software development?

It is building the employee record, the roles that may see each sensitive field, and one workflow, such as hire handoff, leave, or onboarding tasks. Payroll tax, a resume scorer, and a full performance suite are not that first release.

How much does custom HR software cost?

As much as the workflow, the roles, the migration, and the integrations. A second country, a contractor document sync, and a payroll file that must be accepted are cost drivers. This page does not publish a dollar figure, because a figure without that list is a guess.

How long does the first release take?

As long as the field map, the dry run, and the payroll file take. A single-country leave workflow with a tested export is a smaller job than five countries and a contractor compliance sync. This page does not publish a week count.

Should we buy off-the-shelf HR software instead?

Yes, when the workflow fits and you have tested the export. Customize when the vendor can add the field and the role without a private fork. Build when the approval chain, the contractor record, or the payroll handoff cannot be expressed in the product.

Can we start with one module?

Yes. That is the point of the first release. The module still needs the employee record and the roles. A leave form with no record behind it becomes a second spreadsheet.

How should contractor profiles sync?

Send the worker profile, the compliance document, and the expiry date. Name which system wins when the two disagree. If the contractor tool owns the site safety file, the HR side stores the status, not a second original.

What makes an HR report reliable?

You can open the count into the employee rows that produced it: headcount by status, overdue requests, expired certifications, or days from hired to start if both dates exist. A score with no written definition is not a report.

Does the CCPA apply to employee data?

The California Department of Justice says the employment-related exemption in Civil Code section 1798.145(m) through (n) expired on December 31, 2022. Whether a specific request must be honored still depends on the business, the data, and counsel. The software has to be able to find the person.

What should we ask a development company?

Which workflow ships first, which field a manager cannot see, and which payroll provider stays. Ask to see a published case if they claim one. A module catalog is not an answer.