Getting your pricing spreadsheet in: weeks, and a developer

You have a pricing spreadsheet that took years to get right, and you want to know how long it takes to move it into a quoting system, and whether it needs a programmer every time. The honest answer for our quoting product, written on 26 August 2026, is that it takes weeks of a developer’s time, and that it needs one every time, because the tool that would let you do it yourself has not been built.

That is a limit on how many customers we can take on. If every new customer costs weeks of a developer’s effort, the number we can serve in a year is our developer weeks divided by that figure. A better product does not change it, and neither does better selling.

What was actually going on

The system was built for several companies from the start. Every record is tagged with the company it belongs to, every query filters on it, logins need a company code, and permissions and branding are separate per company. One customer’s data cannot leak into another’s. That half was done properly.

The other half, getting a new company’s real data in, was nobody’s design problem until the second customer was in view. Here is what getting the first customer in involved.

The pricing rules arrived as a spreadsheet. It could not be loaded directly, because it wrote material references in one style and the pricing engine expected another, so every formula had to be rewritten on the way in.

Then it was audited. Every calculation was checked for steps that referred to a value no earlier step had produced, which turned up 121 problems. A repair step proposed corrections for around 120 rules, and a person had to confirm each one rather than accept it.

Twelve rule codes were named in the mappings and defined nowhere. Establishing that they were genuinely missing, rather than a loading error, took a full pass over three sheets.

The material groups were next. Fifty-four had arrived with their short code copied into the name field, so the screen showed a two-letter code where a description belonged. Thirty-five were matched to proper names by reading the customer’s own stock price list, seven sheets and four hundred-odd codes. The other nineteen appeared nowhere in that list and were named by looking at what each group actually contained.

Finally, fifty-one pricing rules had placeholder names (a grade string, an automatic label or the code repeated) and seven more were referred to by nothing. All were renamed to something a fabricator would recognise.

After loading, the counts of materials, services, suppliers, rules, compositions and mappings were checked against the spreadsheet, and every difference was explained. Every step was necessary, and every one needed someone who could write and run code against the data.

What is still open

The importer that would replace all this is not built. Today, a second customer would cost close to what the first did, less what we learned, which is real but not most of it.

What exists is a complete description of the feature. The manual work breaks into the parts a self-service importer needs: a published template saying what each column means; a check that reads the file and reports, before anything is saved, every reference that does not resolve and every broken calculation; a dry run that says what would be created and how many; a report after loading that matches the file to the result in both directions; and a refusal to accept master data whose name merely repeats its code. All of these exist as scripts run by their author against one customer’s data, with that customer’s file paths built in. That is the distance between something that works once and a product feature.

What it did not fix

Nothing here shortens your onboarding today. The scripts make a second customer cheaper than the first, but they are not something you can run yourself. We also made a mistake in how we worked: we did the first onboarding by hand and wrote down the results, not the rules. The input rules and checks for each step now have to be reconstructed from scripts and notes, which is a worse version of what we would have had by writing them as we went.

The pattern, for anyone buying software that has to hold your data

Before you sign, ask the vendor what it takes to load your real data and who does it. Ask how many customers they onboarded last year, and whether any of them did it without a developer. If the answer involves a person writing scripts, the vendor’s capacity to take you on is set by that person’s time, and your go-live date is set by the same thing.

Ask too for the check that runs before anything is saved. A list of what will be created, compared with what your file contains, is the difference between finding a problem on day one and finding it in a quote.

Where this ends up

The system described here is Sazinga Quote, where a company’s materials, services, suppliers, pricing rules, compositions and mappings all have to arrive before anybody can price a job. The company separation was never the limit. The path the data takes in is.