[abxyz]

isn’t this self-inflicted in that you’re making the purchase process a sales process for everyone, instead of being self-serve for the little guys? e.g: for teams under 10 people, let them sign up monthly with a per-team member fee. $50/month per team member feels like nothing compared to $6,000/year. I read $6,000/year as “we don’t want your business” because what startup is paying 1 year upfront for anything? They’ll probably be dead in 6 months.

There is a big difference between how startups buy and how enterprises buy, but it seems you’re treating them as equal in everything except budget.

Anyway, easy for me to say that, I have no stake. You know your customers… but as sales-aware observer, it seems very counterintuitive to make low budget people go through a sales process.

[steveruizok]

I'd like to do self-serve pricing like that, maybe we will in the future, but I don't think there are as many teams as you think where the difference would be a deciding factor.

When I was doing pricing discovery and asking early adopters what they would pay for tldraw, almost all the teams I talked to either said "nothing because we don't have any money yet" or a number between $5,000 and $10,000, with a handful of outliers. In the end, my solution was just to put a price on the thing and then find ways to provide for everyone else, including PRPF commercial teams. In 3.x our solution was a watermark, which caused other problems for us; but this discussion made it pretty clear to me that we need to have a better answer for these teams in 4.x.

That said, we've at least got the startup sales _process_ as close to self-serve as we can. Someone still needs to validate the size of the company and send a Stripe link, but 20% of startup licensees were delivered in under 24 hours and more than half are done in under a week.

[abxyz]

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.

[max1990]

Completely agree. A manual sales process is a huge friction (per the CEO's comment above it takes more than 50% of startups over a week to buy tldraw!). And no visibility into scale pricing is a risk no company should take.

It's a great product - charge for it for sure - you need to be comercially viable. BUT, imho it's madness to make it so difficult to buy and have opaque pricing. It's a path to stagnant reliance on a handful of big customers while somebody innovates from under you and takes the market. Comfortable for a while, and then no business.

[max1990]

I agree $6k upfront for startups is a lot (especially if they're just riffing).

But the bigger issue is there's no clarity of what this will cost if the startup works out and grows. So you spend a bunch of dev time building something that uses TLdraw and then its completely unknown if you can keep using it in the future as the cost could be $1 or $1 billion.

Any startup would be crazy to depend on a service with unknown pricing.

Sure you can email them and get the pitch by a salesperson, and use a bunch of time to get some long legal agreement with pricing in it somewhere, but that's what you do for massive custom-built enterprise tools. Not for on SDK in your stack. I don't think the opaque pricing model is common or viable for this kind of SDK. Imagine if payments providers or authorization providers or hosting all just had blank pricing and a "talk to us" button.