Podcast: Embedded Finance and the Art of Getting Your First Customer

Podcast Summary

• Embedded finance is the umbrella term for financial services delivered in context inside the software customers already use. It's broader than "banking as a service," which only covers banking products. Embedded finance also includes capital, lending, wallets, and money movement: anything that helps customers do more with their money.
• Building before you have committed customers can be the right call. When you're changing norms, you'll rarely get a clear yes upfront. Unit spent 2020 building before launching publicly. First customer landed in September of that year.
• The market splits into three groups: 1% deciders, 9% explorers, 90% unawares. When you face a decider, you can't afford to lose. Be patient with explorers and plant seeds with the rest.
• Cross the chasm or stay niche. The first 5% of buyers want Legos and will build the airplane themselves. The next 95% need a different product motion. Unit saw the signal in 2023 and didn't act until late 2024. Itai's biggest regret.
• The double activation problem is what kills platforms in embedded finance. Launching embedded finance inside your platform isn't a win. Getting your customers to actually adopt is. Plan for adoption work, not just launch work.

Transcript

Introduction

Somrat Niyogi: Welcome to Recall Sessions, a new series on the Village Global Podcast. Everyone talks about product, but I want to talk about something that does not get enough attention: go-to-market. Specifically, how do the world's most successful companies get their first customers?

In each episode, I sit down with founders and operators of billion-dollar companies to hear the real story. Not the polished version where everything just clicked, but the messy version: the cold emails, the first deals, and the selling before the product was even ready.

My guest today is Itai Damti, Co-Founder and CEO of Unit. Unit is the platform that lets companies offer accounts, cards, money movement, and capital under their own brand. Unit moves more than $80 billion annually, serves more than two million end users across more than 100 platforms, and powers programs at seven public companies, including Wix and Worldpay.

This is Itai's second company with his co-founder, Doron. They previously built Leverate together, which they bootstrapped to 160 employees and more than $100 billion in monthly trading volume. They have been building fintech companies and working together for more than 20 years.

Today, we are going back to the early days before Unit became Unit.

Setting the stage

Somrat: Itai, I have been wanting to do this for several years. There are not a lot of people who have started an embedded finance business, gotten to significant scale, and gone through the journey from the beginning. As someone who talks to a lot of founders building embedded businesses, I think there are not many people in the world with your experience. Thank you for taking the time.

Itai Damti: Thanks for inviting me. Excited to be here and to share.

Somrat: Maybe we can start from the early days. How did Unit get started? I know you and Doron had a prior company together. Set the stage for the history of Unit, and then we will jump into how you built it and acquired your early customers.

How Unit got started

Itai: We started the company in 2019. Doron and I had known each other for about 15 years at that point, and we had built together for most of those years.

For both of us, Unit was our third company. Our first company was a shared, decade-long experience. We left that business in 2016. After that, we each started second companies independently, and both failed. Then we got together again in 2019 to start what became Unit.

I am an engineer by background. Doron was CTO at our first business. I was not smart enough to be CTO, or even to make a bid for that seat this time, so I took the worst job: CEO.

We went through a six-month ideation process before Unit was born. We evaluated different ideas and landed on an insight about financial services innovation.

At the time, we looked at companies like Chime, Venmo, and LendingClub as what we thought of as “fintech 1.0.” These companies were trying to build what the big banks and incumbents had, but do it better, faster, and cheaper.

We thought that wave was coming to an end, or, at least, that it was not what financial services would look like 10 or 20 years later.

Then we saw something interesting happening. Companies like Shopify, Uber, Gusto, and Toast were expanding from their core software businesses into financial services. That could mean cards, accounts, capital products, or different forms of money movement.

We believed that wave had a much bigger right to win than the first wave of fintech.

Of course, everyone knows Venmo and LendingClub, but not many companies from that wave became truly massive businesses. When we looked at what Toast and Shopify represented in their segments, we thought: these companies have what it takes to win in financial services.

They have trust. They have data. They have distribution. They have software. They have money flows. All they need is a way to extend deeper into the financial lives of their customers, whether those customers are restaurants, e-commerce businesses, or something else.

So first, we believed the right to win was there. We could clearly see how thousands of companies were going to succeed in financial services.

The second thing we noticed was that the older fintech companies - the Chimes and Venmos - had built on pretty difficult infrastructure. Each one needed to invest a lot of money, make 10 to 20 buying decisions, and master a lot of concepts.

