Superframe Rates Calculator

Placeholder — final hero: phone mockup of the calculator with a quote in progress.

Superframe's pricing structure is genuinely complex: three service types (pick up / delivery, delivery plus installation, installation only), crew sizes of one to three people, three client categories with different rates, a distinction between work we framed and work we didn't, and a first-hour plus additional-hourly rate structure. All of it lived on a handwritten whiteboard in the shop.

That worked fine until someone needed a number while standing in a client's lobby. Field quoting meant calling back to the shop, scrolling through a photo of the board, or estimating and hoping. Errors were easy, and every quote interrupted someone else's work.

I'm on that installation team, so I wasn't designing for a hypothetical user. I was the user.

Placeholder — photo of the original whiteboard pricing chart.

• Phones, on-site, often one-handed. Desktop was irrelevant. Everything had to work on a phone screen, standing in a freight elevator.
• No backend, no budget. A single self-contained HTML file the team could open instantly. No accounts, no loading states, no IT dependency.
• The pricing logic is the product. If the math is ever wrong, trust is gone and the whiteboard wins. Accuracy beat every other consideration.

1. Decode the source of truth

I started by translating the whiteboard into structured data: confirming every rate, what the slash notation meant (first hour / additional hourly), and where the exceptions hid. The most important one: Bank clients match Corporate rates everywhere except pick up / delivery on work we framed. Edge cases like that are exactly what a calculator exists to catch.

Placeholder — side-by-side of the whiteboard photo and the structured rate table.

2. Explore structure before pixels

Before committing to a layout, I generated and evaluated ten structural directions, from a dense reference table to a step-by-step wizard. I chose a mobile-first accordion-to-calculator model: fast for people who know the system, self-explanatory for people who don't.

This is where my AI workflow earned its place. Working with Claude, I could pitch a structural option, see it as working code in minutes, and reject it cheaply. Most of the ten directions died fast, which is the point. The cost of exploring went to nearly zero, so the final structure was chosen, not defaulted into.

Placeholder — 3–4 of the rejected structural directions as small thumbnails.

3. Build the calculator

The final tool is a two-tab app: Calc for building quotes, Pricing as a clean reference of the full rate structure (the whiteboard, but legible).

1. Pick service
2. →
3. Crew & time
4. →
5. Add extras
6. →
7. Add job
8. →
9. Quote grows

Core interactions:

• Segmented controls for service type, crew size, and framing status. One thumb, no typing.
• Time on site in 15-minute increments, 8am to 8pm, mapped to the first-hour / additional-hour rate logic.
• Extras as toggles: disposal (bags, crate, or other with custom input), wrapping with a piece counter, and travel with an hourly stepper.
• A persistent bottom bar showing two numbers: the live breakdown of the job being configured, and the quote subtotal that only updates when a job is added. Separating "what I'm pricing now" from "what I've committed to the quote" removed the most common confusion in early testing.
• Multi-job quotes. Add a job, configure the next, see the total grow. Real visits are rarely one job.

Placeholder — annotated screenshot of the Calc tab with the bottom bar called out.

4. Design the system

Client type does real work in the interface. Residential, Corporate, and Bank each theme the header through CSS custom properties (black, blue, and money green), so a glance at the screen confirms which rate book you're in. Client types and crew sizes use Material Symbols (home, corporate_fare, account_balance; person, group, groups) so states read without reading.

Every colour combination passed a WCAG AA contrast audit, the same standard I hold my studio design system to. An internal tool used in a sunlit loading dock has stricter legibility needs than most marketing sites.

Placeholder — the three client-type themes side by side.

5. Debug like it matters

Working software means real bugs. Three worth remembering:

• A circular call between the state-change handler and the calculation function.
• A missing variable declaration that silently prevented jobs from being added (the worst kind of bug: no error, no job).
• A "Clear All Jobs" button that destroyed itself because it lived inside the dynamically rendered HTML it was clearing.

Each fix was targeted, not a rewrite. Knowing when to patch and when to rebuild is a design judgment as much as an engineering one.

In daily use by the Superframe installation team since spring 2026.

Next step: packaging the tool as an installable app via Capacitor or a PWA, so it lives on the home screen next to the phone and the tape measure.

Placeholder — phone on a work surface in the shop, tool open.

• Being the user is an unfair advantage. I didn't need a persona; I needed to remember last Tuesday.
• AI changes what exploration costs. Ten working structural prototypes used to be a sprint. Now it's an afternoon, and the quality of the final decision shows it.
• Internal tools deserve real design. Accessibility audits, theming systems, and interaction polish aren't only for customer-facing products. The people doing the work are users too.