Leave Management for Multi-Location Teams: One Policy Per Country

How we wrote a 32-day leave rule for a team spread across three countries, why the spreadsheet stopped being able to count it, and how that turned into Teamtopia, a leave management tool we built with our partners at Push and now share with 10+ companies.

In 2023 we wrote a rule that still applies at Flatstudio: every person on the team gets 32 days of leave a year, regardless of which country they live in. The rule took two paragraphs in a document. Counting it by hand for 18 people in three countries turned out to be impossible. This article is about how we arrived at that rule, why the spreadsheet stopped holding it, and why a product design studio ended up building its own leave management system instead of buying one.

This is the personal version of the story. The technical part, how we modeled the product and why a single day became its atom, Andrei Zolotukhin covered separately. This is about what came before the model.

TL;DR

• Flatstudio grew from 12 to 18 people spread between Lisbon, Ukraine and cities that change every month. Portuguese leave law does not work for two thirds of a team like that.
• We wrote a rule: 22 days of Portuguese statutory leave plus 10 days for the public holidays of whatever country the person lives in. 32 days in total, no more than 15 in a row.
• Every time the team or the rules changed, understanding the spreadsheet again, rewriting the formulas and pulling out the numbers we needed took a manager and me between 30 minutes and 2 hours. And the spreadsheet still could not answer the only question that mattered: can we let this person go on these dates without hurting the project?
• Together with Push we built Teamtopia. The first version has been live since 2023 and is used by 10+ companies and around 250 people. We are now building a second version where a manager picks a country and the statutory leave rules for it load automatically.

One company, three calendars

When Flatstudio had 12 people, leave rules lived in our heads. Someone wrote "I'm off next week" in the chat, someone replied "ok", and that was enough.

The trouble started with geography rather than headcount. A main location in Lisbon means Portuguese labor law: 22 days of annual leave, accrued at two days a month, plus public holidays on which nobody works. Republic Day, the two independence days, the religious holidays.

But part of the team lives and works in Ukraine, with different public holidays and a different rhythm to the year. Another part is permanently on the move: a new country every few months, a new time zone, a different contract type. For them a Portuguese holiday meant a day off that had nothing to do with their life, while their own national holiday stayed a working day.

It turned out that at least three different calendars coexisted inside one company, and no ready-made policy described all three at once.

That is where the brief that later became Teamtopia came from: a leave management system for companies whose people work from different cities and countries under different rules but have the same right to rest, where everyone from an employee to a client can see who is away, when and why. Adding a new location or team should be as easy as adding a row to a spreadsheet, minus the formulas.

How we came up with the 32-day rule

We wanted one thing: for people to be able to rest with their families on the holidays of their own country, rather than the holidays of the country where the company is registered. And nobody should end up with fewer days than colleagues on a Portuguese contract.

The solution went like this. We take the 22 Portuguese leave days as the base. On top we add 10 days that each person places on the public holidays of the country they live in: Ukrainian, Polish, whichever. If they do not want to tie those days to holidays, they are simply 10 more days of leave. 32 days a year in total.

One constraint: no more than 15 consecutive days, so that a project never loses a person for a whole month.

Later, when Andrei was modeling Teamtopia, this rule became its own entity: a location called Remote, with no country and no public holidays, compensated with more days. But in 2022 and 2023 it was a paragraph in a document and a column in Excel.

When a spreadsheet stops working for leave tracking

The spreadsheet held the rule for exactly as long as little changed in the company. We tracked everything in it: where a person is from, where they are now, their time zone, their contract type, how many days they had used, how many were left.

Every change of location meant a manual update. Every leave request meant someone opening the spreadsheet, subtracting days, checking against other requests. But the expensive part was something else: after every change to the rules or the team, someone had to understand the spreadsheet all over again, rewrite the formulas and pull out the numbers that mattered right now. That took between 30 minutes and 2 hours, and the people spending them were a manager and me.

The real problem was not the time spent on arithmetic. The spreadsheet could not answer the question every request was actually asking: can we let this specific person go on these specific dates without hurting the project?

Picture three interface designers working on one client product, two of whom request the same two weeks. In a spreadsheet that is two filled cells. To see the conflict you need to know who is on which project and check by hand. We found out about overlaps after someone had already planned a trip, and had to go and say "sorry, those dates won't work".

The same effect from the other direction: before signing a new contract or assembling a team for a project, we had to walk through the spreadsheet and make sure none of the people we needed would vanish for three weeks in the next two months. Another manual check, another chance to miss something.

Why we did not buy an existing leave management system

We tested BambooHR and two other tools in the same category: Vacation Tracker, WhosOff, LeaveBoard, Calamari. None of them fit, and the reason was neither price nor interface.

All of them assumed a company has one country, one set of public holidays and one contract type. Our 32-day rule and three calendars inside one team did not fit that shape. We could have worked around the limits with manual adjustments, but that would have put us back in the spreadsheet in a different costume.

