Why Kintsugi’s Founder Spent 2 Years Doing Manual Tax Work Before Writing a Single Line of Code

Most technical founders can’t wait to start coding. The urge to build is overwhelming—sketch the architecture, spin up the repo, ship an MVP. Pujun Bhatnagar did none of that. Instead, after quitting Facebook in 2021, he spent two years filling out tax forms by hand for ten different companies. No product. No customers. No revenue. Just spreadsheets, jurisdiction rules, and the tedious work of sales tax compliance.

That decision—to become a practitioner before becoming a founder—is why Kintsugi is now doubling revenue month-over-month while competitors struggle to keep up.

In a recent episode of Category Visionaries, Pujun Bhatnagar, CEO and Co-Founder of Kintsugi, a sales tax automation platform that’s raised over $8 million, revealed the counterintuitive strategy that became his company’s competitive moat: doing the unsexy work first, for years, before writing scalable code.

The Two-Year Detour That Wasn’t

September 2021. Pujun had just left Facebook with a hypothesis: the 2018 Supreme Court ruling on sales tax would create chaos, and whoever built the right software could win. Most founders would immediately start building that software. Pujun took a different path.

“In the two years leading to the pre seed fundraising, I was doing sales tax by hand for ten different companies just so that I could understand really the ins and outs of what needed to be built,” he explains.

Two years. Ten companies. Manual work. This wasn’t customer development in the traditional sense—sitting in coffee shops asking people about their problems. This was full immersion. Filing actual tax returns. Computing liability across jurisdictions. Dealing with exemption certificates. Handling amendments. Living every edge case, every exception, every frustrating workflow that makes sales tax compliance so painful.

The timeline is revealing. Started in September 2021. Incorporated December 2022. Raised pre-seed September 2023. “We started writing really our first line of scalable code after pre seed fundraising. Before that was all MVP.”

Think about what that means. By the time Kintsugi wrote production code, Pujun had personally processed tax returns for ten businesses across 48 jurisdictions for two years. That’s not research. That’s mastery.

What Manual Work Teaches You

There’s a specific kind of knowledge you only get from doing the work yourself. Not observing it. Not interviewing people about it. Actually doing it.

When you manually file sales tax returns for ten different companies, you learn:

• Which parts of the process are genuinely complex versus which parts just feel complex
• Where the hidden time sinks are that customers don’t mention because they assume that’s just how it works
• What data exists in what systems and why getting it clean is harder than it looks
• Which edge cases happen frequently enough to matter versus which are theoretical
• Where trust breaks down and why customers stay up at night worrying

This depth shaped every product decision. When Kintsugi built their onboarding flow, they knew exactly which data points mattered and which were noise. When they designed their AI engine, they knew which calculations had to be perfect and which could be approximate. When they built integrations with ERPs, they knew which fields would be messy and needed cleaning logic.

“We decided to basically flip the script and flip the table on the problem space and say, we are going to build a sales tax engine that is empowered by AI, where with three clicks and three minutes, we’ll be able to show your sales tax liability and exposure,” Pujun shares. That three-minute onboarding wasn’t a guess. It was informed by two years of understanding exactly what data was essential and what wasn’t.

The Depth Competitors Couldn’t Match

Here’s why the manual work period mattered strategically: every competitor in the space was building from the outside in. They’d look at the problem, talk to some customers, and build what seemed reasonable. Kintsugi built from the inside out.

“All the players in the market, Avalara, it was a big company, but not necessarily a good company,” Pujun notes. “They were kind of caught with their pants down with the changing regulations, because if you have a sales tax engine that is powered by engineering, you can change the code and you can very quickly iterate to catch up with the different rules that are coming out.”

But why were they caught unprepared? Because they didn’t have practitioners building the software. When regulations changed, they had to figure out what changed, how it affected calculations, and what needed updating in the code. That’s a multi-week process when you’re working from documentation and customer complaints.

When you’ve personally filed returns across jurisdictions for two years, you understand the regulatory landscape at a visceral level. You know which jurisdictions are strict about thresholds, which ones have weird rules for digital goods, which ones change rates frequently. That knowledge compounds when regulations shift—you can predict second-order effects and build for them proactively.

The Customer Discovery That Actually Mattered

Kintsugi didn’t just do manual work—they paired it with systematic customer discovery. “We had this massive spreadsheet of 15 adjacent ideas that we wanted to build in. And we just did, I think, 300 to 500 interviews to essentially figure out what we wanted to build.”

But notice the sequence. The interviews weren’t trying to understand the problem—Pujun already understood the problem deeply from doing the work. The interviews were about validating which solution would resonate, which pain points customers were most desperate to solve, and how they thought about the problem versus how it actually worked.

That’s a subtle but critical difference. Most founders interview to understand the problem, then build based on what customers say. Kintsugi interviewed to understand the gap between customer perception and reality, then built software that bridged that gap.

For example, customers would say they just needed help with filing. But from doing the work manually, Pujun knew the real problem was upstream—knowing where you had nexus, computing accurate liability, and collecting the right amount in the first place. Filing was the visible pain point, but incorrect collection was the hidden disaster.

The Compounding Advantages

The two-year investment in manual work created advantages that compounded over time.

First, product velocity. “We spend, I think, 65% to 70% in R and D,” Pujun shares. That R&D investment could move fast because the team wasn’t guessing about requirements. They knew exactly what needed to be built, in what order, with what tolerances. No pivots, no major rewrites, no discovering six months in that you built the wrong thing.

Second, customer trust. In compliance software, customers need to believe you really understand their problem. When Pujun talks to prospects, he’s not speaking from slides—he’s speaking from experience. He’s filed the same forms they’re filing. He’s dealt with the same jurisdictions. That credibility closes deals.

Third, defensibility. The depth of domain knowledge became a moat. “We are the only software in the space which actually has a get started button on the website and where people can actually, seven clicks or three minutes, they can get onboarded and see their sales tax liability within ten minutes without talking to a sales personnel,” he explains. That’s only possible when you understand the problem so deeply you can automate what competitors think requires human review.

The Results Speak

The payoff for the two-year investment? “Ever since we were publicly available, we have been doubling in revenue month over month.” The company went from three people to 47 in ten months. They “quadrupled in revenue ever since we raised our Series A” and recently secured funding “at two x the valuation of what we raised our Series A at.”

That growth rate isn’t luck. It’s the compounding effect of building from a foundation of deep understanding. When you know the problem that intimately, you build the right product, which attracts the right customers, which generates revenue that funds more R&D, which lets you build more features competitors can’t match.

The Lesson for Founders

Most founders won’t spend two years doing manual work before building. They can’t afford to, either financially or temperamentally. But the principle holds across domains: depth beats breadth in competitive markets.

If you’re building in a complex space—whether it’s compliance, finance, healthcare, logistics, or any domain with high regulatory burden and entrenched workflows—consider the Kintsugi playbook: become a practitioner first, build second. Do the unsexy work. Learn the edge cases. Understand why things are the way they are, not just what they are.

The months you spend not coding might feel like wasted time. They’re not. They’re the foundation for building something competitors can’t easily replicate. Because while anyone can hire engineers, not everyone will spend two years filling out tax forms to understand the problem at the level required to actually solve it.