Leafsight~5 min read

Could a proposal be done before the next job?

We rebuilt a proposal tool for the driveway, not the desk, around a ninety-second completion target.

Role: Product strategy and design
Timeline: 6 weeks
Team: 1 PM, 1 engineer, me
Impact: $300k ARR
Platform: iOS, Android

The Leafsight proposal workflow displayed on a laptop at a job site.

Impact

Proposal acceptance

up from 8%

Traffic on mobile after launch

$0k

ARR run-rate

Product figures come from Mixpanel. The 70% is mobile’s share of traffic after the mobile launch. The $300k is run-rate rather than cumulative, and held for the rest of my time on the product. Still missing: dates, so “held” has a length, and the denominator behind acceptance. The target row was written against a user base moving from 20 to 75, and a percentage on a base that size should say so rather than imply a larger one.

The short version

Owner-operators write 4-8 estimates a day from job sites with poor connectivity. The web app they were asked to use was built for a desk. Estimates were abandoned, 18% went out with wrong line items, and acceptance sat at 8%.

We had six weeks, one PM, and one engineer. We rebuilt the flow around one target: a complete, accurate proposal, sent from anywhere in under ninety seconds. Everything that did not fit was cut or moved. Acceptance reached 38%, 70% of sessions moved to mobile, and the product reached a $300k ARR run-rate.

What I owned

I owned

Product strategy and design across the six-week build
Field research: watching estimates get written on job sites rather than in a room
The ninety-second target, and the success measures set before any design
The navigation decision, and the field testing that settled it

Shared with the PM

Scope against six weeks and one engineer
What got deprioritized, and what went to the roadmap

Problem

Proposals get written in driveways, at the end of the day, on phones. Why was the app built for a desk?

Owner-operators and sales reps complete 4–8 estimates a day, usually on site, usually on a phone, often with a connection that drops mid-form. The existing web app was slow and dense, and it assumed a stable connection and an unhurried user. It got neither.

The result was abandonment rather than complaint. Nobody filed a ticket saying the tool was too slow; they just stopped opening it and went back to writing estimates on paper.

Before

Proposal acceptance

Proposals with incorrect line items

0 mins

Time to create a proposal

A field worker’s day mapped from 7am through the evening, showing when proposals get written. — A day on site, 7am to 7pm. Proposals get written at the end of it, by someone already out of decisions. This is what set the ninety-second target.

A three-part diagram: on the left, portraits of five clients under the heading Meet clients; in the centre, a highlighted column headed Under 90 seconds containing three stacked steps — Estimate, Create proposal, and Share/Send; on the right, a photograph of a proposal being signed on a tablet under the heading Work. — Estimate, create, send. Ninety seconds is the budget for all three together — which is why nothing in the shipped flow asks a question that can be answered later.

Ninety seconds sets the scope

What fits in ninety seconds?

We rebuilt around a fixed ninety-second completion-time budget instead of speeding up the existing web flow or adding a mobile view to it. Users were making their fourth to eighth estimate of the day outside on a phone, so decision capacity, not screen size, was scarce. The target removed photos, notes, tags, and AI features that owner-operators eventually want on a proposal; if the wrong parts were optional, the bet would lose badly. We shipped the short flow, watched what people stopped to look for, and would add back only what they reached for. Task completion rose from 45% to above 80%, and no cut feature has been requested often enough to return.

Let repeat users skip ahead

Why walk someone through a task they already know?

We chose hub and spoke, with shortcuts to recently used services, over a guided stepper or a single long form. Field workers already knew the task and were repeating it for the sixth time that day, usually with the same services. Unlike a stepper, hub and spoke does not guarantee that nothing is skipped, a material tradeoff when 18% of proposals already had wrong line items; the hub shows completion state for every section so missing information stays visible without being enforced. Field workers tested all three, error rates fell rather than rose, and they rejected the stepper outright.

Stepper prototype for proposal creation. — Rejected: stepper. Predictable, and slow on site.

Single-form prototype for proposal creation. — Rejected: single form. Fast to build, heavy to scan.

Hub-and-spoke prototype for proposal creation. — Shipped: hub and spoke.

What we shipped

We shipped a mobile-first proposal flow for clients, job-site location, proposal, and item details, with shortcuts to recently used services and completion state on the hub. Notes, photos, tags, and AI features were deprioritized.

We set success before designing: completion under ninety seconds, task completion above 80% from 45%, and return usage within 24 hours above 60%.

The proposal flow before it was shortened, with many steps. — Before: dense, multi-step, desk-shaped.

The shortened proposal flow after redesign. — After: the same job, reshaped around ninety seconds.

The flow, end to end

A Create sheet sliding up over the day’s calendar, offering four options: Lead, Proposal, Active Job, and Client, each with a one-line description. — One entry point over the day’s schedule. Four things a rep can start, named for what they are.

An Untitled Proposal screen with a Save action and a list of fields to fill: Add Client, Add Operation, Add Items, Add Notes, Add Photos, and Add Tags. — The proposal, empty. Every row is optional except the client and the work — the rest can wait for the truck.

A Proposal screen with the client Charles Bikowski, a Seattle address, and the Treecare operation filled in, above a green Add Item button and four shortcut chips: Tree Removal, Structural Pruning, Stump Grinding, and Crown Thinning. — The shortcuts are the ninety seconds. Four services cover most of what this crew sells, so the common case is a tap rather than a search.

A Select Item picker with a search field and a list of services: Tree Removal, Structural Pruning, Crown Thinning, Crown Reduction, Credit Card Fee, Root Collar Excavation, and Oak Wilt Treatment. — The full catalogue, for the case the shortcuts miss. Searchable, and it is the same list the office priced.

The proposal with a Tree Removal line item at $1,500 and its scope note, followed by a subtotal of $1,500, Seattle tax at 10.2% of $165, a total of $1,654, and links to add a discount or require a deposit. — Tax by jurisdiction, computed rather than remembered. 18% of proposals had incorrect line items before; the available record does not say which items were wrong.

An Untitled Job screen with the same field pattern as the proposal — Add Client, Add Operation, Add Items — plus Schedule Job, Add Notes, Add Photos, Add Tags, and Add To-Do List. — An accepted proposal becomes a job on the same shape of screen. Learning the proposal is learning the job.

The proposal form with every action as a row in one list: Add Client, Add Operation, Add Items, Add Notes, Add Photos, Add Tags. — Before: six equal rows. Notes, photos, and tags sit between the rep and the only two fields a proposal actually needs.

The same proposal form with the client and address merged into a single row above the operation, a full-width Add Item button, and Photos, Notes, and Tags moved to a bar pinned along the bottom of the screen. — After: client and address collapse into one row, Add Item takes the width, and the three secondary actions move to a bar. Demoted, not cut.

The clean story leaves out the hard cases

The uncomfortable truth is that every field quote I collected points the same way. I have no recorded case of someone who preferred the stepper or wanted photos badly enough to stop using the tool. That absence is not evidence that those people were not there.

The evidence is also split. The portfolio deck carries 20% user engagement, eight-minute proposal creation, and time-to-value from fourteen minutes to ninety seconds; Mixpanel carries acceptance, line-item errors, and mobile traffic share. Both sets are real, but they were never reconciled into one before-and-after row.

What actually happened is that the ninety-second target made notes and photos deliberately expensive. That worked for a single operator writing 4–8 estimates a day; a crew on larger jobs needs them. The useful judgment is unresolved: a fast default is valuable only until the work becomes complex enough that the exception path is the real job.