Swivl, the deep dive: estimates and invoices

Chapter 1

What an estimate has to do

A plumber or electrician lists the services for a job, sends the estimate, and waits. Once the customer approves, the work starts. When it's done, the same items become an invoice.

The loop every screen in this story serves.

Everything in this flow serves that loop. Two things kept getting in the way: how many steps it took to list the work, and the fact that nobody could see what the customer would receive until the very end.

Estimates and invoices are one module with two names. They share the same layout, and only small things differ: some of the wording, the deposit an estimate asks for, and the way an invoice subtracts any deposit already paid to show what's left. So everything below applies to both.

Chapter 2 · Feb 2025

v1 · What I inherited

When I joined, one founding designer had built the product. Credit where it's due: everything shipped and nothing was blocked. But there was no design system and no design review, so every page looked a little different.

v1 on the web. Invoices and Estimates sat as tabs inside Work Order Management, though the side nav already had its own section for them.

Swivl v1: estimates as a tab inside Work Order Management — v1 on the web. Invoices and Estimates sat as tabs inside Work Order Management, though the side nav already had its own section for them.

The v1 estimate form. Every field, cost breakdown and line item on one long page.

Swivl v1 estimate form: one long page of fields, cost cards and line-item rows — The v1 estimate form. Every field, cost breakdown and line item on one long page.

The preview came last, after the form was saved.

Swivl v1 estimate preview with media and signature — The preview came last, after the form was saved.

v1 on mobile: the list, adding one product per form, and the review at the end.

v1 mobile estimates list — v1 on mobile: the list, adding one product per form, and the review at the end.

Hierarchy. Estimates and invoices were buried under tabs, duplicating the navigation.
Consistency. No shared components, so each page solved the same problem its own way.

Chapter 3 · Sep 2025

v2 · A design system first

Two teams worked on v2. My part was mostly orchestration: setting up the team and the design system they built on.

Before redesigning any one flow, we needed a system. In every role before this I had built a custom design system from scratch. Here that was too slow, so we took shadcn and adapted it to our style: core components first, then custom ones as each page needed them.

The brand was purple at the time. We tried a lot of variations, but nobody wanted to change it, so the revamp kept purple. The whole v2 revamp took a couple of weeks.

v2: estimates get their own page, with status counts and explanations on hover.

Swivl v2 estimates list with status cards and tooltips — v2: estimates get their own page, with status counts and explanations on hover.

Swivl v2 estimate form as four collapsible steps — The v2 form, split into four steps.

Swivl v2 estimate review with a page preview — Preview, still at the end.

The components stabilised. Pages finally looked like one product. But the flow had new problems:

Too many clicks. Creating an estimate meant moving through several steps.
Preview last. You still couldn't see the customer's copy while you filled it in.
Missing details. The detail page lost some information the old one had shown.

Chapter 4 · Mar 2026

v3 · Form left, PDF right

Other designers on the team took v3 in a different direction. Since nobody knew what the estimate looked like before sending it, we put the live PDF on the right and the form on the left. We also added clearer statuses, so it's easier to tell where each estimate stands.

v3: pick the customer and job on the left, watch the estimate fill in on the right.

Swivl v3 create estimate: customer and job details on the left, live preview on the right — v3: pick the customer and job on the left, watch the estimate fill in on the right.

Products and services, with the cost reference and processing fee beside them.

Swivl v3 products and services step with cost slider and processing fee — Products and services, with the cost reference and processing fee beside them.

New statuses such as Awaiting Response and Change Request.

Swivl v3 estimates list with new statuses — New statuses such as Awaiting Response and Change Request.

We tested it. People liked it, engagement went up, and it was simpler than before. But the split had a cost:

Space. With half the screen gone to the PDF, even small things took a lot of room, worst on smaller screens.
Few items visible. Add a few products and the form ran out of space.

The v3 detail page. The customer's copy isn't on it; the preview sat under the ⋮ menu.

Swivl v3 estimate detail page: line items and costs, with no preview of the estimate — The v3 detail page. The customer's copy isn't on it; the preview sat under the ⋮ menu.

And sending it was harder than building it:

Hidden preview. On the detail page the preview sat under the ⋮ menu, so people didn't know what they were sending.
Blind send. Send didn't show a preview either.
A blocking customer step. You had to pick a customer before moving on. Once the page scrolled, people missed that field, and nothing drew their eye back to it, so they couldn't tell why they were stuck.
Too many hops. Create and send meant save, open the detail page, then send it or collect payment.

Chapter 5 · Jun 2026 · Shipped

v4 · Only what you need, when you need it

I wasn't satisfied leaving those pain points open, so in June 2026 I took v4 on myself and owned it end to end, starting with a UX audit of the invoice flow.

I chose not to revamp it again. The flow had been revamped twice in six months, people had only just learned v3, and we were already hearing that things changed too often. So I kept the layout they knew and made it progressive: instead of one long form that's always open, each section shrinks once it's done.

v4: one form, top to bottom, with the live preview beside it.

Swivl v4 create estimate: one scrolling form with a live preview — v4: one form, top to bottom, with the live preview beside it.

Adding items. Before, you pressed plus and a new product card appeared, every time. I asked why the card needs to appear at all. Most of the time the product or service is already in the price book, or you type it on the spot. So one search box now finds an existing item or adds a new one, and fills in the line.

A filled line doesn't open in edit mode, because most people never edit what's added. That saved time and made the screen cleaner.

One form. A continuous scroll replaces the stepper.
Job first. Linking a job up front pulls in the customer, address and media.
Tiers. Good, Better and Best options are picked at the moment you add a price-book item.
Expense Manager. The old cost calculator now shows markup and margin, and controls the processing fee.
Preview your way. A side sheet by default, expanding to a full-screen live PDF.
Send from where you build. The main button on the create page sends the estimate or collects payment, with the estimate in view. On site, the customer agrees and pays there and then. Off site, it goes out straight away.

The v4 detail page opens on the estimate itself, so you always see what the customer sees.

Swivl v4 estimate detail page with the estimate PDF embedded, beside details, payment and cost cards — The v4 detail page opens on the estimate itself, so you always see what the customer sees.

v4 reuses the existing tokens and components, and all of it has shipped.

Chapter 6 · Planned

Next · AI that writes the estimate

What I'm working on now: combining the flow with an AI estimator. Answer a few questions about the job and it drafts the estimate for you. None of this has shipped yet.

The planned layouts. Design in progress.

The rule from v4 carries over: whichever way you build it, you see what the customer gets before it goes out.

That's the long version. Back to the 2-minute read.