The second reason: none of the tools showed risk to the project. They knew how many days a person had left. They did not know who else on that person's team was away on the same dates.

Push had the same spreadsheet

We took the problem to Push, our engineering partners, with whom we had shipped more than one product. It turned out they were tracking leave in the same kind of spreadsheet, with the same overlaps and the same manual work, and had been thinking about building their own tool for a while.

Two small companies, one problem, one decision: build it together. Flatstudio took product logic and design, Push took engineering. We set priorities and made product decisions jointly, because both teams were the first users of what we were building.

The first version of Teamtopia went live in 2023 and has tracked leave and absences in both companies since. Teamtopia became our spreadsheet alternative for planning and tracking time off, and we still test every new feature on ourselves first. How we found the structure of the product, and why we abandoned the org chart in favor of a single day as the base unit, is Andrei's article. What I want to talk about here is what changed at Flatstudio once the spreadsheet was gone.

What changed in the company after moving off the spreadsheet

The most visible change is about that same question of risk. When a person picks leave dates, they immediately see how likely those dates are to be approved. If someone from their team or project is already away on those days, the indicator is yellow. If the maximum number of people from the team is already out, it is red, and it is better to look at other dates right away.

The system blocks nothing and approves nothing on its own. It shows the risk and leaves the decision to the manager, because only the manager knows whether there is work on those dates that requires this particular person. That line between what the software counts and what a human decides became one of the main decisions in the product.

For me as CEO, something else changed. I see the whole company at once: which teams would be short if someone went on leave, who is on sick leave, who took a day off, how that overlaps with client projects. Before, that meant opening the spreadsheet and assembling the picture in my head. Now it is one calendar.

A few things we use every day:

• Locations and teams with their own rules. Teamtopia calls a location an "office", but it can be anything: the Lisbon team on the Portuguese calendar, Remote on the 32-day rule, a branch in another country, a restaurant, a warehouse. For every team there is a maximum number of people who can be away at the same time.
• Calendars built for a specific question. You can assemble a calendar for one team, for every team on a given project, for the whole company or for one location, and share it with exactly the people who need it: a manager, a design director, a team lead.
• A calendar for the client. This is a feature we built because our own clients asked for it. The client gets access to the calendar of their project team and sees who is working on their product, who is on leave, which public holidays apply to the people in Ukraine and which to the people in Portugal, even birthdays. They understand not just that someone is away, but why. Transparency inside the team we considered mandatory from day one; transparency toward the client turned out to matter just as much.
• Sick leave, days off and leave types with no paperwork. Every location and team can have its own absence types. Request, approval and balance update happen without email threads or forms. That is why we talk about absence management rather than just leave: sick days and days off go through the same system.

What we have added in the last year and a half

The product has a life of its own, and some features came from the needs of companies that joined after us rather than from ours.

• Payroll calculation (March 2025): absences and overtime hours in a form ready for payroll.
• External approvers (September 2025): approvers who are not part of the team or location, for example a client or an outside manager.
• Holiday swap (September 2026): moving a company holiday to another date when the standard one does not suit the team.
• Integrations with Slack, Google Calendar and Microsoft Teams.
• Statistics and skill groups: who with which skills is available, plus burnout risk signals based on how often and how long people take leave.

As of September 2026, Teamtopia has scheduled more than 2,100 leaves, recorded more than 500 sick days and more than 1,600 overtime hours.

What comes next: a second version for more countries

The first version works well for companies like us: small, distributed, two or three countries inside. But we regularly hear from new customers that their legislation is built differently from Portuguese or Ukrainian law.

Every country has its own statutory rules: number of days, public holidays, limits on carrying leave over. So we are now building a second version where a manager picks a country for a location and the mandatory part of the rules loads automatically. What remains to configure by hand is only what the company decides for itself: extra days, per-team limits, internal holidays.

The model for the second version is already assembled and clickable as an interactive prototype in Figma Make. The prototype showed that this is enterprise-scale engineering, which is exactly why we know it now rather than six months after kickoff.

The first version keeps running in the meantime. It is open for sign-up: 3 months free, then $2 per user per month.

What I took from this as the founder of an agency

We have been building products for clients since 2014. Teamtopia was the first product where the client was us, and that changed the angle.

When you are the one opening the spreadsheet and spending two hours re-understanding your own formulas, you know very precisely what the product has to do. Not "manage leave" in the abstract, but answer one question: can this person be away on these dates. Everything else in Teamtopia grew out of that question.

One more thing. For a long time we assumed transparency about absences was needed inside the team. The client calendar showed it is needed outside just as much. A client who sees that a designer is off for a Ukrainian public holiday reacts differently from a client who simply did not get a reply to a message.

This is how we usually work on an MVP: start with the model, take it to a prototype, and only then estimate engineering. The only difference with Teamtopia is that this time the first users were us.