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?
The trust before UI insight is underrated brokers and analysts need to see the output before they care about the interface. The proof page approach is exactly right. The next question is how you get brokers to find those proof pages in the first place. That’s a very specific audience with specific watering holes. Curious what channels you’re planning?
Yes, distribution is the hard part.
My plan is not to rely on the proof pages alone. I see them more as the place to send people once they’re curious.
The channels I’m testing are:
I’m trying to avoid broad “CRE software” messaging and stay closer to one concrete pain: turning messy public listing searches into a clean first-pass market file.
Still early, but my guess is the proof page works best after a specific conversation or search intent, not as a cold homepage people magically discover.
The ‘send people there once they’re curious’ framing is exactly right the proof page converts, it doesn’t prospect. LinkedIn comments with junior CRE analysts is probably your fastest path to the first real conversations since they’re the ones doing the grunt work on market files. The SEO play will compound but takes time. Are you on Telegram, Discord or email? Would love to connect and dig into the LinkedIn angle specifically.
Yes, exactly — that distinction is useful: the proof page converts curiosity, it doesn’t create it by itself.
And I agree on junior CRE analysts. They’re much closer to the actual pain of building market files than the people buying enterprise software.
Would be happy to dig into the LinkedIn angle. Email is best for me: [email protected]
The line about making the product feel real before making it complex is exactly right. We've seen the same thing with DictaFlow: a generic homepage explains the category, but the pages that actually convert are the pain-specific proof pages like "does this work in Citrix?" or "what does this look like in Epic?" People usually don't want the architecture first. They want one concrete workflow, one believable example, and proof the output won't break in their world.
Exactly. “Will this work in my weird environment?” is usually a much stronger question than “what does the platform do?”
That’s what I’m trying to apply here too.
A generic page can explain the actor, but a market-specific proof page can answer a much more concrete question:
“What does a Dallas CRE market file actually look like?”
“Are the source links still there?”
“Are duplicates visible?”
“Are missing broker/cap-rate fields explained instead of hidden?”
That kind of page feels closer to the buyer’s real workflow than a polished architecture diagram.
Your Citrix/Epic examples are a great reminder that proof pages probably need to be built around anxieties, not just features.
"Proof pages" is the brilliant reframe. Most data founders build the dashboard first and pray people pay for the convenience. You flipped it: prove the data is valuable by showing the answers before the UI. That is the same trick used by every great newsletter (showing you a free article before asking for subscription) and every good API company (great docs = proof of capability). The $5/1k-listing price point also signals you understand your buyer—they are testing the data quality, not buying scale. Question: how many "proof pages" did you launch with, and how do you decide when a page graduates to a real dashboard feature?
Thanks, I like the newsletter/API docs comparison a lot.
I’m building the first proof site as a small cluster, not a huge content library:
The idea is to cover the main belief gaps: “what is this?”, “what does the output look like?”, “can I see a real market?”, and “how would I use it?”
For me, a proof page graduates to a dashboard feature when the same action keeps showing up after trust exists.
If people just read the page, that is traffic.
If they download the file, ask for their market, ask to repeat the run daily, or say “I wish I could save this search / compare these files / share this with my team,” that starts looking like product surface.
Until then, I’d rather keep the dashboard small and let the proof pages tell me which workflow deserves UI.
"Proof pages" is the brilliant reframe. Most data founders build the dashboard first and pray people pay for the convenience. You flipped it: prove the data is valuable by showing the answers before the UI. That is the same trick used by every great newsletter (showing you a free article before asking for subscription) and every good API company (great docs = proof of capability). The $5/1k-listing price point also signals you understand your buyer—they are testing the data quality, not buying scale. Question: how many "proof pages" did you launch with, and how do you decide when a page graduates to a real dashboard feature?
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.
Really appreciate this. “Truth layer” is exactly how I’m starting to think about it too.
For me, I wouldn’t treat the proof layer as “strong enough” just because the page gets traffic. The signal I’d look for is more behavioral:
That’s very different from “nice landing page.”
I don’t think I’d build the dashboard when users say “a dashboard would be cool.” I’d build it when the same friction shows up repeatedly after they already understand the output.
For example: if multiple users trust the CSV/report, but then say they hate going through Apify, want saved searches, alerts, team access, or a cleaner review interface, then the dashboard has a real job.
In my case I’m not there yet. I’m still trying to make the sample files and proof pages strong enough that someone can look at the output and immediately understand the value.
For your generated reports/insights, I’d probably ask: can someone read one report and say “I would send this to a client / use this in a meeting / make a decision from this”?
If yes, then the dashboard becomes a delivery layer.
If no, the dashboard may just make an unproven insight look prettier.
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.
Yes, that’s exactly the shift.
“What should I build next?” usually sends me toward features.
“What does someone need to believe before they buy?” sends me toward proof: sample files, real outputs, clear limits, source links, and examples tied to actual markets/workflows.
The uncomfortable part is that proof is harder to hide behind. A dashboard can look polished even if the core output is weak. A sample file cannot.
That’s why I’m trying to make the output itself carry the weight first. If people trust the file, then a dashboard becomes a way to make the workflow smoother. If they don’t trust the file, the dashboard is mostly decoration.
That's exactly the implication I was thinking about.
I think there's one strategic business decision sitting underneath your reply that becomes much more significant as the company grows, but I don't think I can do the reasoning behind it justice in a thread.
Happy to explain what I mean if it's useful. What's the best email to reach you on?
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?"
That’s a really good parallel.
For an API/token product, the “proof layer” is probably even more important because trust is not just about the output, it’s also about the billing trail.
If someone can see:
then the product starts feeling concrete before the dashboard exists.
I like the idea of sample route ledgers and receipts. It turns something abstract into an artifact people can inspect.
That’s the same thing I’m trying to do with CRE data: make the output traceable enough that someone can trust the row before caring about a nicer interface.