The fix for an empty state isn't filling it
Last week I posted on Indie Hackers about a decision in my renovation cost tool: it ships with an empty price book. The model reads the floor plan, plain Python does the math, and any line without a real, sourced price s
Last week I posted on Indie Hackers about a decision in my renovation cost tool: it ships with an empty price book. The model reads the floor plan, plain Python does the math, and any line without a real, sourced price stays "unpriced." I admitted the obvious cost. The first run feels like homework.
Within a day, seven people left real, specific suggestions. Not "great post." Actual designs. None of it is built yet. But reading them side by side taught me something I want to argue for:
The fix for an empty state is not filling it. It's making the blanks look like progress.
Here is how I'm sorting the ideas, including the one I'm turning down.
Keeping: show the blank as a step, not a failure
Three people (topapps, daiwik_builds and leadscout) landed on the same idea from different directions:
- Show progress, like "7 of 12 lines priced," instead of a wall of blanks.
- Label any total built from priced lines as partial, so nobody mistakes it for the full budget.
- Ask for the lines that move the total the most first.
- Next to every blank, say why it is blank and what to do next. Something like: "Unpriced: no quote yet. Request one from the package below."
What I like about this: it changes nothing about the numbers. The tool still refuses to invent a price. It just stops making the user feel like the tool is broken. An "unpriced" label with no next step reads as an error. The same label with a reason and an action reads as a to-do list.
The "biggest lines first" part is the one I'm least sure how to do honestly. To know which line moves the total most, you need some sense of its size before it's priced. Quantities alone (square feet of floor, length of wall) might be enough to rank by. A guessed price would not be allowed.
Keeping: let the price book fill itself through normal use
liranblumenberg pointed out that the tool already makes quote packages for contractors. So when a quote comes back, record it straight into the price book, with the source and the date attached. The empty book fills up as a side effect of doing the thing you were going to do anyway.
They added a detail I hadn't thought about: the UI should say clearly whether a quote can be reused on another project. A floor refinishing quote for one house is not a price for every house, and reusing it silently would be exactly the kind of quiet drift I'm trying to avoid.
Keeping: put scope next to the price
ska1296 suggested listing what each contractor's quote includes and excludes (debris removal, permits and so on) right next to the number. Two quotes for "refinish floors" are not comparable if one includes hauling and one doesn't. This is a small change that makes the real numbers more honest, which is the whole point of the tool.
Keeping: sanity check the one place the model touches numbers
gokulravi333 found the weak spot in my own argument. I say "no AI in the numbers," but the model reads the floor plan, and room dimensions are numbers. Their suggestion: check that room areas add up to the total, that dimensions fall in a plausible range, and flag "check this" when they don't.
This one stings a little because it's correct. Right now the safeguard is that a person has to confirm the overlay before outputs are treated as confirmed. A cheap arithmetic check before that step would catch the obvious misreads without asking the person to spot them.
Refusing: an AI estimate column with a confidence score
toptrack_software suggested a two column view: an AI estimate, clearly labeled, next to the real quotes, plus a confidence percentage.
I understand why. It directly fixes the homework feeling. A user opens the tool and immediately sees a number. And I suspect it's the version that would win in a side by side test of first impressions.
I'm still saying no, for two reasons.
First, anchoring. topapps replied in the same thread that if I ever add an AI number, it should be a wide range, kept out of the total, and visually secondary. I agree with that framing, and I think it shows the problem: the moment a number is on screen, it becomes the reference point. A buyer who sees "AI estimate" before any real quote arrives will judge the real quotes against a number nobody can trace.
Second, a confidence percentage looks like evidence. I have no way to say what "72% confident" means for a labor price in a specific city. If I can't explain where a number came from, I don't think the tool should show it, and a confidence score is a number too.
I could be wrong about this. It's the decision in this post I'm least comfortable with, because it trades a better first run for a principle.
What I learned from the thread itself
The post I wrote defended a decision. The comments didn't argue with the decision much. They redesigned the experience around it. That's a better outcome than agreement, and I wouldn't have gotten it if I hadn't written down the downside plainly. "The first run feels like homework" is the line people built on.
Everything above is a plan. The tool has still only been tested on fixtures, not real buyers, so I don't know yet which of these changes matters most in practice.
My question for you
If you've shipped a product that deliberately shows blanks or "unknown" instead of a guess, what made users accept it? Was it progress indicators, clear next steps, or did you eventually give in and add an estimate?
Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.