140 screens before the first line of code

The common advice for new products is to design a little, build a little, and find the rest along the way. Ship the smallest thing, then learn. I believe in shipping small. But for Pawow I did something that looks like the opposite: I designed the entire product before a single line of it was built.

That came to more than 140 screens. The owner app, the provider app, the provider web, the owner web and the admin. Bookings, payments, messages, pet records, the community, the lost pet alerts. Every screen, and most of the states in between.

This is why.

The product is the connections, not the screens

Pawow connects two sides. Pet businesses, groomers, trainers, dog walkers, sitters and boarding, get software to run their day. Pet owners get one place for their pets and their bookings. A booking made by an owner on a phone has to arrive in a groomer’s calendar on a laptop, turn into a payment, a reminder, a visit report and a record in the pet’s profile.

If you design that one screen at a time, every screen looks fine on its own. The problems live in the gaps between them. What the provider sees when an owner books two pets but one is not accepted. What happens to the price. What the owner sees while the request is waiting. Those moments only show up when the whole flow exists in one place.

Designing everything first is not about polish. It is about finding the gaps while they cost a drawing, not a rewrite.

States are where products fail

A typical design file shows the happy path: the full calendar, the successful payment, the nicely filled profile. Real products spend much of their time somewhere else.

So the Pawow screens include the uncomfortable ones on purpose. The payment that failed. The hold that expired and the time that was taken by someone else. The request that was accepted for one pet but not the other. The pet that passed away. The account being suspended. The chargeback.

Each of those is a moment where a customer is confused, worried or upset. They deserve as much design as the home screen. Probably more.

One system, several apps

Designing everything at once also forced the design system to be real. Pawow has a foundation of principles, colour, layout, controls, cards, feedback, navigation and icons, and every one of the 140 screens is built from it.

When you only design ten screens, a design system is a theory. When you design 140, it is either consistent or it visibly falls apart. The scale exposed every component that was not general enough, every colour used in two different meanings, every spacing rule that did not survive a dense admin table. Fixing those at the design stage is cheap. Fixing them after five engineers have each built their own version is not.

The decision behind the structure helped too: web first, with the phone apps as clients of the same product. One set of rules, several screens.

It makes building faster, not slower

The obvious objection is time. Designing the whole product first sounds like months before anything ships.

In practice it made the build faster. Every question a developer would normally ask in week three already has an answer on a screen. The scope is visible, so it can be cut deliberately instead of by accident. And the product can be shipped in parts, because the parts were designed to fit together from the start.

It also changes the conversation with everyone involved. Investors, partners and future customers can walk through the complete product before it exists. Feedback arrives when changing direction is still cheap.

This is not the same as a big upfront plan

I am not arguing for a year of specifications nobody reads. The screens are not a document, they are the product drawn out, quickly and honestly, so it can be judged and fixed before it is built.

And they are not frozen. Once real people use the product, things will change. But they will change from a complete, consistent starting point instead of from a pile of decisions made under pressure.

When I would do it again

Not every product needs 140 screens before code. A simple tool with one user and one job can be designed and built side by side.

But when a product connects several kinds of users, handles money, and lives on more than one device, the connections are the product. In that case I would rather see all of it on one canvas first, and find the hard parts while they are still drawings.