How a Remote-First Insurtech Built a 30-Person Engineering Team Without an Office
Insurance technology is one of the most underestimated engineering domains in tech. The regulatory complexity (50 states, 50 regulatory frameworks), the actuarial modeling requirements, the real-time data processing at scale, and the customer experience expectations of an industry historically known for friction — these create genuinely hard technical problems that ambitious engineers find rewarding to work on.
A remote-first insurtech company came to us at 5 engineers with ambitious growth plans: 30 engineers in 18 months, distributed across US time zones, building the next generation of insurance infrastructure. No office, no geographic concentration, a domain that most engineers hadn't considered seriously.
The Starting Point: Why Remote-First Changes Everything
Most companies retrofit remote work onto a culture built around physical presence. True remote-first companies design for distribution from the beginning: their communication is written-first, their meetings are deliberate (not ambient), their engineering practices account for async collaboration, and their recruiting is geographically unconstrained.
For this company, remote-first was a feature, not a compromise. It allowed them to hire the best insurance domain experts regardless of where they lived (a real advantage in a specialized domain), reduce the comp premium required for SF/NYC-based talent, and build a team culture grounded in outcomes rather than visibility.
The Recruiting Advantages (and Challenges) of Remote-First
Advantages:
- Access to the full US talent market, not just major metros
- No geographic premium required (a senior engineer in Austin or Raleigh commands market for those cities, not SF premium)
- Easier to recruit experienced engineers who've built careers outside major tech hubs
- Strong signal for self-motivated, high-autonomy engineers (the profile that works well in remote environments)
Challenges:
- A harder pitch to engineers who've never worked remotely ("how does collaboration actually work?")
- Need to screen explicitly for remote work effectiveness — not all strong engineers thrive in distributed environments
- Employer brand requires more work (no "our SF headquarters" shorthand)
- Onboarding and culture-building require deliberate investment without the ambient learning of physical proximity
Sourcing for a Domain That Most Engineers Haven't Considered
The insurtech talent pool is less concentrated than fintech or AI. There's no "insurtech engineer" community equivalent to the Stripe or Plaid alumni networks. We sourced from three angles:
Engineers from adjacent financial technology. Engineers who had built for banks, credit companies, or investment products had the financial domain fluency and regulatory awareness that translated well to insurance. The product domain was different but the mindset was similar.
Engineers at established insurance technology companies. Companies like Guidewire, Applied Systems, and Duck Creek have been building insurance technology for decades. Their alumni often want to work on more modern stacks with faster iteration cycles — exactly what a remote-first startup offers.
Engineers from non-insurance companies who expressed domain interest. The interview question "what domain would you want to spend the next 3-5 years in?" occasionally surfaces engineers who have a genuine interest in financial services infrastructure and find the insurance problem space compelling once they understand it.
Screening for Remote Work Effectiveness
This was a deliberate part of the process. Not every strong engineer thrives in a fully distributed environment — and a wrong hire in a remote-first culture is more disruptive than in an office environment, because the lack of informal channels makes recovery harder.
Questions we used to evaluate remote-readiness:
- "Walk me through how you worked through a complex engineering problem with a remote teammate. How did you communicate about it?"
- "How do you decide when to write something down vs. when to pick up a call?"
- "Tell me about a project where you weren't co-located with anyone you needed to work with. What made it work or not work?"
We also looked at candidates' own communication quality in the recruiting process itself. Candidates who sent clear, specific messages, followed through on commitments, and managed their own process without reminders demonstrated the self-management skills that remote engineering requires.
The Results
| Milestone | Engineers | Timeline |
|---|
| Start | 5 | Month 0 |
| First 10 hired | 10 | Month 4 |
| Reached 20 | 20 | Month 11 |
| Reached 30 | 30 | Month 17 |
Offer acceptance rate: 76% (above market average, attributed to strong remote culture pitch). First-year retention: 91%. Geographic distribution: 14 states across 3 time zones. Average time-to-fill: 6.5 weeks.
Key Lessons for Remote-First Engineering Teams
The remote-first pitch needs to be specific, not generic. "We're remote-friendly" doesn't resonate. "We're documentation-first, we do one synchronous standup per week, we're thoughtful about what requires a meeting vs. an async thread" — that's a real pitch to engineers who've worked in poorly-run remote environments.
Screen for remote readiness explicitly. It's a distinct skill that correlates with but doesn't guarantee technical ability. Build it into your interview process rather than hoping it's implicit.
The geographic unconstrained hiring advantage compounds. The 5th engineer hired might have been unavailable to a non-remote company. By month 17, the compound effect of hiring from the full market (not just one city) had produced a team that would have been impossible to assemble in a single location.
Domain education is a recruiting tool. Engineers who hadn't considered insurance as a domain often became interested once someone explained the actual engineering problems. Don't assume non-insurtechs engineers have dismissed your domain — most haven't thought about it at all.
Why Recruiting from Scratch for Remote-First Engineering Teams
We help remote-first companies build distributed engineering teams — from writing the remote-readiness screening criteria to sourcing across the full geographic market. We work as an extension of your recruiting function, adapting our approach to match your culture and your candidate experience expectations. Start your remote team search →
Related: How to Hire Remote Software Engineers at a Startup ·
Engineering Talent Strategy for Hypergrowth Startups
Frequently Asked Questions
Q: Is remote-first harder to hire for than in-person or hybrid?
A: Initially more challenging (the pitch requires more explanation, screening is more deliberate), but the expanded talent market offsets this over time. Companies that invest in their remote culture and can articulate it specifically find that the hiring difficulty decreases as word of mouth builds.
Q: How do you evaluate a candidate's ability to work remotely if they've never done it?
A: Look for behavioral proxies: self-directed projects (open source, side projects), asynchronous communication history (quality of written communication in the process), and how they describe managing complex problems with limited supervision. Fully distributed work is learnable, but there are strong signals about who will adapt quickly.
Q: What's the comp delta for remote-first engineering teams?
A: Remote-first companies can often pay local market rates rather than SF/NYC rates for equivalent talent, resulting in lower total comp costs at equivalent quality. The tradeoff is that top SF/NYC engineers may expect SF/NYC rates even for remote work — be explicit about your comp philosophy upfront.
Q: Does insurtech require specialized industry knowledge to hire well?
A: For core product and platform roles: yes, domain familiarity significantly accelerates ramp time and improves product decisions. For infrastructure, data, and developer-experience roles: less critical — the technical requirements don't require insurance domain knowledge to execute well.
For the latest engineering compensation benchmarks, levels.fyi and The Pragmatic Engineer are the most cited sources.
