[2pointsomone]

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.

[ChicagoBoy11]

I 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]

Aligned 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]

The 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.

[martin-adams]

As a startup founder, here are a few alternatives that I would prefer.

1. Community edition - no direct support, maybe some enterprise features no available (like Sencha.com)

2. Hosted version - easier to PAYG with a lower price point per use (like Typekit)

3. One off purchases with updates for just 12 months. Updates then require licensing (like Sketch)

The other option is that you only got for enterprise and exclude the startup and indie developers. Enterprises tend to have no issue doing the right thing. If you're worried about smaller developers taking advantage, then you need to weigh up the long term benefits.

Just remember, if it's hard to do, it doesn't automatically make the wrong choice the right choice.

[2pointsomone]

Good 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]

The 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]

What 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.

[cl42]

Have you thought of turning your wrappers into a service/SaaS offering? Sounds valuable!!

[spankalee]

Or 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.

[2pointsomone]

I 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]

I 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]

$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]

Pdf.js Express is US$375/month, or US$4500/year.

[transitivebs]

No, it's $440 / month if you look at the actual pay-per-month option.

[williamstein]

Wow. This will be a good example in GPL versus MIT license debates...

[robocop2018]

Actually 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]

Actually 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.

[cl42]

Yes! +1