we spent 14 months building a custom reporting platform that's now replacing power bi where i work. this post covers the decisions that shaped it — when replacing a bi tool makes sense, what actually drives adoption, and how we architected the system to serve both dashboards and ai agents from the same data layer.

when does replacing your bi tool make sense?

not always. power bi, looker, tableau — they work for most companies. we ran power bi for five years and it did its job.

the trigger wasn't that power bi was bad. it was a set of limitations that were getting harder to work around:

• single point of failure — refreshing data required manual action on a specific machine
• rigid report distribution — monthly reports went through a third-party saas tool. automated, but any changes to formats or recipients meant working within their platform.
• data fragmentation — different teams were pulling data from different places. some from power bi, some from other tools, some building their own charts from csv exports.
• ad-hoc analysis bottleneck — every one-off data question funneled to one person

if your bi setup is stable and you have a dedicated data team, you probably don't need to replace it. but if one person is wearing multiple hats and the reporting setup is creating bottlenecks, building something custom might make sense.

what drives adoption

the moment people started preferring the new dashboard over power bi wasn't when the ui improved. it was when it connected external data sources.

we integrated hubspot (crm) and quickbooks (accounting) so the dashboard could pull deal data, actual expenses, and lease costs — then combine them into a per-property profit & loss view.

before this, seeing property-level profitability meant manually assembling a spreadsheet from four different exports. now it was a page with filters.

the thing that replaced power bi wasn't a better version of power bi. it was connecting data that power bi couldn't easily reach. once the dashboard showed something unavailable anywhere else, people had a reason to switch.

if you're trying to replace an existing tool, don't compete on the same features. find the data gap — the question nobody can answer without a spreadsheet — and solve that first.

matching tools to your stage

the project went through three rewrites:

each rewrite served a purpose:

• v1 validated that live data was useful. the priority was accuracy and usefulness, not polish — if the numbers aren't right, it doesn't matter how good the ui looks.
• v2 revealed which features people actually relied on (sortable tables, multi-select filters, csv exports — things streamlit couldn't do well).
• v3 only worked because the first two scoped the problem.

resist the urge to start with the "right" architecture. you don't know enough yet. the scrappy version teaches you what to build. the polished version is for when you know.

the architecture

flowchart TB
    A[Frontend
Next.js + shadcn
22 pages, cascading filters] --> B[FastAPI Backend]
    B --> C[Dimension Layer
auto-resolves filters
across all queries]
    C --> D[Redis Cache
optional — works without]
    D --> E[MySQL
bookings, vehicles,
users, telematics]
    D --> F[HubSpot
deals, property
metadata, rev share]
    D --> G[QuickBooks
actual expenses
by month]
                        

before vs after:

key architectural decisions:

multi-source data layer. the p&l page merges four data sources — mysql for bookings, hubspot for contract terms and revenue share, quickbooks for actual expenses, and a separate table for lease data. property name normalization, date alignment, handling mismatches between sources — this is where most of the effort went.

dimension layer. inspired by how power bi propagates filters through table relationships. select a state or property on any page → a shared dependency resolves which properties match → every query gets filtered automatically. adding a new filter dimension = one file change, zero page changes.

caching. the dashboard reads from the same production database that the live application writes to. without caching, every page load and filter change hits that database directly — competing for resources with the system serving actual customers. redis sits between the dashboard and the database so repeated queries get served from cache instead of creating additional load on production. it also tracks when the database was last queried, so the frontend shows "data as of 3:42 PM" instead of just the current time.

the overall flow:

flowchart LR
    A[Data Sources] --> B[Repository
SQL]
    B --> C[Services
Business Logic]
    C --> D[API Routes]
    D --> E[Frontend]
    D <--> F[MCP Server]
    F --> G[AI Agents]
                        

the separation between layers is what makes it possible to add pages without breaking existing ones — and what makes the ai integration work.

making bi conversational

a dashboard handles the known questions — metrics you check regularly. but a lot of business intelligence is ad-hoc. someone asks something in a meeting, and the answer requires knowing how to query it.

the traditional workflow for those questions:

1. someone has a question
2. they ask the data person
3. data person pulls from the database or bi tool
4. maybe exports a csv, does some analysis
5. sends findings back

the idea: build a data layer that both humans and ai agents can talk to.

every api endpoint is automatically exposed as an mcp server (model context protocol — a standard for giving ai tools access to external data). every query the dashboard can run is also a tool any ai agent can call.

flowchart TB
    A[Web Dashboard
Next.js
daily monitoring, structured reporting] --> C[FastAPI
API Layer]
    B[AI Agents
slack, cli,
any mcp client] --> D[MCP Server]
    D --> C
    C --> E[Data Sources
MySQL, HubSpot, QuickBooks]
                        

we have agents in slack that people chat with. someone asks "how did properties perform in february vs january?" and the agent queries the same api endpoints, same data, responds conversationally.

it's not locked to slack — the mcp server is just an endpoint. anyone can build their own agent on any platform and connect to the same data layer. the dashboard and the agents are two interfaces to the same system.

who can make changes

there's a practical benefit that's easy to overlook.

updating power bi means knowing DAX, understanding the data model, writing measures. with a codebase and ai-powered coding tools, the barrier shifts — anyone who can describe what they want in english can open the repo and have an ai handle the implementation. "add a column showing revenue per vehicle by month" is a conversation now, not a specialized skill.

this changes who can maintain and extend reporting infrastructure. it goes from "the person who knows the query language" to "anyone who can describe what they need."

where it stands now

the transition is gradual. power bi still runs for a few legacy views, but people are already using the dashboard for anything they can't find in power bi or need updated more frequently.

what's in place:

• live data — real-time from production, any device
• monthly reports — automated via sendgrid, replacing the third-party service (~$65/mo saved, sendgrid on existing plan)
• ai agents — slack-based conversational access to the same data
• 22 reporting pages — revenue breakdowns, insurance reports, p&l, cohort retention, fleet ops, and more

ai in the development process

cursor early on, claude code from mid-2025. here's what specifically worked and what didn't:

what worked:

what didn't:

ai doesn't understand business context. it doesn't know that "collected revenue" means something specific at your company, or that a telematics vendor switched units at a specific date. plausible-looking but wrong numbers come from undocumented business logic that ai has no way to know about.

the skill isn't prompting — it's knowing the domain well enough to catch when the output is off.

the handoff

knowledge transfer went well because most artifacts were built along the way — feature docs, a detailed worklog, architecture docs, a data dictionary auto-generated from the backend.

the one thing left too late: auth. the dashboard was an open url for months. "it's just internal" doesn't age well.

document as you go. add auth early.

takeaways

the project started as a weekend build and grew into the company's reporting platform over 14 months. not glamorous, but it worked.