How to Propose a Data Stack

Quick answer: Write the data stack proposal for the person who signs off: the business goal, a few options in a table, a cost table that splits one-time from recurring and licenses from people, a phased timeline with a cushion, and one clear ask. Then rehearse it, park the nerdy details in an appendix, and ask for feedback.

You’ve spent a bunch of time figuring out the best data stack for your company. It was hard work, and occasionally it was frustrating, but mostly it was fun.

Now for the un-fun part of the process: putting together a proposal to convince your Higher Ups to let you build your solution.

One of the reasons this may not be your idea of fun is that you aren’t comfortable creating what is essentially a sales pitch. After all, you’re an analyst, not a salesperson.

In this article, I’ll walk you through how to create a proposal that will convince the folks holding the purse strings to let you build the data stack that will help your company thrive.

Since I first wrote this, usage-based bills, build-vs-buy staffing totals and AI asks have complicated the money conversation, so I’ve added proposal and cost templates you can steal.

Refresher: What is a data stack?

Before we explore what makes for a good data stack proposal, let’s take a beat and make sure you’re clear on what a data stack is. You may only have a rough idea what folks mean when they use that term, not surprising given that definitions differ.

The idea of a “stack” comes from the software world. When web developers talk about their “software stack” or “solution stack,” for example, it’s shorthand for describing the set of tools or components that are the foundation for building their solution, e.g., the operating system, web server, database, and programming language or framework. A data stack is the same idea, only instead of building a website you’re creating an analytics solution.

While not everyone uses the term “data stack” the same way, most agree a working analytics solution in 2026 is built from these layers:

• Ingestion (ELT): how will you get data out of your apps and databases and into one place? Most teams buy ELT connectors (Fivetran, Airbyte) instead of writing their own.
• Data storage: where will you store the data and how? Typically this part of the stack is a cloud data warehouse or a lakehouse that can handle gobs of data.
• Transformation: what tools, languages, and/or frameworks will you use to clean up the data and transform it so it’s easy to analyze? Today that usually happens inside the warehouse, often in dbt.
• Data analysis and the semantic layer: what BI tools, reporting tools, and other analytics tools will you and other staff in your company use to find actionable insights in the data? The semantic layer gives “revenue” one definition every dashboard shares.
• Reverse ETL (optional): will you push cleaned-up data back into tools like the CRM? See reverse ETL.
• AI/LLM access (optional): will people ask the data questions in plain English, through a chat assistant?

Each layer can mean another vendor, contract and cost line. If I can’t justify it in two sentences, I cut it before the CFO does.

Understanding your audience

One mistake analysts often make before they start writing a data stack proposal is that they forget to ask a simple question: who’s the audience for their proposal?

A proposal isn’t an analysis, it’s a tool for making a sale. And it’s hard to make a sale if you don’t understand your audience.

A data stack proposal isn’t an analysis, it’s a tool for making a sale. 

For example:

• Is your audience primarily your CTO, who wants a deep dive on the technical details? Or is it your company’s founder, who just wants to know the bottom line and the ROI?
• Or is it your CFO, who skips to the cost section, wants the bill if usage doubles, and compares your proposal against doing nothing?
• Does the person or people you’re trying to convince want just your proposed solution? Or do they want to choose from several options?
• Does your audience think in PowerPoint slides, or is a crisp Google Doc the way to go?

So before you start cranking out your proposal, take just a few minutes to ask your manager:

• Who do you and/or your manager need to convince with this proposal?
• What does your audience expect in a proposal? And what are their preferences and pet peeves when it comes to proposals?
• Is the company in growth mode or cost-cutting mode? Your proposal can read as an investment or just another cost.

If you’re thinking, “Do I really need to waste time thinking about people’s stupid pet peeves and pointless personal preferences,” consider this: You’re going to be living with whatever decisions they make, including how generous or stingy the budget is for your data stack, for a long time. Isn’t it worth spending a few minutes now to get the best possible shot at getting the answer you want?

Components of a great data stack proposal

While what counts as a good proposal will differ depending on the audience, odds are you’ll need most of the following components.

Your (company’s) goal and how your data stack helps achieve it

Before you began working on your proposal, at some point your company (hopefully) came to at least a rough agreement about the kind of analytics culture you’re trying to create, e.g., to what extent you’re going to follow a self-service strategy. In the proposal, you’ll need to:

