Yes — and if you’re asking, your people data has probably scattered across a payroll tool, a few spreadsheets, and someone’s inbox.
HR is full of details that are specific to your company: how your org is actually structured, what counts as a leave type, which approvals a request goes through, what you track about a role versus a person. Packaged HR tools bake their own answers to all of that into the product. Spreadsheets don’t enforce any answer at all. Either way, the parts that make your company yours are the parts that don’t fit.
The real question isn’t “can I track employees?” It’s “can I run HR the way my company actually works, without it living in spreadsheets or bending to someone else’s HRIS?” There’s a good answer — once you see why the usual options fall short.
Why packaged HRIS and spreadsheets fight you
A packaged HRIS has firm opinions: a fixed idea of departments and reporting lines, a set list of leave types, a workflow you adjust only as far as it lets you. When your structure or your policies differ — and they always do somewhere — you get a workaround, or you simply can’t model the thing you need.
Spreadsheets have the opposite failure. They’ll hold anything, enforce nothing, and quietly fall out of sync: who reports to whom, how much leave is left, which certifications expired. People data spread across tabs isn’t a real system; it’s a liability waiting for an audit.
The two ways teams usually lose
Stitch together spreadsheets and a payroll tool. Flexible and cheap, structurally unable to enforce policy or keep one trustworthy version of the truth. It breaks the moment you have real headcount, real approvals, or a compliance question.
Buy a rigid HRIS — or build one from scratch. A packaged tool fits until your structure or policy doesn’t match, then you’re bending it. A from-scratch build fits on launch day, costs months, and becomes yours to maintain forever.
There’s a third path.
The third path: start from a foundation, then shape it
dForge ships a working HR core out of the box: departments, positions, employees, leave requests, attendance, skills, training and enrollments, and employee documents. That’s a real foundation you can run from day one.
And because the model is defined by metadata rather than hard-coded, you shape it to your company:
- Model your real org — your departments, reporting lines, and the distinction between a position and the person filling it.
- Define your own leave types and policies — and the approval workflow each one follows.
- Add the fields and entities you track — certifications with expiry, equipment assignments, a probation review, whatever your HR process actually needs.
- Wire the rules — approval routing, validation, lifecycle states on a request, reminders for expiring training.
Fitting it to your company is configuration, not a code fork — so the next policy change is a change, not a rebuild.
And the HR system you shape is one you own
The HR system you build on dForge is a standard PostgreSQL database — your org, your people records, your leave and training history, in real tables you can query, back up, and self-host. People data is among the most sensitive and most regulated you hold, so owning it outright — isolated, exportable, on infrastructure you choose — matters more here than almost anywhere.
We covered exactly where that ownership line sits — and where it doesn’t — in Only You Own Your Data.
Where the line is
dForge is the internal HR platform — your org, people, leave, attendance, skills, training, and documents, shaped to how you operate. Payroll calculation and statutory filing aren’t part of the HR module today, and it isn’t a benefits-carrier marketplace; teams typically run payroll through an integrated provider, with data flowing in via API and out via webhooks.
So if payroll and benefits administration are what you’re after right now, plan to integrate a specialist for those. If you need the durable, owned core that knows your org, your people, and your policies — shaped to your company — that’s what the HR module is for.
Frequently asked questions
Can I model my own org structure and reporting lines? Yes. Departments, positions, and employees are part of the model, and you shape the structure — including the difference between a role and the person in it — to match your actual organisation.
Can I define custom leave types and approval workflows? Yes. Leave types, the policies around them, and the approval routing each follows are configuration of the model, so they match your company’s rules rather than a vendor’s defaults.
Do I need developers to build a custom HR system in dForge? You don’t start from scratch — the HR foundation is there on day one. Shaping it is configuration of the metadata model rather than application engineering, so much of it doesn’t require a developer; deeper changes are still configuration, not a custom codebase.
Does dForge run payroll? Not today — the HR module is where your org, people, leave, attendance, skills, training, and documents live, and teams currently run payroll through an integrated provider (data in via API, out via webhooks). Note that dForge does include a full double-entry general ledger on the finance side, so the accounting those payroll runs feed into can live in dForge even while the payroll calculation itself sits with a specialist.
Is my employee data actually mine? Yes. It runs on a standard PostgreSQL database, one per tenant, that you can query directly, back up, and self-host — which matters for the sensitivity and compliance demands of HR data. See Only You Own Your Data.
If your people data has outgrown spreadsheets and packaged HRIS tools don’t match how your company works, there’s a path between them: start from a real foundation, shape it to your organisation, and own what you build. That’s what dForge is for — see how the whole platform is built.
