Dre doesn't sign the contract. He decides whether Hannah ever hears about us. Build him a champion, not a deck.
Dre isn't the buyer. The CTO (Hannah Mertz) is the buyer, and Hannah will not give Nominal a second look until someone she trusts internally puts a recommendation in front of her with a specific ask. That someone is Dre. Don't pitch Dre. Equip him. The right outcome from this call is not 'Dre agrees Nominal is good.' It's 'Dre has a 90-second story he can tell Hannah in their 1:1 next Tuesday that ends in a question — should we run a 30-day pilot?' Everything in the conversation should be in service of building that 90-second story together.
What changed recently
Bench closed a $34M Series B on March 28, with their press release explicitly naming 'unit economics' as the area of focus for the new capital — a public commitment to improve gross margin. AWS bill for April (we have a directional estimate from one of their ex-employees, take with appropriate skepticism) appears to be in the $180–220K/month range. They migrated their fulfillment platform to EKS in Q4 last year and have been running multi-region since January, which typically means cost visibility has gotten worse before it gets better. Dre has commented twice on Hacker News in the last 30 days about Kubernetes cost allocation being 'unsolved at the team level.' That's our opening.
Company snapshot
Series B coffee subscription company — direct-trade beans, custom roast profiles, recurring monthly shipments. ~$72M ARR. ~140 employees, 38 in engineering. Eng stack: Go services on EKS, multi-region (us-east-1, us-west-2), Postgres on RDS, Snowflake for analytics, Stripe for billing, custom logistics platform integrated with their roaster network. Their differentiator is the roast-on-demand model, which means tight orchestration between order, roast, and fulfillment — and that orchestration is what's expensive to run.
Stakeholder profile
Dre Okonkwo · Director of Platform Engineering, 18 months at Bench. Came from Faire (3 years there in similar role). Reports to Hannah Mertz (CTO). Manages 9 engineers across platform, SRE, and developer tools. He is operationally credible inside Bench — engineers respect him, and Hannah lets him drive technical decisions in his domain. He is not a finance person. He's a platform person who's been handed a cost-visibility problem because no one else owns it. His Hacker News activity tells us he thinks about this at the architecture level, not the spreadsheet level — which is exactly Nominal's positioning.
What we know already
Introduction from a mutual contact (Reed Chen, who worked with Dre at Faire and now runs DevOps at a Nominal customer). Reed sent Dre our case study from his current company two weeks ago. Dre replied to Reed: 'looks interesting, will dig in.' That's our entire prior interaction with Dre. He accepted the call invite three days later. No prior conversation with Hannah. We do know from Reed's intro note that Hannah is 'cost-aware but not cost-obsessed' — meaning she'll listen to a well-framed case but won't go hunting for one herself.
Pain points
Kubernetes cost allocation at the team level
Dre's own public commentary names this as unsolved. AWS cost-allocation tags are not enough when a single namespace serves multiple product teams, which is Bench's situation.
Multi-region cost surprise after the January cutover
the move to us-west-2 was for latency, but the cost implications were not fully modeled and showed up in February's bill.
Series B mandate on unit economics
Hannah's pressure from the board to improve gross margin will land on infrastructure spend eventually. Dre is the one who'll be asked 'where can we cut without breaking things.'
No baseline for cost-per-order across the roast-on-demand pipeline
they can tell you AWS spend at the aggregate level, but not what it costs to fulfill a single subscription order. That number matters more after the Series B than before.
Questions to ask
- Q01When you posted on HN about Kubernetes cost allocation being unsolved — what would 'solved' look like for you? What would you want to be able to tell your team that you can't today?
- Q02Has Hannah brought up the unit economics piece to you yet, or is that conversation still upstream?
- Q03If you brought a cost-visibility initiative to Hannah this quarter, what's the bar she'd hold it to? What would make her say yes vs. defer?
- Q04Who on your team would actually use this day-to-day — and what's their current alternative? Is it Cost Explorer, is it a spreadsheet, is it Kubecost?
- Q05If we did a 30-day pilot scoped just to one of your product teams, what would 'this worked' look like for you, separately from what it would look like for Hannah?
Objections to expect
- PUSHBACK
We have Kubecost / OpenCost in the cluster already.
RESPONSECommon — those tools tell you what each pod cost; they don't tell you what each customer order cost across the pipeline. The differentiator is the full-stack attribution (compute + RDS + Stripe + Snowflake unified). Don't argue with Kubecost; position next to it.
- PUSHBACK
Hannah is the one who'd decide this, not me.
RESPONSETrue, and we're not asking him to decide. We're asking him to evaluate it well enough to bring an informed point of view to Hannah. Make that the explicit ask — 'I'm not asking you to buy; I'm asking whether this is worth Hannah's 30 minutes.'
- PUSHBACK
We're heads-down on platform reliability work, not cost work.
RESPONSEReframe: this is platform work, not finance work. Cost visibility is observability. Position it next to their existing reliability instrumentation, not next to their finance reporting.
- PUSHBACK
Send me a price list and I'll see if I can fit it in budget.
RESPONSEPremature — and if Dre is the one asking, that's a sign he's trying to deflect into procurement rather than evaluate. Push back gently: 'Happy to share pricing, but I'd rather first understand whether this is even worth your time. If it's not, the price doesn't matter; if it is, the price will be the easy part.'