• Briefly summarize these high-level decisions
• Explain how the data stack you’re recommending will operationalize those decisions

You’ll also want to take any gauzy expectations that were implicit in that high-level conversation and flesh them out. Of these expectations, the most important is scope, i.e., what you are and are not promising to accomplish.

Say whether AI chat is included or comes later, after you’ve cleaned and modeled the data and agreed on metric definitions.

Options and your recommendation

Next you’ll want to either describe your proposed solution or present several options and explain which one you think is the best fit for your company.

Which approach should you choose? It depends on several factors:

• If there is only one even remotely sensible answer, that’s all you need to cover.
• If it’s a pretty close call, it’s usually a good idea to lay out the options.
• If there are objections you know you’re going to need to address, offering multiple options can be a good way to do it. For example, if one of the Higher Ups is going to push you on why you aren’t choosing a free solution, lay it out as one of several options in a way that highlights why you don’t think it’s a good fit for your company.

When describing options and your proposed solution, how much detail should you go into? It depends on what your audience expects and what you need to explain to “close the deal.” Regardless of how much detail you end up deciding you need, if you are presenting several options you should consider summarizing them in a table. Design the table so it’s crystal clear what the trade-offs are and why your proposed solution is the best option.

In fact, it might be worthwhile to begin your research on the proposal by mocking up a table. It can be a useful way to make sure you don’t go down the rabbit hole on too many details and to keep your research focused on coming up with an answer you can clearly and succinctly explain.

Include staff time for building in-house and for doing nothing. Check existing cloud contracts for savings or faster approval. Run a bake-off if needed, then fill in the options template below.

What it’ll take to implement your proposed data stack

You will also need to explain how you will go about implementing your proposed solution and provide a rough timeline.

A few pointers:

• Add in a cushion. It’s easy to get too optimistic about how long your shiny new solution will take to get up and running. Make sure you give yourself room for unexpected roadblocks and changing circumstances.
• Break the timeline into iterations or a roadmap. In fact, it may be useful to briefly sketch a roadmap of where your company’s analytics adventure will take it, with just the first phase or two covered by this proposal. This can be a particularly useful trick if you’re worried about ensuring the project has a reasonable scope and need to set realistic expectations about what you can accomplish.
• Budget weeks for security and legal review. Allow roughly 2 to 8 weeks; negotiating a data processing agreement from scratch can add 2 to 4 weeks. Start in parallel and request SOC 2 Type II or ISO 27001 documentation upfront.
• Ask for phase one, not the whole roadmap. Define its cost and success criteria, such as finance using the weekly revenue dashboard instead of rebuilding it. Gate phase two with a proceed, adjust or pause checkpoint; use a proof of value checklist.

How much your proposed data stack will cost

When explaining how much your proposed solution and any alternatives will cost, make sure you break it down by:

• Initial and ongoing costs
• Money and staff time, which should include time spent getting trained up

And as you did when providing a timeline, add in a cushion. Nothing ever goes as planned.

Usage-based lines aren’t seat fees. BigQuery on-demand lists about $6.25 per TiB scanned in US regions, with the first 1 TiB each month free. Check the pricing page for your region. Fivetran bills Monthly Active Rows per connection, with a $5 base charge per connection between 1 and 1 million MAR, per Fivetran’s pricing docs.

Use current queries or a pilot to estimate low, expected and high usage. Budgets and alerts warn you; auto-suspend and query quotas constrain usage.

Here’s my starting cost table; put the assumptions in the appendix.

Line item	License or people	Pricing unit	One-time	Recurring (per month)	Low to high (per month)	Who pays in time
Ingestion (ELT)	License	Monthly Active Rows per connection (Fivetran) or credits or a flat plan (Airbyte Cloud)				Engineer: setup, then fixes
Warehouse or lakehouse compute	License, usage-based	Credits (Snowflake), TiB scanned or slot-hours (BigQuery), RPU-hours (Redshift Serverless), DBUs (Databricks)				Whoever sets budgets and alerts
Warehouse storage	License, usage-based	Per TB per month				n/a
Transformation	License	Per developer seat, or free (dbt Core)				Analysts writing models
BI and semantic layer	License	Per user by role, or a flat monthly plan				Analysts, plus staff getting trained up
Reverse ETL (optional)	License	Check the vendor’s pricing page				Analyst
AI/LLM access (optional)	License	Per seat or per token				Analyst curating metrics
Implementation	People	Hours times loaded hourly rate		n/a	n/a	You, engineering, IT
Security and legal review	People	Weeks of calendar time		n/a	n/a	Security, legal, procurement
Ongoing maintenance	People	Share of one person’s time	n/a			Analyst or data engineer
Cushion	Both	Percent of the subtotal				n/a
Total

