Main idea

Once you accept that some blocks have to be handed to the customer, the slope is to build everything: Azure, AWS, GCP, SQL Server, PostgreSQL, Oracle, five model providers, three email gateways, four SMS gateways.

The question that produces this catalogue is "what can we technically support?". It always has a generous answer, and it is the wrong question.

The other question is "what do we need to support for the customers we've chosen to serve?". If nearly all the large accounts being targeted are already built around Microsoft, starting with Azure and SQL Server is justified — not because it would be technically superior, but because it is what maximizes the ability to sell into that market.

Why it matters

Breadth of support is paid for indefinitely: every supported technology is a variant to test, to document, to troubleshoot. A catalogue built on feasibility creates permanent debt in the name of hypothetical customers.

And exhaustiveness doesn't read as a strength: it often signals that no market has been chosen.

Nuances and limits

The target segment shifts, and a breadth calibrated on yesterday's segment becomes a constraint. The rule requires reopening the question, not settling it once.

And a customer outside the segment but very important can justify an exception — owned as such, and priced.

Open questions

• At what proportion of out-of-segment requests should you reconsider the positioning itself?