What a Fixed-Price Build Actually Looks Like
People hear "Excel build" and picture someone writing formulas for a few hours, but the gap between that assumption and reality is worth walking through in detail. I want to describe a recent project from start to finish, not the polished case study version, but the actual sequence of decisions that turned a messy situation into a working tool.
What I walked into
The client runs a small hardware store with about a dozen employees. They had five spreadsheets: one tracking daily sales by register, one tracking inventory counts updated manually every week or two, one tracking vendor costs and purchase orders, a payroll summary their bookkeeper maintained, and a tab inside the sales file where someone had started building what they called a "dashboard," which was really just a few totals and a chart copied from a YouTube tutorial.
None of these files talked to each other. The sales file did not reference the inventory file, the vendor cost sheet had no connection to the sales data, and the payroll summary existed entirely on its own. Every month, the owner spent a few hours pulling numbers from each file into a summary email for their business partner, and that email was the closest thing they had to a performance report.
The numbers themselves were not wrong, and the formulas in each individual file did what they were supposed to do. But the outputs were not telling them anything useful about how the business was actually performing, because each file only showed one slice of the picture.
The scoping conversation
When they reached out, the request was straightforward: "We need a better dashboard." Most people start there, knowing the current situation is not working and assuming the fix is a nicer-looking version of what they already have.
The first thing I did was ask what decisions they make on a recurring basis, not what data they collect, but what choices they face every week or every month that the data should support. Not only the decisions, but also what those decisions impact and how important those impacts are to them. Their answers came down to a handful of things: which product categories were moving and which were sitting on shelves, whether margins were holding or eroding as vendor costs shifted, and whether the labor cost as a percentage of revenue supported hiring another part-time employee they had been discussing.
Five spreadsheets, but ultimately answering three real questions. That gap is where most small businesses live, collecting far more data than they use and applying none of it in a structured way to the decisions that actually matter.
No cross-file visibility
KPIs tied to real decisions
What I scoped and priced
Given the stated desire to remain in Excel, I proposed a single workbook with three components: a data tab where they would enter weekly sales, inventory, and cost figures in a standardized format; a settings tab where they could adjust parameters like target margin thresholds and labor cost benchmarks; and a dashboard tab that would calculate and display their KPIs automatically.
The KPIs were specific to their questions: revenue by product category with a trailing four-week trend, gross margin by category compared against their target threshold, labor cost as a percentage of revenue shown monthly, and inventory turnover by category. I priced the project as a fixed-fee deliverable, scoped before any build work started, so they knew the cost, the timeline, and exactly what they would receive before I wrote a single formula.
The build itself
The build took about a week of active work, and most of that time was not spent on formulas. It was spent on structuring the data input so that the dashboard could do its job reliably.
This is the part commonly underestimated. The reason their original spreadsheets were not useful as a system is that each one stored data in a format designed for entry, not for analysis. The sales file organized transactions by date and register, the inventory file organized counts by aisle, and the vendor cost sheet organized purchases by supplier. Each structure made sense for the person entering the data, but none of them made it easy to ask cross-cutting questions like "what is our margin on power tools this month?"
The new workbook standardized how the data was organized so that every KPI could pull from the same structured source. Category definitions were consistent across revenue and cost data, time periods aligned, and cost figures mapped to the same product groupings as sales figures. That alignment is what makes a dashboard actually work, not the charts or the conditional formatting, but the architecture underneath them.
What changed
They went from spending hours assembling a monthly summary email to opening one file and seeing their KPIs updated as soon as the week's numbers were entered. The dashboard did not just look better than the old setup; it answered different questions, questions that connected directly to decisions they were already making.
Within the first month, they noticed that one product category had a margin nearly 10 points below their target, something they had not caught because the old files tracked revenue and costs separately. They adjusted pricing and vendor terms for that category, and that single insight more than covered the cost of the project.
They also paused the part-time hire they had been discussing. The labor cost percentage showed they were already above their benchmark, and the revenue trend did not justify adding headcount yet. Before the dashboard, they were making that call based on how busy the store felt during peak hours. After, they were making it based on numbers that updated every week.
Why fixed pricing matters here
If I had billed this project hourly, the incentive structure would have worked against the client. The faster I work, the less I earn; the more efficient my approach, the less I get paid. That misalignment hurts both sides of the engagement.
Fixed pricing means I scope the work, name a number, and deliver. If I find a faster way to build something, I benefit from that efficiency and the client still gets the same result at the same cost. For the client, it removes the anxiety of an open-ended engagement: they knew what they were paying before work started, there was no discovery phase, no change-order negotiation, and no surprise invoice at the end.
The tool is just the container
The deliverable was an Excel workbook, but the actual value was in the decisions that preceded the build: which questions matter, what data supports those questions, and how to structure everything so the answers are visible without manual assembly every month. Any competent Excel user can write a SUMIFS formula or build a chart, but the part that requires experience is looking at a small business with five disconnected files and knowing which numbers to pull forward, how to refine them so they reveal something useful about the underlying process, and how to present them in a way that changes behavior.