We thought there was no chance that if 2,000 more companies wanted to offer financial services, they would all have the resources and willingness to go through that. Something simpler needed to exist.

That was the premise behind Unit: make it easier for software companies to become winners in financial services.

Why “banking as a service” was the wrong term

Somrat: Was “embedded finance” already a coined term at that time? What was the state of the embedded fintech market?

Itai: Embedded finance was not widely used yet.

You saw a range of language. Some people described a set of infrastructure options, with card issuing as the center of gravity. Marqeta was starting to take off in a significant way. Some people used the term “banking as a service,” which we never liked, for multiple reasons.

You also saw different practices across the ecosystem. Some companies had their own bank charters and licenses. Other companies focused on just one component, which meant customers had to make multiple buying decisions to piece everything together.

There was no standard name for what the ecosystem was enabling.

I remember when Stripe came out with its product in late 2020 and used the term “banking as a service.” I thought: what are you doing? That is not the term that explains what is being built and what is possible.

They shifted the language toward banking as a service, but we continued to use embedded finance exclusively for years. Now I think the ecosystem is shifting back toward using embedded finance as the umbrella term for all these different constructs and experiences.

Somrat: What was wrong with “banking as a service”? In some ways, it sounds elegant. Why were you against it?

Itai: Banking represents something we all understand, but it is not really what is being built.

For example, when Toast built capital, or when Gusto launched wallets for employees, those were not always “banking” products. A capital product may be a loan product, where you need to keep track of liabilities a restaurant has toward you. That is not really a banking concept.

In Gusto’s case, it was more about wallets and cards. There was no obligation to the end users to behave like a bank.

We thought “banking as a service” was restrictive. It was also a supply-centric term rather than a demand- and experience-centric term. What is actually being enabled is embedded finance: financial services and financial experiences in context, delivered in ways that are much better than what traditional banking could provide.

Banking as a service felt reductive. It felt like it was related more to the supply side than the demand side.

Later, as the ecosystem evolved, some companies in that category gave the term a bad reputation. I think it became overdue for a repackaging and a rethinking of what we actually enable and what language we want to use.

Build first or sell first?

Somrat: When you started the company, did you think, “I want to raise capital and then build it”? Walk me through the sequencing. A lot of founders are trying to figure out the right approach. Do you sell the vision first? How did you verify that there was demand for embedded finance products?

Itai: Our first company shaped our entire career experience. It was completely bootstrapped. Doron and I were two of four founders, and we spent 10 years building that company without any VC money.

So the idea of VC money was foreign to us when we started Unit. Of course, we had many friends who had started VC-backed companies, but it was not obvious to us. Money is just a way to finance a business. A business still needs demand.

There was also a futuristic component to our thinking. Back then, it was not common to think about embedded finance as something that would clearly branch out of software.

One of the things we learned from our first company was that we needed to execute in a big market. Even if the market was speculative, we needed to operate in something we believed would become a big market. Financial services is one of the biggest industries on earth, so it felt like the right place to make that kind of statement about the future.

There was definitely risk. We did not fully de-risk it. It was not like selling cloud security, where you already know companies need the category and you just need to validate your specific product. This was more speculative. We were projecting five to 10 years ahead.

Somrat: How did you validate a market that did not fully exist yet?

Itai: It was hard to validate, but there was one interesting form of validation.

A company called Synapse, which no longer exists, was starting to take off. It was clear that people were getting value from financial primitives: identifying end users, opening accounts, issuing cards. The idea of “Lego-ing” the financial system, building with blocks, was interesting to us.

We looked at the use cases that existed. Most were neobanks: not just Chime and Venmo, but also newer consumer finance companies built on companies like Synapse.

We also saw interesting examples of people using that infrastructure to store and move money. For example, helping real estate funds collect money and disperse it back to investors.

So we thought this idea of creating building blocks for money storage, money movement, and potentially credit had legs.

We had to squint and imagine what it could become in 10 years. We talked to people who had built on older infrastructure,: companies like Chime and Mercury, and people who had built on newer solutions like Synapse.

The people who used the newer solutions were not happy with the quality in some cases, but they said they were not going to make a change immediately. They wished us luck.

People who had built on old solutions also said moving to something like Unit was not a decision they could make overnight, because they had so much sunk cost.

