You built a solid internal tool. It manages customers, tracks orders, handles operations. Your team lives in it every day.

Then someone in leadership asks: "Can we get a report showing monthly revenue by plan type, broken down by region?"

And you realize — your tool has no reporting layer. No charts. No exports that make sense. Just raw data sitting in a database, and a Slack message you're trying to figure out how to answer.

This is one of the most common pain points for developers building internal tools. The app works great. But reporting gets bolted on as an afterthought, and you end up spending a week building a half-baked export feature, or worse — someone starts maintaining a spreadsheet manually synced from the database.

There's a faster path. Tools like Draxlr connect directly to your database and can have a working dashboard up in minutes. But whether you use a tool or build it yourself, the approach is the same — let's walk through it.

Why Developers Put Off Reporting (Until It's Urgent)

Reporting feels deceptively simple — "just run a query and show a chart." But in practice, you're solving multiple problems at once:

• Data access: Who should see what? Should your CS team see revenue numbers?
• Query complexity: Business metrics rarely map to a single clean table. They require joins, aggregations, date bucketing, and edge-case handling.
• Freshness: Should the report be live, or cached? How often does it need to update?
• Presentation: A raw SQL result set isn't a report. Charts, filters, and formatting all take time.
• Maintenance: Metrics change. The query you write today will need updates next quarter.

Most developers underestimate this surface area and either overbuild (a full custom analytics module) or underbuild (a CSV export button). Neither serves the team well.

The Two Paths — and Why One Is Much Faster

Path 1: Build it yourself. You write query logic, wire up a charting library (Chart.js, Recharts, etc.), build filter controls, handle date ranges, add pagination, and manage permissions. For a non-trivial set of reports, this is 2–4 weeks of engineering work, minimum.

Path 2: Connect your database to a SQL dashboard tool. Your database already has the data. You write the queries (the part only you can do), and a tool handles the rest — visualization, sharing, access control, and filters.

Path 2 is almost always faster, and for internal tooling it's almost always good enough.

The key is picking the right queries to expose, and structuring them cleanly. Let's do that.

Step 1: Identify the 5–8 Metrics That Actually Matter

Don't build reporting for everything. Talk to the actual users of your internal tool and find out what they check daily, weekly, or monthly. This is usually a short list:

• New signups this week vs. last week
• Revenue by plan / subscription tier
• Churn rate this month
• Support tickets opened vs. closed
• Active users by feature

Resist the urge to build an all-encompassing analytics suite. Start with 5–8 metrics, ship them, and iterate. Your team will tell you what's missing.

Step 2: Write Clean, Reusable SQL Queries

Here's where you add the most value. Write the queries carefully — they're the foundation everything else will sit on.

Example: New signups per week

SELECT
  DATE_TRUNC('week', created_at) AS week,
  COUNT(*) AS new_signups
FROM users
WHERE created_at >= NOW() - INTERVAL '90 days'
GROUP BY 1
ORDER BY 1;

Example: Monthly recurring revenue by plan

SELECT
  DATE_TRUNC('month', s.started_at) AS month,
  s.plan_name,
  SUM(s.monthly_amount) AS mrr
FROM subscriptions s
WHERE s.status = 'active'
GROUP BY 1, 2
ORDER BY 1, 2;

Example: Churn rate this month

SELECT
  COUNT(*) FILTER (WHERE canceled_at >= DATE_TRUNC('month', NOW())) AS churned_this_month,
  COUNT(*) FILTER (WHERE started_at < DATE_TRUNC('month', NOW())) AS active_start_of_month,
  ROUND(
    100.0 * COUNT(*) FILTER (WHERE canceled_at >= DATE_TRUNC('month', NOW())) /
    NULLIF(COUNT(*) FILTER (WHERE started_at < DATE_TRUNC('month', NOW())), 0),
    2
  ) AS churn_rate_pct
FROM subscriptions;

Example: Feature usage over the last 30 days

SELECT
  event_name,
  COUNT(DISTINCT user_id) AS unique_users,
  COUNT(*) AS total_events
FROM events
WHERE created_at >= NOW() - INTERVAL '30 days'
  AND event_type = 'feature_used'
GROUP BY 1
ORDER BY 2 DESC
LIMIT 20;

Write these in a place where you can share and version them — even a reports/ directory in your repo works fine.

Step 3: Connect Your Database to a Dashboard Tool

Once your queries are solid, point a SQL dashboard tool at your database. Most support direct connections to PostgreSQL, MySQL, or SQLite. You paste in the query, set up the visualization, and you're done.

Here's what a setup typically looks like end-to-end:

Total time to a working internal report: a few hours, not a few weeks.

Step 4: Add a Date Range Filter (Don't Skip This)

The most common thing users will want to do is change the time window — "show me last month" or "show me Q1." Hardcoding dates in your queries makes this painful.

A better pattern is to parameterize the date range at the dashboard level. Most SQL dashboard tools support query parameters:

-- With parameterized date range (Draxlr / Metabase style)
SELECT
  DATE_TRUNC('day', created_at) AS day,
  COUNT(*) AS signups
FROM users
WHERE created_at BETWEEN {{start_date}} AND {{end_date}}
GROUP BY 1
ORDER BY 1;

The tool injects user-selected values at query time. You get a filter for free without any frontend code.

Common Mistakes to Avoid

Mistake 1: Including test accounts in your metrics

Your internal test@yourcompany.com users will skew signup counts and event metrics. Always filter them out:

WHERE email NOT LIKE '%@yourcompany.com'
  AND is_test = false

Mistake 2: Not handling soft-deleted records

If your app uses soft deletes (a deleted_at column), every query needs to account for them. Missing this makes your user counts and revenue figures wrong:

-- Wrong: counts deleted users
SELECT COUNT(*) FROM users;

-- Right: only active users
SELECT COUNT(*) FROM users WHERE deleted_at IS NULL;

Mistake 3: Displaying stale data without saying so

If your dashboard queries run on demand against a production replica, it's fine. But if you're caching results, show the last-refreshed timestamp. Nothing erodes trust faster than someone making a decision on data that's 3 days old without knowing it.

Mistake 4: Treating the dashboard as done

Business metrics evolve. Plan names change. New features get added. The query that was accurate in January might be wrong by June. Schedule a monthly review of your key reports to verify the numbers still make sense.

Mistake 5: One giant query that does everything

It's tempting to write one mega-query that produces a wide result set for multiple charts. Don't. Separate concerns into separate queries. They're easier to debug, easier to update, and run more efficiently.

Key Takeaways

• Most internal tools need reporting far sooner than developers plan for it.
• The fastest path is: write good SQL queries → connect them to a dashboard tool → share with your team.
• Start with 5–8 metrics, not a full analytics platform.
• Parameterize date ranges so non-technical users can explore the data themselves.
• Always filter test accounts, handle soft deletes, and schedule periodic query reviews.

The engineering work worth doing here is the SQL — understanding your data model well enough to write accurate, meaningful queries. The rest (visualization, sharing, filters, permissions) is where a good SQL dashboard tool earns its place.

What does your internal reporting stack look like? Are you building it yourself, using a tool, or still on the "forward it to Slack" system? Drop a comment — I'm curious how other teams handle this.