Thank you for the insight.
I think that your blindspot is that you are defining your pricing based on conversations with the subset of customers that are willing to enter into a sales process. Engineers being sales-averse has become a meme but it is rooted in truth: many engineers do not want to be sold to. And many product-defining choices are being made by engineers. The success of the bottom-up sales strategy for selling software shows that there is a lot of money to be made by making it easy for engineers to buy.
(My startup spends more than $6k/year on a number of valuable services but I would not have selected the services initially if they required a sales conversation and upfront commitment. Even today, knowing I will spend more than $6k on these services in the next 12 months, as I have in the last 12, I would not commit to paying them $6k today. From my own experience, I'd estimate that that 75% of B2B software subscriptions are monthly, even when an annual plan (with an aggressive discount) is available.)
Tldraw is the best product in the space by far, and an obvious choice for any company building a product that needs a canvas, but your current pricing is a big gift to Excalidraw (and others). Every engineer is going to be thinking about forking over $6k in cash before they decide to run `npm install tldraw`. And unless tldraw is a choice being dictated to them, $6k is going to seem like a very big number they are going to have to justify. During my time as an engineer-employee, I had no defined budget: asking for $6k to be spent on something upfront would be very daunting (even compared to asking for a subscription that would amount to $6k/year).
Tldraw is the canvas SDK but that could change quickly if Excalidraw capitalize on your pricing. If Excalidraw is free to use, and Tldraw is $6k upfront, Tldraw will become the product people try after being disappointed by Excalidraw and convince themselves that Tldraw's superiority is worth an additional $6k spend. You go from being the default to the expensive alternative. Being the default is a golden goose, being an expensive alternative is an uphill battle.
As engineers we feel that because we can, we should, and that's why we want to validate numbers, we want a system that does everything and requires zero trust. And I believe that is likely influencing your thinking about self-serve. Yes, some customers will lie when going through self-serve to keep their bill low, but once Tldraw is integrated into their product, you have leverage to get them paying the right amount. Schedule an account review for every self-serve customer after 6 months. If they look like they might be underpaying, reach out, and get them paying the right amount. When the alternative is ripping out Tldraw, paying thousands of dollars more per year is an obvious choice to make.
If I were commercializing Tldraw, I would be selling it self-serve at $100 per month per developer. I would do away with the trial, and emphasize that the open-source version is free to use in development. I would expect customers to purchase once they are ready to go live in production. I would let customers declare their team size when purchasing. Every 6 months I would review subscriptions, reaching out if the numbers look off.
I would probably drop the 10 team size limit too, and instead make the business subscription more valuable to larger teams. If I have a team of 10 developers working on a product containing Tldraw then I am spending millions of dollars per year on their time. If I can save 1% of that time by having access to support from Tldraw's team, my team can spend their time on the parts of the product that matter. An extra $150 per month per developer ($250/month/developer) would be an obvious choice if it could save each developer a couple of hours per month.
Your product is fantastic and worth far more than $6k per year but getting $6k per year for it requires finesse, not just a decision that $6k is the right number. Anyway, I am just a person writing 500 words for free on HN so caveat emptor.