But we saw signs that people were thirsty for better infrastructure. Then we decided to build a V1 - not with clear first customers in mind, but with the bet that once we were close enough to launching, we could find customers and scale with them.

Somrat: That build-first decision is interesting. A lot of technical founders think, “I need to build something, then I will sell it.” Looking back, was that the right approach? You had APIs and web components, but how did you know you were building what your first customers would actually want?

Itai: What we set out to build was unusual.

If you looked at the infrastructure landscape back then, Marqeta existed purely as a card issuing solution. There were compliance and identity solutions that people could cobble together with Marqeta. There were ledgering solutions, money movement solutions, and partner banks.

Pitching the idea of Unit would hardly get you a yes, because people could not always square it with the infrastructure they knew.

That often happens when you change norms. Stripe is a similar example. If you told people it would be instant to launch payments with a single line of code, the people who lived inside the old constructs of payments acceptance might not have immediately seen how groundbreaking that was. But Stripe succeeded over time.

Rippling is another example of a company that broke norms and bundled more than what seemed reasonable into one system.

So it is hard to get a yes when you are changing norms. I do not encourage people to launch companies without validation. To be clear, I violated every piece of business advice I had given people in the preceding few years.

But I thought: if the approach is new enough, and if it is hard to get a clear yes as a new infrastructure company, the best thing you can do is build it, start validating traction, and then, like every early-stage founder, tell yourself that if it does not work, you will iterate your way toward product-market fit.

Luckily, it ended up attracting companies in the beginning and then scaling. But it was a bet.

Finding the first customer

Somrat: Tell me about your first customer. Everyone is trying to find that first customer who will actually bet on them. Unit had credible founders, but you were still building in a sensitive space that requires trust. How did you find your first customer? What was that relationship like? Were you still building the plane, or did you already have components ready?

Itai: In a space that requires trust and proof points, you have to get creative with how you approach the first customer.

I violated another principle at Unit: we spent a year building before we launched publicly. We raised money in late 2019 and launched publicly in late 2020.

During that year, we were compensating for what we thought would be a healthy market need. We wanted to design thoughtfully.

Somrat: Just to make sure I understand, you did not have any committed customers while you were building?

Itai: Correct. We wanted to have committed customers, but we did not.

We had built a network and gathered enough feedback from people in the market to form strong opinions about the design of the system, the type of content we might lead with, and the messaging. But it was purely a lab exercise designed to set us up for success at launch.

I do not want to say it was academic, but it was definitely building with calculated bets about what the market would accept.

In 2020, we focused on three things.

First, we built what we called an unreasonably wide system. Identity, security, ledgers, card issuing, and money movement were all built into one operating system. This was the Rippling-style narrative violation: we were not going to send customers to buy five or six different solutions. We wanted to give them something more opinionated that helped them move faster.

Second, we hired and contracted with people who brought critical compliance and legal experience. Doron and I had both built fintech for many years, but we had no idea how to approach the banking space. It was important to get the right knowledge and systems in place. For example, if an end user has a debit card and wants to dispute a transaction, how do you ingest that dispute in a compliant way?

Third, we had to secure critical partnerships, especially with banks. Banks installed Unit as their operating system before we could get a first customer live.

We had to do all of this in parallel. That is why we spent 2020 mostly in building mode with a minimal team.

Toward the end of the year, once we had hired our first engineers and compliance people, we were getting ready to launch the website. That was around August 2020. We also raised our Series A at that point, before we even had a live website, because we had made enough progress toward a working system.

Then Gradient Ventures contacted me on LinkedIn. Victoria, a partner there, had probably heard about us from others in the ecosystem. She said they had a portfolio company called Benepass that wanted to launch something that might be a good fit for us.

She made the introduction. It took us 12 days to give Benepass sandbox access.

We built the sandbox and completed the features as we got ready to hand them the keys. Twelve days later, in September, I sent them a handcrafted email with their sandbox email and password, instructions, and endpoints. They started building.

We got lucky with that customer. Today, Benepass has raised a Series B, has great investors and a great team, and serves a lot of public companies. But back then, they had an open enrollment timeline to meet because they were in the benefits space. What they wanted to build with us was an HSA product, so they had a December deadline. All they cared about was getting it right and moving quickly.

They also had a very technical DNA. They appreciated the design and the simple approach to building with Unit.

