How much implementation can happen before the sale?

Current position — September 30, 2026

An insurance software sale usually contains a promise: once you buy, implementation will reveal how the system fits your business.

I want to move that moment of truth forward.

What if the first sales conversation also began discovery? Documents collected between meetings could become inputs to an inspectable product configuration. By the next conversation, the customer could react to their own product, its journeys and its unresolved decisions.

The useful output would be more than a convincing demo. It would be a versioned proposal: here is what we understood, the evidence behind it, the rules we configured, and the questions that still prevent activation.

That changes the role of the insurance core. An AI agent can help interpret a conversation or assemble a journey. The core must give those actions a precise meaning. Which product version is being changed? Which fields are required? Who may approve the change? Which tests establish that the result behaves as intended?

A generated screen cannot answer all of those questions. Neither can a database that merely stores the latest values. The opportunity I see for Facio is to connect insurance meaning, governed changes and evidence of correct operation in a foundation that agents can use.

This also changes how I think about responsible automation. Adding a human checkpoint to every step can leave the original bottleneck intact. Instead, each class of action needs an explicit authority boundary, validation requirements and a response when evidence is missing or contradictory. Some actions can proceed within those boundaries; others need escalation. The boundary itself must be tested.

There is a business question underneath this architecture: if generating software becomes cheap, what is an MGA paying for?

My hypothesis is that buyers will pay for a dependable path from business intent to an operating insurance product. That includes maintained insurance definitions, integrations, controlled releases and the ability to explain what happened when something goes wrong. An open SDK could make that foundation easier for outside agents to use; a managed service could take responsibility for running it reliably. Those are directions to test, not a settled business model.

The test should be practical. Compare the time from first discovery to a customer-accepted configuration, while separately measuring staff effort, customer waiting, rework and defects. A fast demonstration is useful. A repeatable, accepted result is stronger evidence.

The question I want to explore is simple: how much implementation can we complete while the customer is still deciding whether to buy?