People are usually the biggest cost, so compare build-vs-buy totals, not license fees, and choose a cushion you can defend in one sentence. Use the warehouse pricing playbook for billing units and surprises.

Objections you need to address

While conducting the research for the data stack proposal, come up with a list of reasons why the people who need to sign off might balk at doing so. And then make sure that somewhere in your proposal, you address your audience’s biggest concerns.

For example, suppose you’re pretty sure your CFO is going to ask, “Why can’t we just keep doing this in spreadsheets, or point ChatGPT at the database?” Make sure your proposal has a crystal clear answer to that question. And don’t bury that answer in a paragraph where it would be easy for them to overlook as they are quickly skimming through the document; make sure it stands out.

Here are the questions I’d expect in the 2026 money conversation, with the short answers I’d have ready:

• “Why can’t we just use spreadsheets?” A shared model prevents conflicting revenue figures and preserves history.
• “Why not use the BI tool’s own connectors?” Separate dashboard pipelines can scatter and duplicate cleanup logic.
• “Why can’t we point ChatGPT or Copilot at the database?” Raw schemas miss business rules; start with governed metrics.
• “What if the bill spikes?” Show ranges, budgets, alerts and query quotas; resource monitors cap compute, not storage.

How to structure and deliver the proposal

Now you’ve got some ideas about what should go into the proposal. What should it look like?

Format your proposal to fit your audience

If your audience expects slides, do a slide deck. If they like short Google Docs, write a short Google Doc. Whatever your audience prefers, that’s what you want to deliver, because, again, your proposal isn’t an analysis, it’s a sales tool.

Ditto for the language you use. If your proposal fits the way your company thinks and talks, you may improve the odds that you’ll get a green light.

Fit your proposal to the process

It’s also useful to know how you are going to deliver the proposal. Let’s say the process works like this:

1. You’re going to do a detailed walk-through with your boss.
2. Once they sign off, you’ll have a 15-minute meeting with some combo of C-suite stakeholders (CEO, CTO, COO, CFO).

You might decide to create a one-page executive summary, a table summarizing the options and your recommendation, plus a deeper dive. That way, you’ve got all your bases covered with both audiences.

Make sure you understand the approval process before you spend too much time on your proposal. Otherwise, you could end up with a proposal that is great for your boss but doesn’t really work for the people who make the final decision.

Make it skimmable

For almost any audience, you can’t go wrong if you make it easy to skim your proposal.

Headings, bullets, bolding. They are all your friends in the battle to get a thumbs up on your proposal. Tables are good too.

Why is it useful to create a skimmable proposal?

The one thing you can be pretty sure of is that some of the most important people who have to sign off on your proposal are folks who spend a lot of time in meetings. In fact, they may spend most of their days in meeting after meeting.

And while this proposal is your baby, it’s probably one of many proposals they will have to deal with this week.

So create a proposal that requires as little effort as possible to understand.

Early on, practice explaining your proposal

As soon as you have a draft of your proposal, do a quick run-through where you pretend you are pitching it. Your dog won’t mind and that practice could pay off big time.

Why? You’re going to use your proposal to tell a story that convinces the Higher Ups to sign off. So, practice telling your story.

If you do, you’ll discover which parts work smoothly, what additional details you might need to add to the proposal, and what needs to get reworked.

This strategy is particularly useful if at some point you’re going to have to briefly present your proposal. The time to discover that your proposal doesn’t quite work when you’re explaining it is not when you’ve got 10 minutes with your CEO.

Practice explaining what the monthly bill looks like if usage doubles and what the CFO gets by funding only phase one.

Stuff the rest into an appendix