And you can never set aside the founder-to-founder relationship. We got on calls with them, took deep notes on their questions, and gave them white-glove service. That is what eventually got us to launch with them.

Why Benepass was the right first customer

Somrat: Benepass does not seem like an obvious first customer based on what you described. Did you have dozens of other opportunities and decide this was the best one? What if Benepass had not launched successfully? It could have changed the dynamic for Unit.

Itai: You do need to plant as many seeds as possible as an early-stage founder.

The shape of the Benepass use case sounds different because it is benefits, but mechanically, an HSA is actually a checking account. We needed to speak their language, but from a regulatory construct, they were building something very much in line with what we had built.

They also did not need to identify employers at the time. They needed to identify employees. That made it easy to square a V1 of Unit, which only supported identity checks for individuals, with their use case.

It seemed like a strong fit for what we were building.

There is always a risk of overfitting the system to specific use cases. We always wanted to stay in the business of Legos. You always have to ask yourself: am I building a piece of Lego that no other company would use, or that very few companies would use?

Back then, it was easy to square what Benepass needed with what we had.

We also started building relationships with other companies. We needed people to know about us, because building credibility was a slow act. It required social proof. It required buzz in the ecosystem, so people would know what was being offered.

On the heels of Synapse, and some of the early disappointment among some of their customers, a better NPS could travel across the ecosystem.

Benepass was also a YC company, and their work with Unit created a lot of early excitement in the YC community. That later propelled us to more scale.

Sequencing early go-to-market

Somrat: After raising a Series A and landing Benepass as the first customer, how did you think about sequencing? There is a lot required to make the first customer successful. Did you focus only on them, or did you try to land more customers in parallel?

Itai: Benepass was a baby company back then. The product they built with Unit was an expansion into health savings accounts, but it was not even the main thing they enabled. They are a benefits company, and they allow people to spend on behalf of their employers. They needed us for something specific and adjacent. Over time, they expanded with us.

As a founder, you should try to work with as many customers as possible in parallel, as long as it does not compromise your long-term success.

Shopify is an extreme example. Shopify can let you, me, and 50 other people sign up in parallel to open a store. Shopify does not need to form an opinion about whether one specific store will succeed. If 5%, 10%, or 50% of the stores succeed, Shopify ends up serving successful stores.

Unit is not that simple. We have onboarding resources, bank capacity, oversight, and compliance to enforce.

I have always thought of Unit as a system of bottlenecks. Every company is a system of bottlenecks. As a founder, you want to remove as many bottlenecks as possible so your machine can create high output.

At the time, we did not have a good reason to stagger or slow down onboarding other customers. Today, we have products that are more hands-on, and the opportunity cost of underinvesting in a large customer can be significant. But when your business is Legos, you want to allow as many people as possible to buy the Legos, create what they want, and go to market.

Deciding which customers and requests to say no to

Somrat: Some customers are much more demanding and may need new kinds of Legos, while others are happy with what you already offer. How did you prioritize? Did you take as much opportunity as you could and push R&D to build as many Legos as possible? Or were there certain types of customers you said no to?

Itai: We definitely said no to some customers.

As an extreme example, we never touched consumer credit. If a company came to us and said they wanted to launch a credit card for consumers, we would turn down the business immediately.

The question you are asking is one of the timeless questions in startups and product management: I am facing a large market, and my product is lacking by definition. How do I say yes to the right opportunities? How do I allow them to thoughtfully shape my roadmap instead of letting them destroy my product or force me into something I do not want to build or something that will not be useful to others?

I will say two things.

First, the job of great infrastructure product teams is to identify useful Legos that do not force you to build a new solution every time.

For example, when we calculate interest, we allow companies to specify whether they want to pay 2% interest or 1% interest on an account. That allows them to take the Lego and configure it, but we do not need to build something custom for company A and company B.

Designing the right building blocks, and designing them in a way that is reusable and broadly applicable, is the job of great infrastructure builders.

Second, we have a system that may be useful to people: green, yellow, and red feature buckets.

If I am selling to you, some of the things you say you need will already exist. That is the green bucket. Take the Lego and run with it.

The second bucket is for things you need that we already planned to build later. For example, you might say, “I want the product to allow me to set limits for different kinds of people.” We might say, “That is something we had planned for six or nine months from now.” Because you say it is important, maybe we bring it forward.

