In the previous post, we covered the business planning aspects of building a large-scale Excel SaaS. This time, we’ll dive into the technical side—what it takes to build something like this from the ground up, what drives the complexity, how much it would cost if I'd simply hire a team to do it for me, and how to keep everything organized.

The Scope of the Project in Technical Terms

Let’s step back for a moment and remind ourselves what we’re actually trying to build here. The goal isn’t to create just another static Excel-based dashboard—there are already plenty of those, and they all suffer from the same limitations. Instead, we’re setting out to build a fully-fledged BI tool that allows users to design and structure their own dashboards however they want.

If we do this right, our project should outperform the market leaders (Tableau, Power BI) in three key areas:

• Graphics – Absolute freedom to create and manipulate any visual component.
• Speed & Performance – Everything should feel instant, even with heavy visuals.
• Customization – No predefined layouts; complete control over every element.

Now, let’s break each of these down in more detail.

Graphic Requirements

We need to be able to produce any kind of graphical element we want—whether it’s a simple 2D shape, a 3D object, a line, a text-based element, or something completely custom. We shouldn’t be limited to Excel’s native shapes or standard chart types; everything should be fully customizable down to the smallest details.

That means we need complete control over:

• Colors, gradients, shadows, glows
• Line thickness, styles, and patterns
• Reflections, 3D effects, and rotations
• Positioning, layering, and alignment

Since our goal is to surpass the web-based counterparts, we can’t cut corners here. Every visual element needs to be drawn with absolute precision, and we need a system in place that allows users to tweak and modify anything they see.

Speed & Performance Requirements

One thing is clear: if this thing lags, it fails.

A normal-sized dashboard should load within 3-4 seconds, which means an individual chart should take less than a second to render. The UI—navigating menus, tweaking settings—should feel instantaneous.

The problem? We’re planning on implementing some seriously advanced graphics, which means getting to these performance numbers won’t be easy. Excel isn’t built for high-performance rendering, so we’ll have to engineer the shit out of this to make it work. That means:

• Minimizing recalculations – No unnecessary refreshes.
• Smart object handling – Only updating what actually changes.
• Optimized rendering pipelines – No bloated VBA loops or inefficient drawing methods.

This is where things get tricky, but it’s also what will set this project apart from every other Excel-based dashboard tool out there.

Customization Requirements

We’re not building a tool with predefined templates. Instead, we want to give users the ability to create their own graphical components from scratch.

• Any shape or combination of shapes should be possible—whether it’s 2D, 2.5D, or 3D.
• Users should be able to apply modifiers (adjust shapes, add effects, tweak interactions).
• They should be able to arrange these components in any pattern and link them to live data that controls their behavior.

At its core, this is how charts work: a combination of graphical elements, arranged dynamically, and controlled by data. But we want to go beyond standard charts.

Once a user has built a custom chart, they should be able to:

• Place it anywhere on the dashboard—no predefined grid layouts like web-based tools force you into.
• Hook it into actions, like exporting data, applying transformations, or triggering something custom.
• Create buttons and logic-based components, so they can interact with their dashboards in ways that aren’t possible in existing tools.

For example, instead of a generic “Export to Excel” button, they could create a custom button that converts all currency values to Chinese Yen or reverses the chart order dynamically.

That’s the level of control we’re aiming for.

How Much Would It Cost to Build This?

Now that we know what we’re building, let’s talk about the real cost of hiring a team to do it instead. Spoiler: It would cost a fortune—not just because of the complexity but because we need people at the absolute top of their field to make it work.

Of course, you should take all of the figures with a grain of salt, but I consulted 3 different AIs, gave them the scope and quality of what we are expecting as an output and I took the average from them.

Option 1: Building This in Excel (VBA-based Solution)

To build something at the highest possible quality, we’d need a team of specialists:

• Excel/VBA Lead Developer (15+ years experience) – To architect a custom VBA framework and push Excel beyond its limits.
• Graphics/UI Specialist (Excel & Custom Rendering) – To develop a custom graphics engine that allows 2D/3D elements, effects, and fully interactive visuals.
• BI/Data Expert (Power Query, Power Pivot, DAX, M, SQL, APIs) – To handle data modeling, integration, and advanced calculations.
• Performance Optimization Engineer (Excel/VBA, API integration) – To ensure charts render in under a second and dashboards load in 3–4 seconds.
• Project Manager (Excel SaaS development) – To keep everything on track and prevent scope creep.

A 5–6 person team working full-time at this level would likely take 2–2.5 years to complete the project properly.

At $125–$175/hour per expert, this brings the total cost to somewhere between $1M – $1.6M.

Why is it so Expensive?

There’s no off-the-shelf solution for what we’re building. Every major component—graphics rendering, interactivity, data processing, and user interface mechanics—needs to be custom-built from scratch.

Even Microsoft doesn’t push Excel’s graphical engine this far. The level of engineering required is far beyond typical VBA development, requiring specialists in data processing, UI design, and high-performance optimization.

Option 2: Building This as a Standalone SaaS (Non-Excel Solution)

