Most founders look for easy markets with fast validation loops, but April CEO Ben Borodach picked the opposite: the US tax industry. It’s so regulated, only ~10 companies in history have gone through the process he willingly walked into.
In early 2025, April became the first new tax platform in over a decade and a half to receive authorization to file returns nationally.

April CTO Daniel Marcous and CEO Ben Borodach
In July, April announced a $38M Series B. To scale, Ben and co-founder Daniel Marcous built what he calls a compound startup — a company that can’t be reduced to a single wedge product because the problem itself is made of interlocking layers: infrastructure, compliance, data, distribution, and workflow.
That’s the playbook we unpack in this episode.
A lot of startup advice online is optimized for fast-moving consumer apps and narrow SaaS plays, but many founders are working in regulated markets, infrastructure, and entrenched legacy systems.
If that’s you, this episode contains vocabulary, frameworks (and real talk) that can help you build something genuinely durable.
What is a Compound Startup?
It’s a company that must solve multiple layers of the problem simultaneously because the system you’re replacing doesn’t neatly separate into “good wedge” vs. “later expand.”
In April’s case, the layers included:
A compliant, IRS-approved tax engine
National tax form coverage
A consumer-grade user experience
Embedded distribution into banks and fintechs
Infrastructure for real-time tax insights and financial decisioning
April didn’t build one layer in isolation — because the value only emerged when the layers worked together.
The Framework: How to Build Something This Complex
Ben and Daniel identified three basic principles while building April — and each one is transferable to any founder tackling a complicated market:
1. Sequence the Risk in the Right Order
Intuitively, founders want to make progress everywhere at once. Compound startups die that way.
April’s approach:
Risk #1: Technical feasibility — Can you build it at all?
Risk #2: Regulatory acceptance — Will anyone approve this?
Risk #3: Institutional distribution — Will partners integrate?
Risk #4: Consumer experience — Will people trust it?
You don’t need to solve everything on Day 1. Instead, pick the right domino to knock down first.
2. Treat Early Product Work as Science Experiments, Not Revenue Plays
Before writing code, they logged more than 100 customer interviews across banks, payroll, benefits platforms, wealth apps, and fintechs.
Not to sell, but to observe patterns. After they identified places where taxes created operational risk or customer friction, they began building the platform.
3. Write a Cultural Playbook Before Writing Code
This was one of the most refreshing parts of the conversation.
Before building anything, Ben and Daniel wrote a cultural manifesto that covered:
How they handle conflict
What “quality” means
How they give and receive feedback
How they make decisions under pressure
What standards are non-negotiable
This wasn't an offsite exercise; they developed a shared operating system to keep them in sync before starting a journey that would last years.
“Ironically, when things are going well, you spend most of your time dealing with the things that aren't,” says Ben. “Having a clear and cohesive framework for that is critical, both to success but also longevity in this game.”
RUNTIME 48:00
EPISODE BREAKDOWN
01:08 How Ben and Daniel met + connecting over complex data problems
01:47 Ben’s background: Deloitte, crypto infra, cyber, fintech
02:51 Why pick tax? Choosing a hard, high-impact market
03:44 Outdated incumbents + the opportunity hidden in “don’t touch that” markets
04:57 Why tax innovation is so rare: regulatory hurdles and decades-old engines
05:29 Founder-market fit: complementary backgrounds + AI expertise
06:38 Translating congressional law into code + achieving 20× engineering leverage
07:25 The pseudo-manifesto: conflict resolution, culture, and founder alignment
08:40 What “compound startup” means and why narrow wedges don’t work in B2B
09:57 Stitching data, workflows, and software into a flexible platform
10:39 Building for multiple configurations across financial institutions
11:26 How complexity becomes a moat
13:01 Why compound startups require longer gestation and patience
14:46 Sequencing layers: engine → coverage → interfaces → embedded infra
17:13 Serving customers early: friction with the market by design
18:46 Manual work vs. automation: the constant balancing act
19:27 The early KPI wasn’t revenue it was proving technical and trust viability
20:46 Running “science experiments” to de-risk assumptions
21:16 Investor expectations vs. seasonal learning cycles
22:47 Surviving four years of annual gauntlets before scale
23:02 Inside the regulatory maze: IRS approval, state forms, arbitrary specs
24:04 Data governance challenges: CCPA, IRS 7216, portability
25:20 Why April participates in the industry’s private governance body
26:18 Why April chose embedded distribution over a consumer app
29:08 Tax as the missing data layer enabling personalization
30:47 How customer discovery differed across banking, wealth, and SMB
32:51 What April had to prove at Seed, Series A, Series B
33:49 Why rigid VC benchmarks can be unhelpful for complex companies
37:02 Headcount growth: seed → A → B
38:20 Why Ben doesn’t interview every employee anymore
39:48 Founder evolution: doing → delegating → maintaining quality
40:55 Resilience, wellbeing, and founder longevity
41:39 The mythology of 996 and why it’s unsustainable
44:07 The most common mistakes first-time fintech founders make
46:14 The one question Ben would ask the CEO if he were interviewing for a job with an early-stage startup
LINKS
If you found this helpful…
… here are three things that help a ton:
1. Subscribe to Fund/Build/Scale on Beehiiv
I moved everything off Substack so I can centralize here.
2. Subscribe wherever you get your podcasts
3. If you’re feeling generous…
Become a paid supporter. It directly buys me time to make more deeply reported conversations like this one.
Thanks for reading,
— Walter.





