Jack Crabtree, Founder · 4 August 2026 · Case study

Overview

DualFuel is a building services company operating in New York City, running its commercial pipeline through HubSpot. The problem we were brought in to solve wasn’t a broken CRM; HubSpot itself was fine. The problem was the layer between HubSpot and the leadership team’s actual morning routine, which relied on someone manually pulling numbers into a report before anyone senior looked at the pipeline. We built a revenue cockpit that removes that manual step entirely, and we’re describing it as a small, focused build, because that’s what it was: not every engagement needs to be a multi-month platform rebuild to be worth doing properly, and this one is a useful example of that on its own terms.

The Problem

Before this build, pipeline visibility for DualFuel’s leadership team depended on someone assembling a report from HubSpot data, usually by hand, on some regular cadence. That’s a common pattern, and it’s not a sign of a badly run business; it’s simply what happens when reporting is treated as a periodic task rather than a live view. The cost of that pattern is subtle but real: the report leadership looks at is always at least a little stale by the time they see it, the person assembling it is spending time on manual data pulls instead of higher-value work, and if that person is out sick or busy on a given day, the report sometimes just doesn’t happen. None of that is dramatic on its own, taken in isolation. Compounded over a year, it means a leadership team making decisions on data that’s never quite current, and a recurring task that quietly consumes hours that could go elsewhere.

There’s a broader pattern here worth naming, because we see it often enough that it’s not specific to DualFuel: a business’s CRM is genuinely well set up, the sales team uses it correctly day to day, and the gap isn’t in the CRM at all, it’s in the last mile between the data existing and a decision-maker actually seeing it in a useful form. That gap tends to get patched with a person rather than a system, because hiring or tasking someone to pull a report feels like the fast fix when the alternative looks like a CRM project. The trouble is that a person-shaped patch scales badly: it depends on that person’s availability, it doesn’t get faster as the business grows, it adds a step of manual transcription where errors can creep in unnoticed, and it’s the first thing that breaks down under any change in headcount or shifting priorities.

Our Solution

We built a revenue cockpit as a lightweight web application on Vercel, using Vercel KV as the data layer, reading directly from HubSpot rather than from a manually maintained export. The design goal was specific: leadership should be able to open one URL each morning and see pipeline visibility that reflects what’s actually in the CRM right now, not what it looked like whenever someone last ran a report. We kept the scope deliberately narrow. This wasn’t an attempt to rebuild DualFuel’s CRM or restructure how the sales team works; it was a purpose-built read layer on top of the CRM they already use correctly, solving the specific gap between “the data exists in HubSpot” and “a person can see it without asking someone else to pull it for them.”

That narrowness was itself a deliberate choice, not a limitation we ran out of time to address. A revenue cockpit that tries to be everything, editable records, workflow triggers, a full admin interface, ends up being a second CRM the team has to maintain in parallel with the first one. We built a read-focused view instead, so there’s exactly one place data gets entered and changed, which is HubSpot, and exactly one place leadership goes to see it clearly, which is the cockpit. Keeping those roles separate means the cockpit can never drift out of sync with the CRM in the way a parallel, independently-updated spreadsheet or dashboard eventually does.

We also thought carefully about who the cockpit was actually for, because a dashboard built for everyone tends to satisfy no one particularly well. This wasn’t a tool for reps to manage their own deals day to day; that’s what HubSpot itself is for, and duplicating that functionality would have added a second interface for reps to learn with no real benefit over the one they already use. The cockpit was built specifically for the view a leadership team needs, which is different in shape from a rep’s day-to-day working view: less granular on any single deal, more focused on pipeline shape as a whole, and structured around the questions a leader actually asks in a morning stand-up rather than the fields a rep fills in during a call.

How We Deployed It

Because the cockpit reads from HubSpot rather than owning its own copy of the data, the main engineering work was in getting the read layer right: querying the specific pipeline views leadership actually cares about, at a refresh cadence fast enough that the dashboard feels current without hammering HubSpot’s API more than necessary. We used Vercel KV as a caching layer between the two, so the dashboard loads quickly for the person opening it in the morning without every page load triggering a fresh, slower query against HubSpot directly. That’s a small architectural decision, but it’s the kind of thing that determines whether a tool like this actually gets used daily or gets opened once, judged to be slow, and quietly abandoned.

We treated load time as a first-class requirement rather than a nice-to-have, because the entire value proposition of this build was replacing a habit, the daily manual report, with a better one, opening a link each morning. A tool competing against a habit doesn’t get much benefit of the doubt: if the cockpit had been slow or unreliable in its first week, the leadership team would have reasonably gone back to asking someone for a report, and the build would have failed on adoption even if the underlying engineering was sound. We tested the dashboard’s load behaviour under realistic conditions before calling it done, rather than only in the fast, low-latency conditions of local development, specifically because that gap between “works for me” and “works reliably for the actual users” is where tools like this most often quietly fail.

We also made a deliberate choice about what not to build into the first version. It would have been possible to add historical trend charts, forecasting logic, or configurable views from day one. We shipped the core live-pipeline view first, got it in front of the leadership team, and treated anything beyond that as a decision to make based on how they actually used it, rather than guessing up front at features that might never get used. A small, focused tool that does one thing reliably beats a broader one that does several things adequately, especially for a team whose main ask was simply: let us see the pipeline without waiting for someone to send us a report.

The Outcome

The leadership team now opens one dashboard each morning, reading live from HubSpot, instead of waiting on a hand-pulled report. We’re describing that outcome plainly and qualitatively, because that’s genuinely what changed: a recurring manual task became a live view, and a report that was always somewhat stale became one that reflects the pipeline as it actually stands. There’s no locked percentage attached to this build, and we’re not going to invent one; the value here is in the removal of a daily bottleneck, not in a number we could measure against a baseline that never existed in the first place.

What we can say with more confidence is what this build represents as a category of work: a small, tightly scoped engagement that solved one real, specific friction point rather than a large platform rebuild pitched at solving everything at once. Not every business needs the second kind of engagement, and we’d rather scope a project correctly to the actual size of the problem than expand it artificially because a bigger engagement makes for a bigger number to put in a case study. DualFuel’s problem was specific and bounded, and the fix we shipped was scoped to match it precisely, not padded out beyond what the situation actually called for.

Related: RevOps Consultancy and CRM & HubSpot Consulting. More on the team behind this build: About Equanax.