Turning Ad-Hoc Quotes Into a Pricing System

Generating a client-ready proposal in iankha Tools, from start to exported document.

Role: Product Designer · Self-Initiated
Owner: iankha
Timeline: 2 weeks
Team: Solo · Sales Team (feedback via comments)
Date: September 2026

The constraint

Every proposal started the same way: pull comparable costs from past jobs, reason out a margin that felt right for this client’s size and flight frequency, then open the template and replace each line by hand. Once it looked right, it went to the team for a sanity check before it reached the client — another round trip, another wait. None of it was hard. All of it was slow, and it started over from zero every time, because there was no shared reference for what a price should be.

The template was not the problem

The obvious fix is a better template. But the reason each proposal took hours was not formatting. It was that we decided the price from scratch every time — there was no pricing model, only instinct. Automating the document would only have made a slow decision faster to write down.

Pricing first

I structured the commercial model before designing anything, in a spreadsheet: price bands by operation range, client size, and flight frequency, with a defined set of levers a seller is allowed to pull. Founder discounts. Annual-pay discounts. Adjustments to specific line items. The judgment that used to live in someone’s head became a set of rules the team could agree on once.

Pricing spreadsheet with tiered rate bands by farm size, showing integration fees, license rates, annual discounts, and per-hectare flight pricing — figures blurred — The pricing model, structured in a spreadsheet before any interface existed — tiered bands by farm size, with discount levers layered on top. Figures blurred: client pricing data.

Ship it, then design it

With the model settled, I built the first version by prompting Claude Design. No design system, no Figma file, no components — just the model, described. It went live on Vercel, and we used it: real proposals, to real clients, exported and sent.

First version of the quoting tool: a single scrolling column with field size, flight frequency, flight type, and a client cost estimate — Version one, prompted into existence with no design system — a single scrolling column. It was live and sending real proposals within days.

That was the point. The open question was whether a pricing model could carry a proposal end to end, and the fastest way to answer it was to put a working tool in front of the people selling.

The input surface stayed deliberately small. Hectares. Flight frequency. Who flies, us or the client. Then the discount levers. That is all of it, because the model underneath is carrying the complexity.

Then backwards, to paper

Once it worked, I went back to the beginning. I sketched the interface I actually wanted and weighed two options for the sidebar. The real question was not navigation — it was whether this stayed a proposal generator or became the shell that later tools would sit in.

Notebook sketches: two alternative sidebar structures on the left page, and a form layout with product tabs and discount toggles on the right — Two sidebar options, weighed on paper. The tabs sketched here — Open Field Platform, Rose Ecosystem, Photogrammetry — did not exist yet.

Building first had earned something specific: I now knew which parts of the flow were load-bearing, so the sketches were about structure rather than guesses.

A design system, then a rebuild

I moved into Figma and drew the screens against a design system I am building alongside it, with Claude Code and the Figma MCP — semantic styles from the ground up rather than colour values chosen per screen. The layout changed: v1’s single scrolling column became a form on the left and a live estimate on the right, so the price moves while the user is adding inputs.

That system is why the rest scales. Nothing in the interface picks a value directly: every element binds to a semantic style named for its role — surface, border, text, interactive — across dark and light modes and three typographic scales. Components are mapped back to their Figma counterparts through Code Connect, so a developer opening a frame gets the component that builds it. I author the system in Figma, by hand and with Claude Code driving the Figma MCP, and I work with Claude Code to bring the components and variables into Storybook.

Two-panel interface design: scenario and discount controls on the left, live client estimate and annual summary on the right — The redesign: inputs on the left, the estimate updating on the right. The three product generators became tabs.

Then I built the product with Claude Code. Because it is an internal tool for our own team, I built it myself; on client-facing products I write the specifications and prototypes that engineers build from, not production code. I plan for this to become iankha Tools: an internal app that helps our small team move faster on commercial and operational matters.

The table that answers the next question

The generated PDF covers what a proposal has to cover: client name, issue and expiration dates, price per hectare, price per flight processing, one-time setup fee, and what the platform and service include.

Then one thing a quote usually leaves out, added deliberately. A table showing price per hectare across every flight frequency, not just the one selected. A quote tells a client what this costs. This table lets them ask what a different cadence would cost, and answer it themselves, without another call and another three hours.

Page from the generated proposal: a cadence comparison table listing price per hectare at quarterly, bimonthly, monthly, fortnightly and weekly capture frequencies — The cadence table, in the generated document. Every frequency is priced, not just the one selected — and the recommended one is marked. Client and figures are illustrative.

What changed

A proposal now takes between thirty seconds and a minute, depending on how sure the seller is about what they want and the information they have. The hours did not disappear, they moved: we spend that time on the pitch and the client relationship instead of the paperwork.

The structure held well enough to repeat. Photogrammetry has its own generator now, the Rose Ecosystem one is in progress, and the shell they sit in is turning into a tools app for the rest of the team.

No one asked for this. The constraint on revenue was proposal production, not demand, and that was worth the extra time to remove permanently.