That does not destroy the product or twist it into something unnatural. It just moves forward something we already thought we would build.

Then there are things that are not a fit. If you came to me and said, “I want to build a new type of benefits solution, but I do not have the technical resources. Can Unit build it for me?” our answer would be no.

I do not see how that serves us now. I do not see how it serves us in a year. And you are too alone in needing it for that to make sense as a native part of Unit.

So I encourage founders to bucket features and understand what people are really asking for.

Creating demand in a new market

Somrat: You have this concept of deciders and explorers. In embedded finance, the opportunity may be large, but not everyone is already thinking about building embedded fintech products. How did you prioritize who really needed something? How did you create demand? Was it all push, or did it eventually shift to pull?

Itai: This is true for embedded businesses, but it is also true for any new market.

If you are building something that does not exist yet, you have to accept that the market is sometimes very educated. In the case of maybe 1% of people, they already want to buy what you have. Sometimes the market is somewhat educated: people are exploring what you offer. Then there is a large swath of the market that is uneducated. We call them “unaware.”

At Unit, in any given year, we thought about buyers in three groups: deciders, explorers, and unawares.

The deciders know they want something Unit can solve. They are likely to come to us, or we can find them.

If deciders are 1% of the market, explorers are another 9%. Explorers may say, “Can I get an ROI analysis that helps me quantify the opportunity in fintech? I would like to compare it to an AI investment that my CEO already wants me to make.” They are exploring. They want to understand the cost and benefit. If they decide it is a good idea, they may become deciders.

Then there are the unawares, who may represent 90% of the market. You have to be patient and plant seeds. By definition, when Unit started, most of the market was unaware.

Our approach was: when we face a decider, we need to excel. We cannot waste sales opportunities. We cannot lose when companies are actually making buying decisions. We have to shine.

Somrat: How do you know someone is really a decider? People often say they are deciding, then punt another quarter or two. How do you assess whether an account is actually a decider?

Itai: That is timeless in sales. You think someone is ready to make a decision, and then they kick the can.

There are two things.

First, be patient. You are building relationships, learning, and teaching. Hopefully, the delayed demand does not kill your company. But if it does not, you are earning relationships and learning that may eventually get you the business.

Second, and this was a big mistake we made at Unit, we initially took “not now” as a sign that the market was not ready. But our product could have been much better and much easier to choose.

That realization motivated us to create another set of implementation options that allowed companies to plug and play and test demand more quickly.

In other words: if you hear “not now” once, that is fine. If you hear “not now” 50 times, you have to ask yourself whether your product is in a shape that allows people to say yes. Or does it always seem like too much investment and too speculative?

If so, you need to do something about the product.

Crossing the chasm from early adopters to the mass market

Somrat: What did you do to make the product easier to adopt? And how did you validate that it worked in the market?

Itai: In many early markets, the first buyers are the most enthusiastic and early-adopting by nature. When the iPhone came out, the people who bought it first were the gadget lovers.

As you move deeper into the mass market, you encounter pragmatists, conservatives, and eventually the people who are latest to the party.

What we realized - and this was a very important part of Unit’s journey - was that Benepass and many of the early companies we sold to, including the first 100 companies, had the resources, motivation, and comfort to build with Legos.

But selling into the mass market requires a very different product motion and go-to-market motion. If you do not get the product insight right, no amount of go-to-market will help.

When people ask how you pitch companies to buy embedded finance, I say you need something that makes it easier for them to engage and say yes:L not all of them, but a reasonable number.

The first version of our product was building-block based and API based. I say we sold people airplanes and taught them how to fly.

With pragmatists - the people at the next 500 companies - we took a different approach. We told them, “You might want to fly the airplane one day, but we have an airline we can operate for you. You can choose to put passengers on it and sell the tickets.”

In other words, they could send people into an embedded finance area in their product, but Unit would build and manage the experience, down to customer support, limits, and fraud.

That is a very different way to present the product because it allows customers to think in plug-and-play terms.

We also launched capital, which allows customers to offer capital without offering banking and without offering money movement... directly into people’s Chase or Wells Fargo accounts. That helped us reach the next set of buyers.

The double activation problem

Somrat: For an infrastructure business, your growth is tied to how well your customers sell their own products. Just because customers build on you does not mean their products will work or scale. How did you think about that?

