From Operations Manager to Founder: How SubBase Was Built While Running Construction Jobs

In a recent episode of Category Visionaries, Eric Helitzer, CEO and Founder of SubBase, a construction materials management platform that’s raised $5 million, described a constraint that most founders never face: “I had to balance between building software for something that I thought could be amazing and also running a job and running multiple jobs, and being a part of the company that was hiring me to build and operate.”

Most founders build software, then find customers to use it. Eric did both simultaneously—building material procurement software in the morning, using that same software to order materials for actual construction projects in the afternoon, discovering bugs on job sites, and fixing them the next day.

This wasn’t a deliberate product development strategy. It was necessity. And it created feedback loops that most startups spend years trying to build artificially.

The Three-Month Ultimatum

SubBase didn’t start in a garage or a co-working space. It started inside a construction company, with Eric running operations while building software on the side. The company knew about it. They’d even invested early. But they weren’t patient.

“They gave me three months to figure out how to make this work,” Eric recalls.

Three months to validate that the software worked. Three months to prove it could become something bigger than an internal tool. Three months before the company would pull the plug and expect Eric to focus entirely on construction operations.

This created an unusual dynamic. Eric wasn’t a founder who left his job to build a startup. He was an employee with permission to build a startup—but only if he could do both simultaneously, and only if he could prove viability within a quarter.

Most founders would see this constraint as impossible. Eric saw it as an opportunity to test the software under real conditions immediately.

The Dual Reality

The early days involved a schizophrenic schedule. “We would be running jobs, but I’d also be running demos with a very early mvp that took off pretty quick.”

Construction jobs don’t pause for software development. Materials need ordering. Vendors need coordination. Budgets need tracking. Projects have deadlines regardless of your MVP’s feature completeness.

So Eric did both. “We had a very awesome product from the get go, but we’re iterating very fast. And what I would do is I would actually take the product to some of our jobs.”

This “take the product to some of our jobs” approach meant every feature got tested in production immediately. Not in a staging environment. Not with beta customers who’d be forgiving of bugs. On actual construction projects where material delays cost money and ordering mistakes impact timelines.

“As we’re iterating on the product, we’re also building what we didn’t even know it was going to be called SubBase at the time.”

The software evolved through real operational pressure. When a feature didn’t work, Eric found out not through a support ticket, but through a vendor calling about a confused order. When a workflow was clunky, Eric experienced the friction himself while trying to meet project deadlines.

The Feedback Loop That Changes Everything

Most founders spend months trying to get customer feedback. They schedule user interviews. They watch session recordings. They analyze usage data. They’re always one step removed from the actual pain.

Eric had no separation. When the software failed, his construction projects suffered. When workflows were inefficient, he wasted his own time. When features were missing, he felt the gap immediately.

This created product development advantages that are nearly impossible to replicate:

Zero latency between problem and solution. Traditional customer feedback has delay—the customer experiences a problem, decides to report it, contacts support, the feedback reaches product, and eventually gets prioritized. Eric’s feedback loop was instant. Problem discovered in the morning, fix deployed by afternoon, tested on the same job the next day.

Perfect understanding of context. Customer interviews capture what users say about their problems. Using software on actual construction projects captures the full operational context—why this order matters, what the vendor relationship dynamics are, how this connects to project budgets, what the downstream impacts are.

Authentic prioritization. When you’re both building software and using it professionally, feature priorities become crystal clear. You can’t trick yourself into building nice-to-haves. You build what you actually need to get your job done.

Real-world edge cases. Construction is messy. Projects change mid-stream. Vendors update pricing unexpectedly. Materials arrive wrong. Payment terms shift. Testing on real projects exposes these edge cases immediately, not months into customer usage.

When The Office Visitors Changed

The dual reality couldn’t last indefinitely. Eric knew the turning point had arrived when the nature of his office visitors shifted.

“We started to see influx of people that were coming to the office to get demos, versus coming to talk to me about new work or work that was ongoing.”

People weren’t visiting to discuss construction projects anymore. They were visiting to see the software. The construction company’s office had accidentally become a software sales operation.

“So in 2022, I had to separate the two and decided to take the leap of faith into what is now the construction tech world.”

This moment—when demand for the software exceeded capacity to serve it while running construction operations—is the signal most founders dream of. But Eric had reached it through an unusual path: building software so good that his own company used it, then watching other companies want it too.

What Makes This Approach Work

Not every founder can or should build their startup while doing the job their software solves. But Eric’s path reveals when this approach creates disproportionate advantages:

You’re solving operational problems, not feature gaps. Material procurement isn’t about missing features—it’s about operational inefficiency. Software that actually works in operations beats feature-rich software that doesn’t fit workflows.

The industry resists change from outsiders. Construction companies don’t trust software built by people who’ve never run construction projects. Eric’s credibility came from doing the actual work, not from impressive technical credentials.

The feedback cycle is short enough to be actionable. Building construction projects takes months or years, but ordering materials happens daily. Eric could test, learn, and iterate quickly because the operational cycles were fast enough.

Your own usage represents your ICP accurately. Eric wasn’t a consumer building B2B software or an engineer building for operations teams. He was an operations manager building for operations managers. His needs actually matched his target customers’ needs.

The Domain Expertise Compounds

What Eric gained from this dual reality wasn’t just early customer feedback. It was domain expertise that became an insurmountable competitive moat.

When he talks to subcontractors about material procurement challenges, he’s not reciting customer research. He’s describing his own experience. When he explains how SubBase fits into existing workflows, he’s not guessing—he knows because he lived those workflows.

“I come from the industry. I love speaking about what we’re doing.”

This authenticity matters in construction, where relationships and credibility drive adoption. Subcontractors can tell the difference between someone selling software and someone who’s actually managed subcontracts and ordered materials and dealt with vendor relationships.

Fifteen years of construction experience gave Eric knowledge that no amount of customer discovery could replicate. The additional months building software while running projects gave him something even rarer: real-time understanding of how software needs to integrate with construction operations.

The Trade-Offs

Eric’s path wasn’t without costs. Three months of intense dual responsibility. The stress of building software while meeting construction deadlines. The uncertainty of whether the company would actually support the transition or shut down the experiment.

Most founders can’t negotiate this arrangement. Most employers won’t accept it. Most industries don’t have operational cycles fast enough to make it work.

But for founders who can arrange this dual reality—who can build software while doing the job the software solves for—the advantages are profound.

You skip months of customer discovery because you are the customer. You avoid building features nobody needs because you only build what you actually need. You develop domain expertise that competitors can’t replicate because you’re not studying the industry—you’re working in it.

The Lesson For Founders

Eric’s story challenges the standard startup advice about focus. Conventional wisdom says quit your job, go all-in, focus exclusively on the startup.

But what if your job is the best possible product development environment? What if your operational experience is your primary competitive advantage? What if the feedback loops from doing the actual work are more valuable than extra hours writing code?

For founders building in traditional industries—construction, manufacturing, healthcare, logistics—Eric’s path suggests a different approach. Don’t leave the industry to build software for it. Build software while still in the industry. Use the operational reality as your testing ground.

The dual reality is hard. Eric had three months to prove it could work, with the company watching closely. But that difficulty created something valuable: software that actually worked in construction because it was built by someone still doing construction.

That’s not just a better MVP. That’s a better company.