My $5/1k-listing data product didn’t need a dashboard yet. It needed proof pages.
I almost made the classic indie mistake: turning a working backend into a SaaS dashboard too early.
I built an Apify actor that turns public LoopNet + Crexi searches into a cleaner commercial real estate market file: source links, duplicate signals, cap-rate context, days-on-market, broker fields when available, and CSV/API export.
The first instinct was obvious:
“Now build the web app.”
Dashboard, login, saved searches, billing, onboarding, all of it.
But after talking to people and watching how they reacted, I realized the bigger problem was not the UI yet.
The problem was trust.
A broker or analyst does not immediately care that I have an actor running in the background. They want to know:
- What does the final CSV look like?
- Is the data clean enough to scan?
- Are source links preserved?
- Are duplicates flagged?
- Are missing fields explained?
- Can I use this for a real market, not just a demo?
So instead of building a full SaaS, I’m building a small “proof site” around the actor.
The first version has:
- a homepage
- a product page
- a demo page
- a sample CSV page
- a LoopNet vs Crexi comparison article
- an export-to-CSV guide
- a Dallas sample dataset page
- a Phoenix sample dataset page
The goal is not to make the site feel huge.
The goal is to make the product feel real before asking someone to run it.
The actor itself is still the engine. The site is the layer that explains the use case, shows proof assets, and gives search traffic somewhere better to land than just a marketplace listing.
This also changed how I think about “marketing.”
I used to think: write articles, post on LinkedIn, get traffic.
Now I’m thinking more like:
Can someone land on one page, understand one pain point, download one sample file, and immediately see whether this is useful?
That feels much closer to product validation than just adding more features.
Actor is here if anyone wants context:
https://apify.com/kazkn/commercial-real-estate-brokerage-intel?fpr=8fp2od
Curious how others think about this:
At what point do you build the dashboard, and at what point do you keep the backend/tool as the product and just build better proof around it?
This is one of the clearest explanations I’ve seen of “building proof before product UI.”
The part about trust really stood out. Before users care about dashboards, filters, or features, they need to believe the output is real, useful, and directly applicable to their workflow. Without that, even a well-designed SaaS just feels like another tool they don’t trust yet.
I’m currently building a SaaS tool, and I’ve been struggling with a very similar question: how much should I invest in the dashboard vs. how much should I focus on proving that the insights themselves are valuable?
In your case, the CSV acts as the “truth layer.” In my case, it would be the generated reports/insights.
A few questions I’d love your perspective on:
This idea of “making the product feel real before making it complex” feels like a very underrated stage in early SaaS building.
I think the important shift here is that you stopped asking "what should I build next?" and started asking "what does someone need to believe before they'll buy?" Those are completely different questions. A dashboard improves the experience after trust exists. Proof pages create the trust that makes someone want the dashboard in the first place. That's a much harder problem, but probably the right one to solve first.
I like this distinction a lot. For Tokens Forge, I keep seeing the same thing: before people care about a full dashboard, they want proof that the output and billing trail are trustworthy. For an AI token/API product, that means sample model-price pages, example route ledgers, sample AI Researcher reports, and clear receipts showing which model route ran and which balance paid. The dashboard matters later, but proof pages can answer the buyer's first question faster: "will this output be clean enough, traceable enough, and predictable enough to use?"