As you’re reading this article, perhaps there’s a voice in your head that’s saying, “If I follow your advice my proposal won’t have all of the nitty-gritty details the Higher Ups need to understand before they sign off. There’s no way I can capture the subtlety and complexity of the solution I’ve crafted in the ridiculously small amount of space that Higher Ups are giving me.”

I feel you.

Here’s my trick for dealing with the nerdy details I wish I could put into a data stack proposal when I’ve been told it can only be a few pages long: I put everything else I want to cover in one or more appendices.

That way:

• I can let go of any frustrations this process is inflicting on my Inner Data Nerd.
• If the Higher Ups really do need to know more details, I’ve got it written down. Then if I get questions about it during my presentation, I’m good to go.
• Even if I don’t end up referring to the appendix or appendices during the presentation, odds are at some point during the project, I’ll be glad I pulled together these details.

Ask for feedback after presenting your proposal

There’s a good chance this isn’t the last time you’ll need to put together a proposal.

So once you’ve presented your proposal, at some point in the next few days, take a minute to ask some of the folks who saw your presentation what worked for them and what didn’t. At the very least, you’ll learn some useful lessons that will help you do a better job next time…and that could help you level up to the managerial track.

But perhaps more importantly, by showing interest in what the Higher Ups think, you’re demonstrating respect. And in doing so, you’re helping to build the trust you will need as you build out your analytics solution.

Many analysts don’t bother to do this. So make yourself stand out by following up with at least some of your audience and asking for feedback.

A one-page data stack proposal template

Hand the C-suite this page, with the cost table and details attached. Fit their format, but keep this decision order.

1. Summary. Use three sentences: business problem, recommendation, requested approval.
2. Options. Mark your pick; make the trade-offs visible.
3. Cost. Give year-one and monthly ranges; attach the cost table.
4. Timeline. Show dated phases, security review and cushion.
5. Risks and mitigations. Limit to three; pair bill spikes with alerts, low adoption with training.
6. The ask. Specify money, people, time and the next decision date.

Mock up this options table before researching:

	Option A: managed stack (recommended)	Option B: build in-house	Option C: do nothing
What it is	Bought connectors, a cloud warehouse, dbt, one BI tool	Pipelines our engineers write, schedule and maintain	Spreadsheets and BI exports, as today
Year-one cost	[$] to [$]	[$] to [$], mostly salaries	[$] in staff hours spent reconciling numbers
First dashboard leadership uses	[x] weeks	[x] months	n/a
Main risk	Usage-based bill grows with adoption	Pipelines break when the person who built them leaves	Conflicting numbers keep reaching the board

“Approve phase one: [$] over [x] months and [x] hours a week of analyst time, to deliver [the weekly revenue dashboard finance builds by hand today]. If we hit [success criteria] by [date], I’ll come back with the phase two numbers.” Write that ask last, once you can explain exactly what their money buys.

Conclusion

Writing a data stack proposal isn’t fun. But if you do it right, it could make the difference between suffering through maintaining a duct tape solution and getting the resources you need to help your company thrive.

Where to next: Use the data warehouse guide for CTO background, the warehouse pricing playbook for usage rows, and data warehouse comparisons and ETL tools for options. For BI, check Tableau, Looker and Metabase; for transformation, dbt. I’d keep those tool details behind the one-page ask.

FAQ

What should a data stack proposal include?

Include a summary, options with your recommendation, costs, a phased timeline, risks with mitigations, and one clear ask. I’d use the one-page template above, attach costs split by timing and people versus licenses, include usage ranges and a cushion, and put details in the appendix.

How do I estimate a usage-based warehouse bill for a proposal?

Identify the billing unit, estimate volume from current queries or a pilot, and show low, expected and high costs. Name the controls alongside the estimate: budgets and alerts flag spending, query quotas constrain usage, and Snowflake resource monitors cap compute credits but not storage.

Should my proposal recommend building or buying the stack?

Compare both with people included, since staff time is usually the biggest cost. Building makes sense when the stack is part of your product or a long vendor security review makes buying slower. Otherwise I favor buying for a small team, provided the totals support it.

Should I ask for AI tooling in a data stack proposal?

Yes, as an optional line if leadership wants it, but fund governed metrics first. Thoughtworks’ Technology Radar warns that raw-schema text-to-SQL gets answers wrong when business rules live outside the schema, so start with a semantic layer for executive metrics. Keep AI separate so cutting it doesn’t sink the proposal.