Congrats on launching! This seems like a great product! I have seen use cases where something like this could come very in handy. I don't know if this is useful but I'd be worried about using this library because: the difficult to adhere to pricing scheme, the high cost for the level of market saturation, and lack of quality support.
Since you're building a library, not a tool, whenever I hire an engineer they'll automatically be using this tool and I'd need to remember to send you more money. The only other products that I have to do this with are either:
1. Monthly subscriptions that automatically charge me the correct amount of money.
2. GitLab which tracks how much I owe the developer and charges me the correct amount of money the next time around.
I'm concerned that I'll pay for this software, download a .js file, check it into my repo, hire a new developer, and completely forget they're using this product.
The biggest difference between this tool and my currently paid-for software is that it has no "check-in" period. I could very easily imagine a scenario in which I violate your license. Here are two:
1. I, as an engineer on a single project in a large company, buy your software and use it in a product. I move on to other stuff and get asked to write new features after a long time completely forgetting your software was paid-for. Me and another engineer start working on the project. We now have 2 devs.
2. Another engineer sees me building a cool project. They copy my frontend as a starter for another feature. We now have 2 devs in a multiproject license.
3. We have the correct multi project license for the correct number of devs but we want to hire some contractors for some cheap work. Hiring these contractors just became a lot more expensive.
As for the pricing, at 54,100 EUR ($62,444.87 USD) for a 50 person team, you're competing with a sizable chunk of an engineers salary. Depending on what part of the world you're in you can pay for 1 quarter to 1 years worth of an engineers time with this chunk of change. It seems you're setting yourself aside from the competition because of performance reasons. If that is the large differentiated factor I'd be thinking the following as an engineering manager:
1. Given the timeline (3 months to 1 year) can I build my own implementation of this product?
2. Given the timeline can I take an open source implementation that has more features, use it until there's a performance problem, then have one of my 10x engineers tweak it to make it perform better?
3. Can I find another paid-for version of this library that will be cheaper? In this very HN post there's another implementation of a similar product with a seemingly similar feature set that is substantially cheaper [0] that is also source available.
So, when I'm crunching the numbers, and have to choose to Build, Tweak, or Buy at a cheaper price, it's hard to justify this product. What makes it even harder to justify the product is the support limitations. The main reason to never choose build or tweak or "buy the cheaper one" is because it won't save you any time. Your support page makes it seem like, however, I'll have to put a lot of time and effort into bending over backwards to make a support request that fits your model. This makes the comparison:
1. Build XYZ and support it
2. Tweak XYZ and support it internally
3. Buy your software and get very non-specific support
Since you're building a library, not a tool, whenever I hire an engineer they'll automatically be using this tool and I'd need to remember to send you more money. The only other products that I have to do this with are either:
1. Monthly subscriptions that automatically charge me the correct amount of money.
2. GitLab which tracks how much I owe the developer and charges me the correct amount of money the next time around.
I'm concerned that I'll pay for this software, download a .js file, check it into my repo, hire a new developer, and completely forget they're using this product.
The biggest difference between this tool and my currently paid-for software is that it has no "check-in" period. I could very easily imagine a scenario in which I violate your license. Here are two:
1. I, as an engineer on a single project in a large company, buy your software and use it in a product. I move on to other stuff and get asked to write new features after a long time completely forgetting your software was paid-for. Me and another engineer start working on the project. We now have 2 devs.
2. Another engineer sees me building a cool project. They copy my frontend as a starter for another feature. We now have 2 devs in a multiproject license.
3. We have the correct multi project license for the correct number of devs but we want to hire some contractors for some cheap work. Hiring these contractors just became a lot more expensive.
As for the pricing, at 54,100 EUR ($62,444.87 USD) for a 50 person team, you're competing with a sizable chunk of an engineers salary. Depending on what part of the world you're in you can pay for 1 quarter to 1 years worth of an engineers time with this chunk of change. It seems you're setting yourself aside from the competition because of performance reasons. If that is the large differentiated factor I'd be thinking the following as an engineering manager:
1. Given the timeline (3 months to 1 year) can I build my own implementation of this product?
2. Given the timeline can I take an open source implementation that has more features, use it until there's a performance problem, then have one of my 10x engineers tweak it to make it perform better?
3. Can I find another paid-for version of this library that will be cheaper? In this very HN post there's another implementation of a similar product with a seemingly similar feature set that is substantially cheaper [0] that is also source available.
So, when I'm crunching the numbers, and have to choose to Build, Tweak, or Buy at a cheaper price, it's hard to justify this product. What makes it even harder to justify the product is the support limitations. The main reason to never choose build or tweak or "buy the cheaper one" is because it won't save you any time. Your support page makes it seem like, however, I'll have to put a lot of time and effort into bending over backwards to make a support request that fits your model. This makes the comparison:
1. Build XYZ and support it
2. Tweak XYZ and support it internally
3. Buy your software and get very non-specific support
[0] - https://rowsncolumns.app/pricing