An internal ERP for running a team

What was needed was a system where a request is entered once — and the calendar, the vacation balance and the amount on the payroll sheet recalculate themselves and stay in the history. A company of 30+ people outgrew chat threads and spreadsheets: the processes existed but were written down nowhere, the rules lived in the HR manager’s head, the data lay in five unconnected places.

• Vacation and time-off requests arrived as private messages. A week later neither the manager nor the employee could reconstruct what had been agreed.
• The vacation balance was counted by hand. On termination that regularly turned into a dispute.
• Hours from the trackers were copied into a spreadsheet — one or two days of work a month, plus transfer errors.
• The payroll sheet was assembled in a spreadsheet: no change history, with formulas that broke whenever someone was hired or left mid-month.
• Public holidays, sick leave and overtime were tracked from memory. Access to payout data rested on trust.

A setup like that works until the first argument about severance pay, until a payout error spotted a quarter later, and until the HR manager goes on vacation and it turns out there is nobody left to close the month.

Not a single day of training was needed. The employee lives in a messenger that is already open: a request takes half a minute, no login and no manual required. The manager approves with one button straight from the notification. Only HR and administrators have to learn the interface — the people who work in the panel every day anyway.

The heart of the architecture is no double entry. A single approval updates the team calendar, the payroll sheet and the vacation balance by itself, and the employee gets the answer in the same chat where they asked.

Inside the system: employees and team structure, absences, vacation day balance, time tracking and payroll calculation. Each of these areas gets its own section below.

The vacation balance is kept as a ledger of movements, the way accounting does it. Every change to the balance is a separate entry with a date, a source and an author. Previously the balance was a single field in the employee card and was not calculated anywhere. Keeping the balance as a single number is a classic architectural trap of B2B systems: a dispute on termination needs the history, not a number. The base norm is 28 calendar days.

• Accrual — one twelfth of the annual quota for each month that has passed; the cron job runs on the first day. Pro-rating by days applies only to the year of hire; absences do not reduce the accrual. Naive rounding would give 27.96 instead of 28 over a year, so each month accrues the difference between accumulated rounded values: the yearly total matches the quota exactly.
• Write-off is FIFO. The rule was chosen in the employee's favour: the oldest days are spent first, so a carried-over balance is used before a fresh accrual and less of it expires.
• Carry-over and expiry — separate ledger entries: an unused balance is carried over for a year and then expires, once a year on schedule.
• Adjustment — an entry with a mandatory comment and author, available under a separate permission. The balance never goes negative: the check sits both in the form and in the service.
• Vacation beyond the balance does not block the request: the days are split into a paid and an unpaid part — the paid ones are written off from the ledger, the unpaid ones reduce the base without compensation.

A payroll sheet is created in one action. The system builds the roster from all active employees, pulls hours from the trackers, approved absences, public holidays and recurring additions — and calculates every line.

The sheet goes through a cycle: roster build → draft → approved → paid. After approval the amounts are frozen: later changes in hours and absences no longer rewrite a closed month. This is the property such systems are built for — history cannot be rewritten after the fact.

The main question asked of any payroll system is "where did this number come from". Here the system answers it itself: every line unfolds down to the formula with the numbers filled in — the base for days worked, holiday compensation, additions, the productivity coefficient, the reduction factor, the gross total and the amount to pay.

The full calculation can be opened up to the employee. The same calculation is exported to PDF for the finance team.

The system flags the lines that must not be closed without a second look: zero hours for an hourly employee, unapproved time off inside the period, a missing exchange rate, a fixed payment when there are absences. Each flag explains what exactly is wrong and how it affected the amount.

Errors are visible in the draft, before the period is closed. That is an order of magnitude cheaper.

A manager needs a picture of one particular person. A single page collects average hours per day, total time worked, activity percentage, days of vacation, sick leave and time off, the productivity index, active additions and their effect on the payroll fund, the dynamics of hours and the payout history.

Separately — a counter of days until the contract ends: there is still time to find a replacement.

The actual development time is about 80 person-hours. That is roughly two working weeks of one developer: it covers people and absences, time tracking, payroll calculation, integrations and the vacation balance together.

The active phase was April and May: about 60 hours, three quarters of the whole time. Everything that counts money fits into it: the payroll calculation core, the pay rules, the second source of hours and the external integrations. Before that — roughly 20 hours on the skeleton, people, permissions, the API and time tracking: on 25 April 2026 live accounts appeared in the panel and the company stopped keeping its people records in spreadsheets. After that — targeted work on a product already in use.

The figures are taken from the repository history: commits are grouped into working sessions by the intervals between them, so the hours are a lower bound, not a time tracker export.

Modules arrived as they became ready, not as one release at the end. Merged pull requests fell in April, May and July, and the deployment on the main branch was started manually every time. You can work this way when a rollback to the previous version costs one command and every branch runs a style → analysis → tests pipeline, three steps in parallel.

At launch the team got not a stub but a working loop — people, absences and time tracking, — and used it while the pay rules, the integrations and the vacation balance were still being written. The usual order for us: first what can be used tomorrow, then what counts money. Not a single day was spent waiting for “everything to be ready”.

The system pays for itself in hours that are no longer spent and in errors that no longer reach the payout. The hours are simple to count: below is the work that used to be done by hand every month, and what is left of it. Errors are harder to count, but a single underpayment surfacing a quarter later costs more than a whole month of saved time.

What the system brings over one year and over two. Every month it gives HR and finance back two to four full working days. Over a year that adds up to 24–52 working days, over two years — between 48 and 105. The whole development, including the integrations, the vacation ledger and notification routing, took about 80 person-hours — some ten working days — so the invested time comes back within the first three to five months of use, and after that it is pure gain.

The twenty hours that carried the system to launch paid for themselves in the very first month. From there the effect only accumulates: the system keeps returning the same two to four days every month for as long as the company uses it. The count is in time, which is why the figures transfer to any company: put in your own rates and you get the sum.

The most expensive load is the one that stays in people's heads. Remembering the day balance, remembering who to write to, remembering what has to be checked before the payout — all of it takes attention even while a person is busy with something else. The system takes it over.

Three techniques that make it work:

• The system decides for people everything it can decide itself. Working days, public holidays for the employee's country and the currency rate are filled in automatically. The only questions asked are the ones that genuinely need a human decision.
• The hint arrives at the moment of the decision. The day balance and overlaps with colleagues' vacations are shown right in the request, where the decision is made. There is no need to look them up in a separate report.
• The system catches the errors. Zero hours for an hourly employee, unapproved time off, a missing exchange rate — all of it is flagged in the draft. There is no checklist to remember before closing the month.

An internal system lives for years and outlives several generations of the team. So dependability here is measured by one thing: can a calculation rule be changed safely two years from now without breaking closed periods. Below are six pillars, each of them verifiable in the code.