Building a design org from one to seven

Idaratech builds a SaaS HRMS and ERP suite for enterprises in Saudi Arabia: HR core, attendance and payroll, CRM, project management, supply chain, and the country-specific integrations that make or break adoption there. Arabic-first, RTL throughout, web and mobile. When I joined in late 2024 as the first designer, there was no design infrastructure: no system, no process, no shared language between design and engineering, and an ambitious roadmap that assumed all of it existed.

The instinct when you're drowning is to hire. I deliberately didn't — not first. A team inherits whatever systems exist on the day they join, so as the founding designer I spent my early months building the foundational design infrastructure and a design strategy the ERP suite could actually scale on: how modules share patterns, how decisions get documented, and how design work reaches engineering.

That sequencing paid for itself later. Every designer who joined onboarded into a working system rather than a pile of conventions in one person's head.

I was promoted to manager to build and oversee the entire design function. The team grew from me alone to seven designers, including two product design leads. The structure maps to the product, not to a generic org chart: two product groups split by domain — ERP core, HR and fintech on one side; supply chain, project management and CRM on the other — each with an acting lead carrying the quality bar so it doesn't bottleneck on me, covering web plus three mobile apps.

The operating rhythm is deliberately light: two to three design reviews a week, a design weekly for the team, and regular 1:1s. Process exists to serve shipping; when a ritual stops earning its time, it goes.

The proof of an org design is what it ships. While the team was being built, it delivered three complex modules from 0→1 (CRM, Project Management, and Supply Chain) and a brand-new Mobile App v2, all inheriting the unified design language. My own role shifted from making to multiplying: setting direction, reviewing for coherence across modules, and keeping design strategy aligned with where the business needed the suite to go.

A design team that only pushes pixels caps its own influence. I run the team on a pull-based capability backlog: idle time between product deliverables converts into work that serves the company's growth target. Product always comes first; the backlog only runs in the quiet. Tasks are sized small, medium, or large, any available designer pulls the top one that fits their time, and when product work returns they hand off in two lines and go back, no guilt attached.

That mechanism is expanding the team along three axes beyond core product: data (a full measurement infrastructure so every design change gets measured before and after), research (a usability practice built from scratch on a zero budget, with an insights repository), and marketing (a unified sales and brand asset system). Every designer also carries a quarterly growth goal and teaches what they learned in a monthly skill-share.

Scaling design isn't a hiring problem, it's a systems problem with a hiring component. The order matters: infrastructure, then people, then leverage. Build it the other way around and every new designer adds coordination cost instead of capacity.