4 ms·
I have a startup and we are highly reliant on PDF rendering in our application. But here's the thing, Nik: your pricing model doesn't make sense to me. In gener
by 2pointsomone 7y ago
I have a startup and we are highly reliant on PDF rendering in our application. But here's the thing, Nik: your pricing model doesn't make sense to me. In general, most PDF SDK models don't make sense. I have searched a lot over the years, and am left consistently disappointed.
You charge the same amount to large commercial customers as you do to small startups, who are trying to save every penny. Even though I really value the technology you have built, you have not allowed us to "pay-as-we-go". I am not interested in your trial and the trials of your competitors because you don't allow me to start with a $5/month plan based on volume of usage. And so, we have resorted to writing the wrappers around PDFJS ourselves, slowly and steadily over months and years. Even though we might end up spending the same amount over 2 years by doing these things ourselves, at least we will understand the technology and own it perpetually.
Just charge us based on volume, so your revenue can align with our revenue. It will create much larger traction among small developers. If you are not targeting that audience, I understand, but I contend that most people on places like HN are that audience. Be more like Crocodoc (the company Box acquired). I really don't want us to keep reinventing the pieces here because this is not our core competency.
- cl42 7y agoHave you thought of turning your wrappers into a service/SaaS offering? Sounds valuable!!
- spankalee 7y agoOr open sourcing it? This seems like one of those complex-enough areas that having multiple groups and companies contribute to a common good could really pay off for everyone.
- cl42 7y agoYes! +1
- 2pointsomone 7y agoI agree with both of you. Our wrappers are currently very tightly glued to the rest of the product, and have a lot of hacks (hint: PDFJS documentation is not very rich, they have barely touched their documentation since they came out). So what we have is in no good state to release, unfortunately :( But if someone does initiate serious work, we will jump in with our contributions. But to your points: because there is no good open source initiative that does what PDFJS Express does, commercial providers like PDFJS Express and PSPDFKit are able to build pricy SaaS offerings.
- williamstein 7y agoI agree. I would definitely love to integrate (and improve) this as part of my SAAS product, and I would spend way more than $400/year in effort on it. However, I can't possibly use or buy this as is, because it isn't open source. For comparison, my company pays for the CodeMirror "moral license"...
- 2pointsomone 7y ago$400/month is what PDFJS express is charging. $400/yr would have been a little difficult to swallow too, but this amount is just absurd for a product where most of the underlying technology is open-source.
- mkl 7y agoPdf.js Express is US$375/month, or US$4500/year.
- transitivebs 7y agoNo, it's $440 / month if you look at the actual pay-per-month option.
- williamstein 7y agoWow. This will be a good example in GPL versus MIT license debates...
- robocop2018 7y agoActually express is already open sources ( see other messages ) and will be licensed under dual commercial/AGPL terms ... like iText ( bit.ly/2JD0Yj0 ), another popular PDF OSS
- phonon 7y agoActually it's NOT, you're quote "working on it". Stop spreading misinformation. Right now it's 100% commercially licensed in a public repo. Not open source in any way, shape, or form.
- ChicagoBoy11 7y agoI want to say there was something that reached pretty high on the HN front page a few days ago that discussed SaaS pricing models and they made this exact same point! Aligning incentives between you and the customer just makes sense, as your comment clearly demonstrates!
- molsongolden 7y agoAligned incentives (we help you grow and succeed, we share the reward) has also come up in interviews and discussions as one of Stripe's greatest strengths.
- niknikson 7y agoThe biggest challenge to pricing based on volume is the exercise of tracking usage. In a typical SAAS product determining usages is fairly linear. For PDF.js Express because you would be deploying from your environment we would not have an accurate way to measure usage. Fundamentally I agree with you - you should pay for what you use. Unfortunately at this time we are not able to implement that effectively. Also keep in mind for some organization the value created from this product will far outweigh the final price tag.
- 2pointsomone 7y agoGood point. What if you have two models: - One: the model you have right now. this is for organizations where the value outweighs the price tag. - Two: Smaller organizations are generally also more willing to compromise on JS/asset bundling and performance. Why don't you give them: - a hosted JS solution where they just have to include a <script /> tag - An uglified script. I'd argue most JS developers can't unscramble these - you keep counters on number of requests - you disqualify (using some basic hashing method) run-ability of PDFJS Express based on the time the script was requested OR if an acknowledgement from a server fails. So say, if someone is using a cached version, the script will either not run at a certain point OR all the documents will be watermarked with "TRIAL". This second way could also be the best way for getting people started immediately. Include a tag, see a watermark, but you are ready to go.
- lukevp 7y agoThe watermarking is how Google Maps does it. It shows "development only" on the maps if the keys are not set up right or are over their limits.
- richardkeller 7y agoWhat about doing something similar to JetBrains, where you offer the product at a significantly discounted rate to startups, rather than based on usage? You would have 1 new customer immediately.
- martin-adams 7y ago