Designing 94 Pages Before Writing a Line of Code

Most software projects fail not in the code but in the gap between what a client imagines and what actually gets built. The cheapest place to close that gap is a design file. The most expensive place is production.

So when a UK virtual-assistant agency asked me to build their internal operations platform, I didn't start with create-next-app. I started with a blank Figma canvas — and I didn't stop until I had 94 pages.

What "design before build" actually means

It's not wireframes-then-guesswork. It means every screen a user could reach exists as a high-fidelity design before anyone estimates the build. For this platform that meant:

• 10 functional modules — auth, staff, clients, onboarding, time tracking, performance, finance & payroll, notifications, teams & projects, and platform configuration.
• A 7-role permission system, with support for users holding up to four roles at once.
• 8 shell variants — four roles across expanded and collapsed navigation.
• 10 transactional email templates, designed as carefully as the app itself.
• A full design system: colour tokens, a Poppins + DM Sans type scale, a component library, and spacing rules.

Why this saves money the client doesn't have to spend

Every decision made in Figma is a decision not re-made in React. A permission matrix is a one-hour conversation over a design; it's a two-week refactor once it's wired into the backend.

By designing the client → project → VA assignment model, the 5-metric performance scoring, and the 7-phase onboarding checklist up front, the build phase becomes translation, not invention.

The honest caveat

Designing everything first works when the domain is knowable — internal tools, where the workflows already exist on paper or in someone's head. It's the right default far more often than the industry admits, but it isn't dogma.

The point isn't the 94 pages. It's that when we start building, nobody is guessing.