Why a working spreadsheet still needs a brief
Pricing spreadsheets work because the person using them knows where they break. They know that cell F12 must never go below a certain value, that the discount tab is out of date, and that oversized orders are "done by hand". None of that knowledge is in the formulas. A configurator app has to make every one of those decisions explicitly, and if nobody writes them down, the developer will guess.
The brief below is the document that removes the guessing. It also makes quoting easier: a configurator app with ten documented rules is far easier to scope than one described as "like our spreadsheet".
The kind of configurator this brief describes is a bounded pricing workflow: a user picks options and enters sizes, the app applies your documented rules, shows a price breakdown, and saves or sends the quote, while named people edit rates in an admin panel. It is not 3D product visualisation, and it is not an enterprise CPQ system with ERP approval chains, contract pricing per account or multi-currency price books. If you need those, an established CPQ product is the better starting point.
Write down who owns each formula
List every rate and rule, and next to each one name the person who decides it and how often it changes. This tells the developer what belongs in an admin panel (rates that change monthly) and what can be fixed in code (a rule that has not changed in years).
| Rule | Current value | Owner | Changes | Where it lives in the app |
|---|---|---|---|---|
| Oak rate | 120 per square metre | Purchasing | Quarterly | Admin panel |
| Birch rate | 80 per square metre | Purchasing | Quarterly | Admin panel |
| Hardware per shelf | 15 | Operations | Yearly | Admin panel |
| Shelf depth | 300 mm, fixed | Product | Rarely | Code |
| Width step | Round up to next 100 mm | Workshop | Rarely | Code |
| Volume discount | 5% from 10 shelves | Sales director | Campaigns | Admin panel |
| Minimum order | 150 before tax | Sales director | Yearly | Admin panel |
| Tax | 20% on the net total | Finance | When law changes | Admin panel |
Decide how and when numbers are rounded
Rounding is where spreadsheets and apps disagree most often. A spreadsheet may display two decimals while storing ten, and different cells may round at different steps. Agree three things in writing: which inputs are rounded (here, widths round up to the next 100 mm because that is how the workshop cuts), at which step money is rounded, and which rounding method applies.
For the example, the rule is: calculate each shelf price from the rounded width, sum the order, apply the discount, apply the minimum, then calculate tax on the net total and round tax half up to two decimals. Write it as an ordered list like that. If your finance team rounds differently, their rule wins, but it has to be one rule.
Define valid inputs and what invalid ones should do
For every input, state the allowed range and the message a user sees outside it. A spreadsheet will happily calculate a shelf 5 cm wide or minus three shelves. An app should stop the user with a clear reason, and for sales tools it should say what to do instead.
- Width: 400 to 2400 mm. Below the range: "Minimum width is 400 mm." Above: "Maximum width is 2400 mm. Split this into two shelves."
- Quantity: whole numbers from 1. Zero or blank disables the price until fixed.
- Material: Oak or Birch only. A discontinued material stays on old quotes but cannot be picked for new ones.
- Decimals in millimetre fields: rounded up with the width step, so 1150.5 is treated as 1200.
Edge cases as a test-case table
The test-case table is the most useful page in the brief. Each row is an input someone could really enter, the result your business considers correct, and the rule the row checks. The developer builds against it; you accept the app when every row matches. Include ordinary orders, every boundary, and every rejection.
| Case | Input | Expected result | Rule checked |
|---|---|---|---|
| 1. Small order | Birch, 800 mm, 3 shelves | Items 102.60, raised to minimum 150.00, tax 30.00, total 180.00 | Minimum order |
| 2. Width rounding | Oak, 1150 mm, 4 shelves | Priced at 1200 mm: 58.20 each, net 232.80, tax 46.56, total 279.36 | Width step |
| 3. Upper boundary | Oak, 2400 mm, 2 shelves | 101.40 each, net 202.80, tax 40.56, total 243.36 | Maximum width accepted |
| 4. Below discount | Birch, 700 mm, 9 shelves | 31.80 each, net 286.20, tax 57.24, total 343.44 | No discount under 10 |
| 5. Discount boundary | Birch, 700 mm, 10 shelves | Items 318.00, discount 15.90, net 302.10, tax 60.42, total 362.52 | Discount from 10 |
| 6. Tax rounding | Oak, 1200 mm, 11 shelves | Items 640.20, discount 32.01, net 608.19, tax 121.64 (from 121.638), total 729.83 | Round tax half up at the end |
| 7. Too wide | Oak, 2450 mm, 1 shelf | No price. Message: "Maximum width is 2400 mm. Split this into two shelves." | Validation, upper |
| 8. Too narrow | Birch, 350 mm, 2 shelves | No price. Message: "Minimum width is 400 mm." | Validation, lower |
| 9. Zero quantity | Oak, 1000 mm, 0 shelves | Price hidden, quantity field highlighted | Validation, quantity |
Handing the brief to a developer
With the rule register, the rounding order, the validation list and the test cases, a developer can scope the configurator accurately and you can check the result without reading code. Add who uses the tool and what happens to a finished quote, which the calculator app cost guide covers, and the spreadsheet-to-app guide if your spreadsheet also tracks orders or stock.
Send the brief through the quote form. You receive a written scope that lists these assumptions, a timeline with checkpoints and a quote. After full payment the project files and original assets are yours, and the rates in the admin panel stay under your team's control.
Frequently asked questions
Can you turn our pricing spreadsheet into an app?
Yes. Send the spreadsheet with inputs and rules marked, plus a few real quotes with correct totals, and the scope is written from that.
Why does the app give a different total from our spreadsheet?
Usually because of rounding at a different step or a rule that lives in someone's head rather than in a formula. A written rounding order and a test-case table settle it.
Who should own the pricing rules in a configurator?
Name one owner per rule. Rates that change often belong in an admin panel that the owner can edit; rules that rarely change can live in code.
What is a test-case table?
A list of realistic inputs with the result your business considers correct and the rule each row checks. The app is accepted when every row matches.
Can sales staff change prices in the configurator?
Only if the scope gives them that permission. Most businesses let named owners edit rates in an admin panel and keep the sales app read-only.
Written and reviewed by the DFY Games team. Published ; facts checked . Prices and store rules change: check the linked sources before you rely on a figure.