Why We Build Before We Pitch
The case for showing up with something wrong instead of nothing at all
A few weeks ago, we wanted to explore opportunities in the battery storage industry.
We knew almost nothing about BESS. We didn't have contacts. We didn't have credentials. We had no business being in the room.
So we did what we always do: we built something.
Not a pitch deck. Not a proposal. Not a scope of work with timelines and estimates.
We built three working prototypes. Then we sent a 2-minute video saying, essentially: "We tried to understand your world. Here's what we made. What did we get wrong?"
This is how we approach every new engagement. And it works far better than the traditional consulting playbook.
The pitch-first trap
Here's how most consulting engagements start:
- 1Initial call: Learn about the client's needs
- 2Proposal: Write a document describing what you'd build
- 3Negotiation: Scope, timeline, price
- 4Kickoff: Finally start building
- 5Discovery: Now actually learn the domain
- 6Delivery: Hopefully something useful, eventually
This process optimizes for risk mitigation. Nobody commits until everything is specified. Nobody builds until contracts are signed.
The problem: you're negotiating over something that doesn't exist yet.
The client is evaluating your proposal, not your work. Your credentials, not your capability. Your words, not your judgment.
And you're estimating effort for a problem you don't fully understand, in a domain you haven't deeply explored.
Everyone is guessing.
Our approach: build first, ask second
Here's what we do instead:
- 1Learn: Research the domain intensively
- 2Build: Create something. Rough, incomplete, probably wrong
- 3Share: "Here's what we made. What did we get wrong?"
- 4Learn: Their feedback teaches me what actually matters
- 5Refine: Now I know what to build
The conversation changes completely.
Instead of: "Do you think you can help us?"
It becomes: "Oh interesting, you built X. But actually, our problem is Y."
Now we're talking about something real.
What we built
For the BESS exploration, we built:
1. A battery physics simulator
Interactive, real-time. Shows power flows, state of charge, thermal dynamics, degradation.
We had to learn how batteries actually work to build this. The physics are embedded in the code.
→ Read about the physics model2. A partner revenue calculator
What does a solar farm owner see when a BESS company proposes co-location? Revenue share, 15-year projections, market scenarios.
We had to learn the business model to build this. The economics are in the assumptions.
3. An operations dashboard concept
Portfolio to cell. What does an asset manager need to see? What does a technician need?
We had to learn the operational workflows to design this. The hierarchy reflects how people actually work.
→ Read about the dashboard design4. A software landscape map
What software do they need across sales, operations, and partner relationships? I mapped the landscape to understand where software could help.
Open to feedback on what I got wrong, what's missing, and what doesn't matter.
None of these are finished products. They're not meant to be.
They're conversation starters. They're proof of engagement. They're mistakes worth correcting.
Why prototypes win conversations
1. It demonstrates capability, not credentials
Clients don't really care about your resume. They care about whether you can solve their problem.
A working prototype, even a rough one, shows more than any credential ever could. It shows you can ship. It shows you can think. It shows you can learn.
2. It earns attention
Everyone gets pitch decks. Almost nobody gets working software.
When you show up with something built, you stand out. You've already invested in the relationship. That asymmetry creates goodwill.
3. It accelerates learning
Building forces you to confront what you don't know. You can't fake a simulation. You can't handwave a calculation.
Every bug, every gap, every "I'm not sure how this should work": that's learning.
4. It de-risks the conversation
The client isn't evaluating a hypothetical. They're reacting to something concrete.
"I like X but Y is wrong" is infinitely more useful than "Sounds good, let's discuss scope."
5. It inverts the power dynamic
Traditional consulting: the client has the problem, you have (maybe) the solution. You're auditioning.
Build-first: you've already created value. You're offering, not asking. The question becomes "Is this useful?" not "Can you do this?"
The risks aren't what you think
"What if you build the wrong thing?"
You probably will. That's the point.
A wrong prototype generates useful feedback. A wrong proposal generates polite rejection.
We'd rather show you something wrong than describe something right.
"What if they steal your ideas?"
Ideas aren't scarce. Execution is.
If someone can take your prototype and build the full solution without you, they were never your client anyway. And they probably won't, because the prototype is 10% of the work.
"What if you waste time?"
Building is learning. Even if this specific opportunity goes nowhere, you've developed domain expertise, reusable components, and portfolio pieces.
The simulator we built for BESS will help us understand any energy storage project. The dashboard patterns apply to any operational domain.
Nothing is wasted.
How to do this in days, not months
1. Timebox aggressively
Don't spend months. Spend days.
The goal isn't a polished product. It's a concrete artifact that demonstrates understanding and invites feedback.
2. Document your assumptions
Make it easy to critique. List what you assumed. Cite your sources. Call out what you're uncertain about.
"We used industry benchmarks. We'd need your actuals to make this real" is an invitation, not an apology.
3. Frame it humbly
This is not: "Here's what I think you need."
This is: "Here's what we built to understand your world. What did we get wrong?"
You're asking for guidance, not approval.
4. Make it interactive
A static PDF doesn't invite engagement. A clickable prototype does.
Let them explore. Let them break it. Let them say "What if we tried..."
5. Ship it
Don't wait until it's perfect. Don't polish endlessly.
The goal is conversation, not completion.
The real reason this works
This approach only works if you genuinely enjoy building. If prototyping feels like a cost you're paying to win business, it will show.
For us, building is thinking. We understand things by making them. The prototype isn't a marketing tactic. It's how we learn.
That authenticity matters. Clients can tell the difference between "we built this to impress you" and "we built this to understand you."
The second one earns trust.
Skip the proposal. Build something instead.
Next time you're exploring a new client or industry, try this:
- 1.Build something small. Days, not weeks.
- 2.Share it with: "What did I get wrong?"
- 3.Watch the conversation change.