DEV Community

Yoshida.T
Yoshida.T

Posted on

Building Miniviz: A Minimalist BI Platform for IoT PoCs

#iot #buildinpublic #fastapi

What I Built

I built Miniviz, a minimalist BI platform to speed up IoT proof-of-concepts (PoCs).

https://miniviz.net/

The goal is intentionally simple:

  • Send time-stamped data
  • Store it without heavy setup
  • Visualize it quickly
  • Notify when something crosses a threshold

In many PoCs, the pain isn’t the sensor code—it’s everything around it (DB, auth, dashboards, alerts). Miniviz is my attempt to make that “cloud-side glue” thin enough that you can get to a first success fast.

A 10-minute Demo (curl only)

In this demo, we'll send a JSON event via curl, check it in the Database view, create a chart, and add an alert — all from a shell terminal, with no Python required.

1) Send a sample event

Generate a UNIX timestamp in milliseconds (pure shell):

TS=$(($(date +%s%N)/1000000))
Enter fullscreen mode Exit fullscreen mode

Export your credentials:

export PROJECT_ID="YOUR_PROJECT_ID"
export TOKEN="YOUR_TOKEN"
Enter fullscreen mode Exit fullscreen mode

Send a JSON payload:

curl -sS -X POST \
  "https://api.miniviz.net/api/project/${PROJECT_ID}?token=${TOKEN}" \
  -H "Content-Type: application/json" \
  -d "{
    \"timestamp\": ${TS},
    \"label_key\": \"local_pc\",
    \"payload\": {
      \"temperature\": 25.0,
      \"humidity\": 55.0,
      \"switch\": \"true\",
      \"system_status\": \"running\"
    }
  }"
Enter fullscreen mode Exit fullscreen mode

2) Confirm it in the Database view

it in the Database view

Open the Database page. You should see parsed values like temperature, humidity, switch, etc.

3) Create a chart

Create a line chart using temperature (and optionally humidity) as the data source.

4) Add an alert (Slack / Email / Webhook)

Create a threshold alert like temperature > 30, then test it by sending another event with a higher temperature.

The Problem with Current IoT PoCs

IoT PoCs often get stuck on cloud-side setup before even getting to sensor or device implementation:

  • Database setup, permission management, visualization tooling, and notification integrations
  • AWS/GCP are powerful but often overkill for early PoCs
  • “Automation tools” can work, but time-series data with timestamps can get awkward once you care about consistency and repeatability

The result is that the time to “first working dashboard” becomes long, and PoCs lose momentum.

Philosophy & Design

Miniviz’s philosophy is pragmatic and deliberately limited:

  • Make storage + visualization + notifications available in one place
  • Minimize setup friction (a simple POST API)
  • Require no special SDK (works with ESP32, Python, curl, etc.)
  • Keep notification destinations minimal (start with what’s necessary)
  • Assume advanced analysis happens via CSV export in familiar tools
  • Support image storage as a separate category (object storage) with cost control (Pro plan)

For PoCs, “minimum viable and immediately usable” is often more valuable than “can do everything.”

Tech Stack

I chose a modern stack that’s sustainable for solo development:

  • Backend: FastAPI
  • Frontend: React (Next.js)
  • Database: PostgreSQL (Supabase)
  • Image storage: Google Cloud Storage (GCS)
  • Hosting: Cloud Run (GCP) for API, Vercel for frontend

Key Learnings (from solo development)

This is a solo project, so I had to choose an architecture that’s sustainable rather than “the perfect architecture.” Here are three trade-offs that mattered the most.

1) Going “modern” with hosting boosted development speed

Problem:
IoT PoCs often stall on deployment and ops before features. In solo development, server management and environment differences become immediate technical debt.

Decision:
I moved the API to Cloud Run and the frontend to Vercel, making deployment nearly one-click and reducing environment friction.

Trade-off:
Vendor lock-in increases. But for PoCs, the most important thing is the distance to the first successful experience, so I accepted it.

Learning:
For solo IoT projects, a sustainable deployment workflow matters more than architectural purity.

2) For images, object storage was the right choice over a database

Problem:
IoT isn’t just numeric telemetry. Field photos, meter snapshots, and other images often matter—even in PoCs.

Decision:
I store images in GCS and keep only metadata (URL/key/timestamp/label) in PostgreSQL.

Trade-off:
Uploads require constraints (signed URLs, size limits), permission design, and cost awareness. I chose to control this via plan tiers.

Learning:
Images aren’t a “small feature.” They are a separate category that includes storage, permissions, and cost design.

3) Authentication is always a UX vs security trade-off (especially for IoT)

Problem:
Complex auth like OAuth is not practical for many devices. But careless token handling leads to leaks and abuse.

Decision:
I used a low-friction project_id + token approach so that any device/language can send data quickly.

Trade-off:
Token risk remains, so you need a baseline: scoped permissions, revocation/rotation, and rate limiting.

Learning:
“You can secure it later” doesn’t work—even for PoCs. Lightweight auth needs a non-careless baseline from day one.

Try it (optional)

Miniviz is live at https://miniviz.net
and the quickstart is at https://docs.miniviz.net/quickstart.html.

What’s Next

I’ll keep maintaining Miniviz while improving:

  • More user-facing recipes and references
  • UI/UX
  • International docs and onboarding

If you try it and run into friction, I’d love to hear what blocked you—those are usually the most valuable signals for a PoC-focused tool.

Top comments (0)