3
2 Comments

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?

on June 27, 2026
  1. 1

    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.

  2. 1

    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?"

Trending on Indie Hackers
I built a tool directory that doesn't pretend every founder has the same needs User Avatar 62 comments Drop your landing page URL. I'll use Ferguson to tell you why visitors might be leaving User Avatar 50 comments AI helped me ship faster. Then I forgot what my product actually does. User Avatar 37 comments I Was Picking the Wrong SaaS Tools for Two Years. Here's the Mistake I Finally Figured Out. User Avatar 33 comments Most early-stage SaaS companies miss churn signals — here’s how to catch them early User Avatar 28 comments How I Run a 1.7M Product Search Engine at 66ms on a $0 Hosting Budget User Avatar 19 comments