From Sketch to Production Software

The Problem

A major regulatory shift was coming. New Time-of-Use billing structures were about to make the client's existing sales math obsolete overnight — the way they'd always calculated value for customers would no longer hold up.

The sales team had no reliable way to model customer financials under the new rules, size systems accurately, or generate proposals with confidence. Every deal carried uncertainty. Leadership didn't have a solution — they had a problem, a deadline, and a hand-drawn sketch from the Director of Engineering.

No off-the-shelf product covered it. The vendors in the space were all solving the old problem — the pre-regulation math — and none of them moved fast enough to matter against the deadline. The scenario was too specific to this business, this market, and this incoming regulation for a generic tool to fit. If the client wanted software that actually matched their situation, someone was going to have to build it. And building custom software on a regulatory deadline is exactly the kind of project that goes badly without the right ownership.

What We Did

We started by proving the logic before building anything expensive. A working spreadsheet prototype validated the core financial model under the new rate structures — cheap to build, fast to change, and enough to confirm the concept held up before a single line of production code was written. If the model was going to be wrong, we wanted to find out in a spreadsheet, not three months into a development cycle.

With the logic proven, we designed the full product architecture and assembled a development team to build it. This is the part that separates a working prototype from a shipped product, and it's where most build efforts stall: someone has to translate a validated idea into technical requirements a development team can actually execute against. We owned that translation and everything downstream of it — turning business needs into written tickets, directing the team, managing delivery, and shipping.

The result was an end-to-end pre-sale platform:

• Customer financial modeling under the new rate structures

• System sizing and design

• Quoting and proposal generation

• Native integrations with the client's core design and CRM systems

We drove Agile development cycles across multiple years with full Scrum ownership: sprint planning, backlog grooming, QA, release management, and stakeholder alignment at every stage. The people writing the code were a development team we directed; the bridge between what the business needed and what the developers built was us.

The Outcome

The platform became the backbone of the client's sales process and stayed there for years, evolving through continuous delivery as the market and the regulations kept shifting. Because it was built for this business specifically, its flexibility unlocked offerings no off-the-shelf product could touch: in-house financing, battery-only sales, and complex non-export system configurations that competitors simply couldn't quote. Each of those became a line of business a generic tool would have quietly foreclosed.

The sales team went from walking customers through a bare spreadsheet to presenting inside a polished, customer-facing application built specifically for their business — a change in credibility as much as capability. More importantly, the tool boosted the team's confidence in what they were pitching. What started as a hand-drawn sketch and a blank page became a durable competitive advantage that carried the client through one of the most disruptive regulatory shifts their market had ever seen.

Why This Matters for Your Business

The specifics here are solar and regulation. The capability is broader than that.

Every growing business eventually hits a process that no software vendor has built for. The usual response is to bend the business around a tool that almost fits, or to keep limping along in spreadsheets. There's a third option — but it only works if someone can do all of it: understand the business deeply enough to define what's needed, decide honestly whether to build or buy, and then actually lead the build.

Prove the logic before you fund the build. A spreadsheet prototype cost almost nothing and de-risked a multi-year software investment. Most failed custom-software projects skip this step and discover the flaw after the money's spent.

The hard part isn't the code — it's the translation. Turning a sketch into tickets a development team can execute is a specific skill. It's the gap where most build projects break down, and it's the gap we're built to fill.

Custom isn't always the answer — but sometimes it's the only one. Off-the-shelf couldn't do in-house financing, battery-only sales, or non-export configs. Those became the differentiators. When the thing that makes you competitive doesn't exist yet, buying won't get you there.

From requirements to production, we own the whole path. That's rare in a fractional partner, and it's exactly what a build-vs-buy decision needs sitting on your side of the table.