DodoIS HR Platform: 30k people, 1000 restaurants, throughput as the design

HR for a network with high turnover is not a feature problem. It is a throughput problem. 30,000 people, 1,000 restaurants, a constant flow of hiring, onboarding, offboarding. The design question is not "what does the system do" but "what does the system let go of".

I came into the DodoIS HR product line as an engineering lead and grew into the product owner role. The platform we built and operated at peak carried 30,000+ employees, served 1,000+ restaurants, and pushed roughly 100,000 personalised messages per week. None of those numbers were fixed by a feature decision. They were fixed by a series of decisions about throughput.

Throughput first, features second

When you are designing for high turnover, the unit of analysis is not "the user." It is "the user, refreshed every six months, half of whom did not work anywhere with software more sophisticated than a messaging app." A feature you ship today will be used by people you have not hired yet, and trained at a tempo you cannot control.

That changes priorities in three concrete ways.

First, the cost of every onboarding step compounds. We measured onboarding completion as a funnel and pruned aggressively. The first version (inherited from the previous owner) had completion at 62% by day three after hire. After two passes of cuts and one redesign of the first screen, day-three completion was at 89%. A 27-point lift on a 1,000+/quarter cohort is meaningful operational time.

Second, every "let me ask my manager" moment is a tax on the manager, not the employee. A platform that requires a manager in the loop for routine actions does not scale linearly with employees, it scales with manager bandwidth, which is fixed. We kept removing manager-blocking steps even when it added system complexity.

Third, anything that has to be customised per-restaurant is going to be customised by the restaurant manager, not by us. So the question is not whether to expose configuration; it is how to expose it without the manager needing to talk to engineering.

Personalised communications: the admin matters more than the engine

The piece I am most proud of from the DodoIS years is the personalised communications system. 30,000+ users, 100,000 messages a week, parameterised by branch, region, role, and tenure. The DodoIS backend stack is C#/.NET, and the messaging engine sat on top of that with a queue, a templating layer, and channel adapters.

The interesting decision is not the engine. The engine is mostly a queue plus a templating language plus delivery. Anyone with a mid-level backend team can build that.

The harder decision is the admin layer. We built it as a self-service editor that branch and regional managers used directly, without an engineer in the loop. The templating language was a constrained Liquid sandbox: enough to interpolate name, branch, role, tenure, and a few business attributes; not enough to call out, do arithmetic on PII, or write loops that touch external state. Engineers reviewed only the segmentation primitives, not individual templates.

I remember Yulia, a regional ops manager in Moscow, sending the first non-engineer-authored campaign in week six of the rollout. She targeted line cooks who had started in the last 30 days at the Belorusskaya cluster, with a message about the new prep checklist. Three minutes from idea to send. Before, that had been a Jira ticket with a 5-day turnaround. We watched her do it on Zoom in silence and then quietly stopped pushing every comms feature through engineering. That is the moment the system actually shipped.

Where no-code failed

Two stories where no-code did not pay, both in year one.

First, we tried to no-code the staff probation review process. It turned out the underlying process had no clear owner across the regions: HR thought ops owned it, ops thought HR owned it. We built a flow, deployed it, and three regions ran it differently within two weeks because nobody could decide whose flow it was. Six weeks of work, retired in week nine. The process needed to be re-engineered first, not configured first.

Second, we tried to no-code the equipment-handover step at offboarding. The configuration surface we exposed was rich enough to be misconfigured. A regional manager set up a flow that quietly skipped the laptop return checklist for one branch type. We caught it in a quarterly audit, three months later, after about 40 laptops had walked.

The lesson stuck: no-code is a multiplier on whatever is underneath. If the underneath is good, you 5x. If the underneath is broken or has weak ownership, you 5x faster mistakes. We rolled back from "configurable workflow" to "engineer-reviewed workflow with a configuration surface" for anything touching equipment, money, or compliance.

Engagement as a separate product, not a tab

Pulse surveys, satisfaction index, regional health analytics, merch store, contests. We could have built these as tabs in one HR app. We chose to split them into independent surfaces with shared identity, for the same reason we split mobile in LOOV: the mental state of someone opening a pulse survey is different from someone browsing the merch store.

Splitting let us run experiments per surface. The merch store iterated retention loops independent of the survey tool. The survey tool iterated cadence and length without affecting comms. Each had a small dedicated team and a clear KPI.

What survives a transition

I left the role after about three years. The platform stayed and grew. The engineer who replaced me as product owner was someone I had been working with from year one, and her first decision was to deprecate two features I had championed.

That was the right call. The features in question were leftovers from year one and the throughput data showed they were not earning their place. I would not have killed them; she did. The fact that she could, and that the design centre held without me defending it, is the actual measure of the platform.