Why we build first and talk money later

We do the first phase for free. Listening, pulling data, building a working prototype. Only after that do you decide whether there is a follow-up.

That sounds like a sales formula, and I understand the suspicion. So here is why it exists, and it has little to do with selling.

A quote up front is a guess

If you ask me what a dashboard costs for your business, and I name a figure before I have seen your data, I am making that number up. Put kindly: I am estimating it based on what similar projects cost.

The problem is that the gap between two similar businesses can be enormous, and that the gap is never in the question. It is in the state of the data.

Two companies with the same question, the same size and the same software package can be a factor of three apart because one of them uses its article numbers consistently and the other does not. You cannot see that in an intake conversation. Not me, and not you either.

And you cannot tell me either

This is the second part, and it sounds harsher than it is meant.

If you knew exactly where things go wrong in your data, you probably would not need me. The problem is usually not that the information is missing, it is that nobody ever bothered to lay the sources side by side. What comes out of that is new to both parties.

I have had projects that started with a question about margin where the real bottleneck turned out to be stock registration. Projects about labor cost that turned out to be about scheduling. You find that by building, not by meeting.

What I get out of it

Being honest about the other side: I am not doing this only for you.

By building, I see where it goes wrong. Which source is messy, which definition does not hold, how much work is really in it. That means I can then give a price that is accurate instead of a price with a safety margin on top.

That safety margin, by the way, is where most clients overpay. Anyone who writes a quote without having seen the data has to cover themselves against the worst case. They pass that on, also when it turns out fine.

And I get to see whether I can mean anything here. Sometimes the answer is no. Sometimes a business just needs a decent export and not a dashboard. I want to know that before there is an invoice, because a project that delivers no value ends up costing me more than it brings in.

What a prototype is and is not

It is: running numbers from your own sources, with the question you started with answered. Enough to see whether it holds up and whether it is useful to you.

It is not: a finished system. There is no automatic refresh on it, the definitions are provisional, and nothing has been built for maintenance. That is precisely the difference with what comes after.

I say that up front, because a prototype presented as a finished product is a dishonest sales trick.

Why this is also less risk for you

You can walk away after that phase without having paid anything, and with the knowledge that came out of it. That is the intention.

If you do, I have invested time without a result. I take that risk deliberately, because in practice it rarely happens that someone who sees their own numbers properly for the first time then says it is not for them.

And if it does happen, then that project really was not for you. Then we both learned something without any money being lost.

The claim

A quote for a data project that nobody has seen the inside of is a price with insurance baked in. You are paying for your supplier's uncertainty. Building is the only way to remove that uncertainty before a figure lands on the table.