Moving Upmarket: What happens to a small team when the first insurer calls

There is a moment every software company experiences as it moves from serving small businesses to landing an enterprise client: the first inquiry from a real enterprise organization arrives, the team is thrilled—and two weeks later, a security questionnaire lands on the desk that is longer than your actual product documentation.

In our case, it was an insurance company. Until then, we won customers simply because the product was good. From that point on, that was no longer enough. Not because the product suddenly got worse—but because in this league, you have to answer a completely different set of questions. Small customers ask: Does this solve my problem? Enterprise customers ask: What happens if you go out of business tomorrow, if someone compromises your database, if our audit committee asks questions two years from now?

Going upmarket isn't about building a better product. It's about being able to prove what you're already doing.

The questionnaire isn't a hassle—it is the actual competition

The initial reaction in a small team is indignation: hundreds of questions about encryption, operational processes, disaster recovery plans, subcontractors, data deletion policies, tenant isolation—for a contract whose value seems almost laughable compared to the effort. You feel like you have to justify things you've been doing right all along.

The realization came later and was uncomfortable: The questionnaire isn't a hurdle before the sales process. It is the sales process. In regulated industries, buyers don't choose the best product—they choose the best-documented one. Delivering clean, complete, and transparent answers builds trust—not because the responses are mind-blowing, but because how you answer demonstrates how you'll operate when things get serious.

What changed as a result: We stopped treating every questionnaire as an isolated incident. Once properly documented, the next questionnaire takes days instead of weeks. That investment didn't pay off with the first customer—it paid off with the third.

What a small team goes through during this shift

The most underestimated part of this phase isn't technical—it's human. A small, double-digit team used to making decisions in days encounters an organization where scheduling a meeting with the security head takes six weeks of lead time and approvals run through three separate committees.

Three things happen at once, and all three take a toll:

• The sales cycle stretches. Weeks turn into quarters. This isn't just a cash flow issue—it's psychological: A team used to celebrating a deal every week suddenly goes months without a win.
• Your best people get tied to a single customer. The person qualified to answer security questions is usually the same person building the product. For the duration of the RFP, product development effectively comes to a standstill.
• The temptation to promise everything grows. Every custom request feels doable in the moment. You say yes because the deal is huge—and a year later, you're maintaining a custom solution nobody else needs.

The third point was the costliest for us. The difference between a product company and an agency isn't size—it's how often you say no. We didn't learn that right away.

Why the smaller player can still win

The obvious assumption is that the largest vendors always win RFPs. In practice, that happens less often than you think—and the reasons have very little to do with feature sets.

Accessibility. With a enterprise vendor, the customer speaks to an account manager who then talks to a team in another time zone. With us, they spoke directly to someone who could solve the problem themselves, in the same time zone, speaking the same language.

Commitment. A massive vendor can't promise a feature will be delivered next quarter—their roadmap is global. A smaller company can, and credibly so. That's a real advantage, as long as you don't overextend yourself.

Data residency and legal frameworks. For a Swiss insurance provider or a cantonal bank, where data is hosted and which jurisdiction applies isn't a minor detail. It's not a marketing angle—in many cases, it's the cost of entry.

What the smaller player can't win, however, is a feature-by-feature comparison. If you get into a feature checklist war with an enterprise competitor in an RFP, you've chosen the wrong battle.

The hidden cost almost nobody accounts for

Going upmarket costs more than the obvious line items. Certifications, legal counsel, additional contracts—you can budget for those. What's hard to budget for is reshaping your entire organization.

You need processes nobody needed before: approvals, documentation, disaster recovery drills, proof of things that previously just worked. To a founder team, that feels like bureaucracy—and part of it is. But the other part is the prerequisite for a company to function without the founders in the room. I realized that connection quite late.

Then comes an unavoidable decision: A product built simultaneously for solo entrepreneurs and enterprise corporations will end up worse for both. At some point, you have to choose who you're optimizing for—and that means consciously taking focus off part of your existing customer base. That's uncomfortable because it directly affects the very customers who got you off the ground.

What I would do differently today

Document earlier, not just on request. Security and compliance documentation isn't sales collateral—it's infrastructure. Having it ready before the first questionnaire arrives significantly shortens your first enterprise deal cycle.

And prioritize more honestly: Not every enterprise inquiry is a good opportunity. A deal that ties up six months of development and leaves behind a custom one-off solution can be far more expensive than walking away. We didn't run those numbers early on because the contract value looked so appealing.

What I wouldn't change: taking the leap itself. Not because of the revenue—but because a company that stands up to an insurer's requirements is a different company afterward. You would never build the necessary processes otherwise. And the questions a chief security officer asks you are almost always better than the ones you asked yourself.