I got the data. Then I realized none of it was usable.

That was probably the biggest lesson while building my latest data product.

At first, I thought the hard part was collecting the data.

You know the usual developer brain:

“If I can pull the records, structure the fields, export a CSV/API, then the product is basically working.”

But once I started working with commercial real estate listing data, I realized the real problem was not access.

The real problem was trust.

A row can be technically “valid” and still be useless.

Same property, slightly different address.
Missing cap rate.
Different price format.
Lease and sale fields mixed together.
Broker info available on one source, missing on another.
A listing that looks fresh but may not be.
No clear source link to verify anything.

So the product shifted in my head.

It was no longer just “collect listings from LoopNet and Crexi.”

It became:

“How do I make this row understandable enough for someone to actually use it in a market file?”

That’s why I started adding things like source links, duplicate signals, enrichment status, cap-rate context, days-on-market when available, and broker fields when public.

Not because they sound fancy.

Because without them, the user still has to manually ask:

“Can I trust this?”

I packaged the current version as an Apify actor here:
https://apify.com/kazkn/commercial-real-estate-brokerage-intel?fpr=8fp2od

Still early, but it taught me something I keep seeing in vertical data products:

The product is not the extraction.
The product is reducing the user’s doubt.

Curious how other builders handle this.

When your data has uncertainty, do you expose it clearly to the user, or do you hide it behind a cleaner-looking output?