Building Software in Startups with Ron Shteinberg - E3

In this exciting episode of Software Meets Business, host Richard Bundock sits down with Ron Shteinberg to dive into the intricacies of building software within startups, focusing on the process of finding, hiring, and working with external software teams. They also explore the challenges, rewards, and pitfalls startups face when developing software, and how building solid relationships with software partners can lead to long-term success.

WATCH NOW ON YOUTUBE

FOLLOW US ON TIKTOK

[00:00:10]

Rich: Welcome to another episode of Software Meets Business. I’m excited to have Ron Shteinberg with us today. Ron is the co-founder and Chief Technology Officer of Bounce. Welcome, Ron!

Ron: Hi, great to be here.

[00:00:37]

Rich: This podcast is all about how software integrates with business. You’ve got quite a background in building software products. Why don’t you talk us through your early experiences?

Ron: I’ve been in technology for two decades now. I know I look younger than that, but yes, it’s been 20 years! I started as a software developer, then moved on to managing small teams, larger teams, and eventually entire engineering infrastructures. About 11 years ago, I moved to London with my family and worked in fintech and pure software companies. Eight years later, I returned to Israel to start Bounce. Over the years, I’ve built many types of software systems—from embedded software for chips to decision-making fintech systems. So, I’ve done it all.

[00:01:49]

Rich: You started out building software yourself, then transitioned to managing teams and outsourcing. What were the early challenges in finding the right people?

Ron: When starting a new project—whether it’s a new company or a venture within an existing company—there’s usually a sense of urgency to get things rolling. My approach has been to initially bring in a trusted outsourcing company to quickly get developers on board. This allows the project to progress while giving me the time to hire the right in-house engineering team. It also helps me better understand the roles and skills I’ll need in-house later. This approach keeps things cost-effective and allows us to move fast.

[00:02:58]

Rich: So, when you start building a new product, you hire an outsourced team first to help define the structure and then gradually bring in your own team?

Ron: Exactly. This approach works particularly well when starting from scratch. If you’re within an established company, you can pick and choose internal team members and supplement them with outsourced developers. Having a trusted outsourcing partner is always useful—it ensures you can meet deadlines and deliver results quickly without compromising other areas of the business.

[00:04:00]

Rich: Some people insist on building everything in-house. You seem to prefer a hybrid model. Why is that?

Ron: Flexibility. Markets fluctuate, demands change, and you need to scale up or down quickly without the overhead of hiring or layoffs. For critical, core parts of the product, I always keep development in-house. Outsourced teams are great for peripheral tasks, like integrations with third-party systems, where specialized knowledge isn’t required long-term.

[00:05:13]

Rich: Can you give an example?

Ron: Sure. At Bounce, our core involves analyzing transactions and running machine-learning models. That’s our business, so it’s all done internally. But integrating with payment systems like Stripe or Braintree? That’s not our core competency. It’s something I’m happy to outsource because it speeds up our time to market.

[00:06:32]

Rich: What about internal tooling? Would you outsource that?

Ron: That’s a tricky one. I tend to think about infrastructure first—things like deployment pipelines and CI/CD processes. Starting with a basic “Hello World” deployment to production is crucial to identify potential issues early. For larger infrastructure projects, I might outsource some work, but only if my in-house team remains involved in the design and reviews. They need to fully understand the system for future maintenance.

[00:08:32]

Rich: You’ve mentioned working with trusted partners. How did you go about finding them?

Ron: Early on, I didn’t know how to choose outsourcing partners. I experimented by hiring individual developers to see who delivered better results. Over time, I developed a “matrix” to evaluate companies based on:

• Technology stack expertise (e.g., backend, frontend, specific languages).

• Company size (large enough to scale but small enough to give us attention).

• Engagement models (embedded teams vs siloed projects).

I score potential partners based on these factors.

[00:11:22]

Rich: Do you consider things like bench capacity or average employee tenure?

Ron: Bench capacity isn’t a specific focus for me, but I do ask what developers do when they’re not on a client project. If they’re building internal tools or templates, that’s a good sign. As for tenure, I don’t focus on how long developers have been at the company. Instead, I look at their overall experience and skills.

[00:14:00]

Rich: What about churn? How do you deal with turnover in outsourcing teams?

Ron: Churn hasn’t been a major issue for me. I’ve only had one developer leave a project because they left their company. Good partners will handle replacements smoothly, and I’ve even had cases where companies refunded me for subpar work.

[00:16:00]

Rich: What advice would you give non-technical founders trying to build a product?

Ron: Don’t go it alone. Get a fractional CTO or a technical advisor who can oversee the project. You need someone impartial who can ask the right questions and ensure the team is doing things correctly. I’ve seen too many projects fail because non-technical founders relied solely on software houses claiming they could handle everything.

[00:20:00]

Rich: How do you feel about fixed-price contracts?

Ron: They don’t work. Complex projects are unpredictable, and fixed prices lead to friction when scope changes or miscommunications arise. Instead, I prefer a pay-per-developer model. It’s more transparent and allows for adjustments as the project evolves.

[00:22:32]

Rich: For non-technical founders paying for time-and-materials, how can they measure productivity?

Ron: Measuring productivity is tough, even for internal teams. The key is open communication. Good partners will proactively check in with you, explain delays, and address your concerns. If you have a fractional CTO, they can help evaluate the team’s progress and call out any issues.

[00:25:11]

Rich: Let’s talk about Bounce. How have you applied your own advice to building the company?

Ron: Bounce helps e-commerce merchants deal with declined payments. Our system analyzes transactions in real time to determine if a decline is legitimate or a false positive. If it’s a false decline, we retry the transaction later or reimburse the merchant if our prediction was wrong. When we started Bounce three years ago, I followed my own playbook. I hired a trusted outsourcing partner to get the ball rolling while I built an in-house team. Over time, we reduced reliance on outsourcing but still bring them in for specific tasks like DevOps or data pipelines.

[00:28:00]

Rich: So Bounce helps merchants recover revenue lost to declined transactions?

Ron: Exactly. Around 7–10% of card transactions are declined daily, often due to fraud prevention measures or insufficient funds. Our system increases approval rates, improves conversion, and creates happier customers—all with zero risk to the merchant.

[00:31:00]

Rich: That’s incredible. Ron, thank you so much for sharing your insights and experiences.

Ron: My pleasure. If only my kids were this happy to hear my wisdom!

Rich: They’ll appreciate it one day. Thanks again, Ron.