If we wanted to replicate everything outside of Excel, we’d basically need to rebuild an entire BI tool from scratch, including:

• A custom visualization engine – No existing tool gives this level of control over 2D/3D graphics.
• A Power Pivot alternative – For fast, in-memory data processing.
• A Power Query-like ETL system – To handle live data connections and transformations.
• A completely new UI system – Since standard charting libraries (D3.js, Plotly) don’t allow this much customization.

This means hiring a larger team with diverse expertise:

• Frontend Developer (React/JS, WebGL, D3.js) – To build a fully interactive, high-performance UI.
• Backend Developer (Python/Node.js, APIs, cloud computing) – To handle all server-side logic and data connections.
• Data Engineer (SQL, NoSQL, Power Query equivalent) – To design the data processing layer that replaces Power Pivot.
• Cloud & DevOps Specialist (AWS, GCP, scaling & optimization) – To manage hosting, performance, and real-time collaboration features.
• Graphics/Rendering Expert (3D & Custom UI/UX in web) – To develop the custom charting & rendering engine.
• Project Manager – To keep everything aligned across multiple disciplines.

A 6–8 person team working for 2.5–3.5 years at $125–$175/hour per expert would cost somewhere between $1.8M – $3M.

Why Excel is still the best choice

Yes, building this in Excel is insanely difficult and would be insanely expensive if one were to hire a team to do it.

However, staying in Excel also means we can:
✅ Leverage its built-in power pivot engines (instead of creating our own)
✅ Use its existing data-handling capabilities (instead of building Power Query from scratch)
✅ Focus purely on visuals, customization, and performance instead of reinventing the entire wheel

Even though this project will take "quite some time" to perfect, especially as a solo project, the Excel route is still the fastest way to get to the final product—without needing a multi-million-dollar team.

Frameworks

Before we get into the specifics, let’s take a step back and talk about what a framework actually is.

Imagine you’re building a city. If you just start throwing up houses randomly without roads, utilities, or a zoning plan, it’s going to be a complete mess. No one will know where anything is, traffic will be a disaster, and expanding the city later will be a nightmare.

Now, think of a framework as the city’s infrastructure—the roads, plumbing, electrical grid, and zoning laws that make everything work smoothly and efficiently.

• Without roads (structured logic), nothing connects properly.
• Without utilities (core functions), every building needs to generate its own power and water.
• Without zoning (modular design), expansion becomes chaotic and unmanageable.

A well-built framework doesn’t do the work itself—instead, it makes everything else easier, faster, and scalable.

Most Excel-based projects don’t have real frameworks. They’re just a bunch of macros and formulas slapped together, which might work in small-scale solutions but completely fall apart in a large, high-performance system like this.

We’re not making that mistake. If we want speed, modularity, and long-term maintainability, we need to build a structured foundation first.

Now, let’s break down the key frameworks we need to create.

The Core Frameworks

In total, there will be a ton of different frameworks, but the six most critical ones are:

1. Graphics Framework

Handles everything visual—shapes, colors, gradients, shadows, 3D effects, positioning, layering, and rendering.

The challenge? We need a framework that allows maximum customization while still being compact and efficient. There’s no point in having extreme flexibility if it means writing 100 lines of code just to draw a single rectangle. The goal is to make the system powerful but intuitive, so it doesn’t become a nightmare to work with.

2. Button Automation Framework

This controls all interactive UI elements—buttons, toggles, dropdowns.

Since I’m a one-man team, I don’t have the luxury of hardcoding every button manually (like most web developers do). Instead, I need a fully automated framework that:

• Manages button hierarchy dynamically
• Handles UI changes on clicks automatically
• Routes actions without requiring manual intervention

Everything needs to self-organize, meaning that once I define what a button does, the framework should handle everything else—from its positioning and state changes to the events it triggers.

3. Charts Framework

The way I’m structuring this framework is closer to a graphic design system than a typical charting engine (think of Photoshop and you get the idea). Instead of thinking of charts as static objects, I see them as collections of dynamic shapes that react to data inputs.

This will take a hell of a lot more effort to build, but in the end, it’s the only way to get true customization without being held back by Excel’s limitations.

4. User Forms Framework

It’s a shame that Excel doesn’t allow embedding interactive elements directly on the sheet—everything has to go through User Forms, which still look like something out of Windows 95.

That’s unacceptable. If we want this to feel like a real BI tool and not a 90s relic, this framework is mandatory.

5. Data Processing Framework

This framework ensures that data flows efficiently, handles large datasets without lag, and integrates seamlessly with external sources.

6. Filtering Framework

This framework allows real-time, multi-level filtering, letting users drill down into their data without performance issues.

Final thoughts

As you can probably tell, this isn’t just another Excel project. What we’re building here goes far beyond standard VBA development, and the amount of planning and engineering required is on another level.

A project like this can’t be done with just scattered macros and formulas—it needs proper frameworks to handle graphics, automation, data processing, and user interaction. And while it would cost millions to hire a team to build this, I’m tackling it solo—which means the frameworks need to do a lot of the heavy lifting.

Next time I will cover the topic "Why don't you just write it with an AI?"