Itai: This is the classic double activation problem. It exists in embedded finance and in any embedded product.

It is not only about selling to someone. It is about encouraging them to sell and drive adoption among their own customers.

That is a hard problem. For any embedded founder, I would say this can kill your company. If you do not consider the capital implications of the journey, and if you underestimate how hard and slow it will be to get adoption and volume, you might overspend.

I have spoken with many people building embedded solutions over the last three years, and this is my first advice: think seriously about the capital equation. Do not assume you can always raise the next round on growth just because you bring logos. You have to drive activation within your customers’ customer bases.

Historically, we have seen different patterns. I describe it as: people who bought the airplane and flew high, people who bought the airplane and never took off, and people who took off and then landed.

Some companies grapple with the adoption question. For some, it is easy. For others, it is much harder.

Somrat: Are there rules of thumb you would share with other embedded founders? How do you know customers are not just going to build the product, but actually care about the execution and performance of what they build?

Itai: First, leave a lot of margin for error. Do not kill your company by assuming every logo you sign will fully materialize. That is not going to happen.

Second, identify the patterns that indicate whether someone is more or less likely to be successful.

For example, companies that use Unit as mission-critical money infrastructure are much more likely to use you deeply. Benepass is a good example. They integrate accounts into the onboarding flow for employees. The account opening is woven into the Benepass onboarding flow, and it is almost invisible to the employee.

When Unit is a critical piece of infrastructure that enables something important in the business, that is a good sign. It suggests the account is more committed and easier to retain and grow.

Another pattern is companies that already have money flows going through them.

Wix is a good example. Wix helps hundreds of thousands of businesses process payments and sell goods and services online. They pay out to a Chase or Citi account, but they have the ability to create a built-in money hub within Wix. They need to construct the experience and reroute payments so funds go into that money hub.

So we look for signs that we are either mission-critical infrastructure that enables something important in the business, or, if the product is adjacent, that the conditions for success are present.

Of course, you also care that the leadership at the company you are selling to is committed.

When to turn away business

Somrat: Did you ever say no to companies because you did not think they needed Unit or it was not the right time? Or did you sometimes close a customer even if you did not know where it would go, but you had another reason to do it?

Itai: We say no to customers for many reasons.

One reason can be commercial: we do not see legs. For example, a consumer neobank in 2026 would not excite us, so we would let them find other solutions in the market.

We have also signed companies knowing there was some speculation about whether they would be successful. They wanted to take the swing, and we committed to helping them.

We have seen many people enter embedded finance with the best intentions and never take off. We have also seen companies take off and then decide it is not for them.

For example, we have seen companies operate embedded finance at scale and then say, “We are paying out to hourly workers, and we do not actually feel this is better than Venmo. Even though we are at some level of scale, we are deciding to withdraw from this space.”

What matters most is the product. If you design your product to make it simpler to launch and simpler to succeed with minimal brain damage, that is the key to scaling and sustaining.

There will always be shots that do not hit the goal. That is part of building infrastructure.

Looking back: what Itai would do differently

Somrat: If you went back to 2019 or 2020, what would you do differently? What advice would you give founders starting companies now? Whether fintech, infrastructure, AI SaaS, or something else?

Itai: Be mindful of the chasm.

The gap between your early adopters and the mass market is where many companies die, or become niche businesses that never scale.

At Unit, we started seeing signs around 2023 that a different type of buyer was on the horizon, but we did not take full action until late 2024.

Be very mindful that the first 5% of your customers will be very different from the next 95%.

We eventually acted on the product and go-to-market motions required to capture the mass market, but we could have done it sooner.

The same is probably true for AI businesses today. There may be a group of tech-savvy people who pick up your product first. But if you sell to restaurants, for example, the pool of tech-savvy restaurant owners is relatively small.

At some point, you may need to lean into older-school techniques: salespeople, mail offers to restaurants, foot traffic, and other messier motions. Do not avoid those.

Embrace the messier problems that will help you unlock more.

I often think about Amazon and logistics. If Amazon had not cracked logistics, it would not be the company it is today. If something messy helps you become the company you want to be, take it seriously.

Somrat: I love that. I feel like we could spend another hour on pricing, packaging, technical buyers, and more. A lot of founders are struggling with these questions, and there is more to cover. Thank you for taking the time and sharing your experience.

Itai: Thanks for inviting me. Glad to share.