I built a SaaS that turns messy company data into dashboards, cited AI answers and a secure API

Six months ago I kept hearing the same thing from small business owners: "My data is everywhere, and I can't answer a simple question about it."

Sales in Shopify. Payments in Stripe. Costs in Excel. Forecasts in Google Sheets. And no analyst on the payroll.

So I built DataShowing — and I want to share the three design decisions that made it trustworthy enough for real company data.

The problem with "just ask the AI"

Everyone is bolting AI onto products right now. But when the data is company data, a free-form AI is a liability:

• It can hallucinate numbers that don't exist.
• It can leak data across tenants if your isolation is sloppy.
• Nobody can audit what it actually read.

So I inverted the model: the AI never generates facts, it only formulates queries. Every number you see in an answer comes from a real row in your database, and every answer links back to the exact query that produced it.

Decision 1: Row-level security at the database layer

Multi-tenancy is usually done in application code: WHERE tenant_id = ?. One forgotten filter and you have a breach.

DataShowing enforces isolation with Postgres row-level security policies. Even a bug in my application code cannot read another tenant's rows, because the database itself refuses. The AI runs under the same read-only role — it physically cannot write, delete, or cross tenants.

Decision 2: The AI is read-only and cited

The analyst endpoint (POST /v1/ai/analyze) takes a question like "What was my best-selling product in September and why?" and:

1. Generates a SQL query (never executed directly — it goes through a validator).
2. Executes it with a read-only, RLS-scoped role.
3. Returns the answer with the query, the rows used and a confidence note.

If the data doesn't support an answer, it says "I don't have data for that" instead of inventing a KPI. That single behavior is what makes founders actually trust the tool.

Decision 3: Everything is an API

Dashboards are for humans. But half of my users wanted their numbers in their own apps, Slack bots or weekly email reports. So every dataset is exposed through a versioned REST API with scoped keys:

curl https://datashowing.com/v1/datasets/42/profile \
  -H "x-api-key: $DS_API_KEY"

Versioned means when I change a response shape, v1 keeps working. Your integrations never break because I shipped a feature.

The stack (boring on purpose)

• TanStack Start + React on the frontend.
• Postgres with RLS for every tenant boundary.
• CSV, Excel, Shopify, WooCommerce, Google Sheets and Stripe connectors for ingestion.
• A read-only analyst layer on top of the same database your dashboards use — one source of truth.

Pricing that a solo founder can expense

Starter at €2.99, Business at €5.99 (no VAT, UK company). No sales call, no "contact us". You connect your data and you have a dashboard in ten minutes.

What I'm learning from building in public

The unsexy truth: the hard part was not the AI. It was making the ingestion boring and predictable — deduplicating rows, normalizing currencies, handling timezone chaos in Stripe exports. Garbage in, garbage dashboard out is the real law of analytics.

I'm documenting the whole journey — distribution, SEO, what works and what flops. If you're building something similar, I'd love to compare notes in the comments.

Try it free: datashowing.com — feedback is more valuable than money right now.

Posted by the founder. I read every comment.