Thesis

Enterprise IT teams face growing pressure to operate across multiple cloud providers – often not by choice, but by necessity. Whether driven by compliance, cost, or performance needs, the result is a fragmented infrastructure landscape. Each cloud comes with its own tools, standards, and limitations, making migration and integration between them slow, expensive, and complex.

This friction creates real consequences. Organizations lose agility, engineering teams get bogged down in repetitive infrastructure work, and innovation stalls under the weight of technical constraints. Even with the right motivation, moving between environments often feels like reinventing the wheel.

We set out to explore how this pain could be abstracted away. The core idea was to introduce a lightweight, non-intrusive solution that would allow teams to transition between cloud environments more easily – without deep rewrites or custom engineering. Something simple, flexible, and broadly compatible that could reduce the complexity at the heart of multi-cloud operations.

Validation

We conducted our validation in three stages, speaking with around 40 tech leaders—VP R&Ds, CTOs, team leads, and developers—from both startups and large enterprises in Israel. Our goal was to understand the depth of the problem, the potential ROI, and the business case for our solution.

1. Understanding the Pain First

• At this stage we did not dig into how to solve it, but rather focused on whether multi-cloud was a significant pain point and to what extent. Conversations with a dozen of tech leaders revealed that migration times ranged from a rare minimum of three months (for a mid-sized team) two and up to two years in larger organizations.
• This validated our assumption: inefficient migration was a major blocker for enterprises.
  

2. Sizing the Opportunity

• We expanded our discussions to 20+ companies, refining our Ideal Customer Profile (ICP) and quantifying the impact of our solution.
• Larger enterprises showed strong interest, with one leader stating: “Save me 1% of my costs, and that’s worth $500K a year.”
• At this stage, we secured a design partner, reinforcing the market demand.
  

3. POC and Business Model Testing

• As we moved toward proof of concept (POC), we explored willingness to pay and commitment levels.
• While companies expressed interest, securing buy-in for deep technical integrations required more time for exploration.
• We also engaged with 15 VCs. Some struggled to see our differentiation, while others indicated interest – provided we refined our business model and vision.
• During this stage, we at the founding team started to realize this venture requires full commitment on our end.

Why it didn’t progress 

Team Commitment & Timing

When the project required full-time dedication, my co-founders decided it was not the right timing for them and they couldn’t commit, leading to a difficult but necessary decision to pause.

This wasn’t a lightweight SaaS tool – it required deep security and infrastructure integrations, which enterprises do not adopt lightly.

Our team wasn’t operating full-time due to other work commitments and the war in Israel.

Insights

1. Full-time commitment is critical: If all co-founders aren’t fully invested from day one, it’s better to recognize that early before significant time and money are spent.

2. Fundraising requires complete focus: Splitting time between fundraising and product development diluted our efforts. In hindsight, we should have delayed official fundraising in 2-3 months.

3. ROI translation is key: We needed a clearer business case and a direct ROI model before engaging VCs and enterprises.

4. Market timing matters: Just because a problem exists doesn’t mean the market is ready to adopt a solution immediately.

---