1) It is tedious to code the layout and design of the PDF using code libraries such as FPDF, Prawn etc.
2) When it came to generating large no of PDFs it is difficult to scale.
3) Developer wants to focus on the core offering of their web product rather that spending their time on stuff like PDF generation, email, image processing, payments etc.
4) In cloud development model off-the-shelf components are preferred in the form of cloud services or cloud API over code packages or software. So PDF generation offered as a service instead of code library is better.
Targeting these assumptions Pagify offers a designer within the browser where users can design their PDF template and use an API to generate PDFs.
But after launching on HN and betalist we received mixed feedback on Pagify. Do you think our assumptions are correct? And does Pagify solve this problem?
Thanks, Kush.
That's a bit different from vanilla PDF generation, but perhaps a good portion of that is down to marketing. How you position this could be important. You've got your salesforce version - nice :-) That should mean you're selling direct to a business user, so have you worked out what their pain point is? Do they think of it as "generating PDFs" (you've branded it as "Great Reports", so obviously you think they don't!) I don't know anything about report generation on SF, but I'd be shocked if there wasn't already some competition - have you looked in to that? What's your point of difference?
Down to your assumptions: 1) I've only ever used FOP & yes it is tedious, but it gives you a lot of power, and that power is going to be hard to replicate.
2) Generating large no of PDFs is hard to scale. For a cloud service, though, you need to work out how you're going to deliver a large number of PDFs over the wire. (You'll easily be able to generate more bytes of PDF per $ of CPU than you'll be able to transfer per $ of bandwidth.)
3) That sounds like a safe assumption (almost a tautology).
4) I'm not so sold on this. If I can get equivalent functionality from a library, I'll use the library. I don't want to add a dependency on an external service (making my own service more fragile) unless it offers a significant benefit. Stripe saves me SO MUCH TROUBLE it's a no brainer. There's is no way I would even think of trying to replicate what they've got. The barriers are significant. What are the barriers to me using a library instead of Pagify? Not nearly as great.
Gut feeling, the SF report generation product is much more compelling, but check out the competition in that space.
That said, there might be a market there for developers, but you'll need to identify a very particular challenge that devs have and provide a much better solution than what they can achieve with a library in a day.
The concept here in designing a template to be filled later is a brilliant idea, but I think its the delivery of the product that may pose the biggest problem. PDF generation doesn't have the same level of complexity as video encoding or payments so when it is used, its expected to just work as the environment doesn't change.
This introduces what I think is the main issue, if I build a website for a client, as a developer I never want to see it come back with problems, so its not worth introducing the risk of a third party service for the sake of a few hours of tedious work. At the other end of the industry any company producing a webapp may have problems with this simply due to how fundamental the feature can be, PDF generation doesn't require the same infrastructure as video encoding or payments, so they will have very different tradeoffs. Your main problem here is that you have no competition so I have nowhere to go if you close and the design online feature is essentially a vendor lockin.
Your assumptions are right but they are what a developer wants, the decisions are mostly made by management where future risk is more important than short term convenience.
Personally I think this product in particular would be much more suited to being a standalone package.
But the main thing that drew me to PDF utilities was to programmatically fill out pre-existing PDF forms. With FPDI i would load in the form and then overlay the data on top of it. Not as easy as charts and tables, as some data exists as one line per row and other might have several lines per row of data. different positions, etc. (here's a fun form I had worked with: http://www.cdss.ca.gov/cdssweb/entres/forms/English/CD9600.P... depending of family size or care situation could be multiple pages...) If you can crack stuff like that in an easy-ish to use API, I think you would catch more developers interest.
It is tedious to code the layout and design of the
PDF using code libraries such as FPDF, Prawn etc.
You can try using FlyingSaucer (https://code.google.com/p/flying-saucer/) It takes in HTML and gives PDF. It also supports print related CSS3 properties and its open source. May be it cannot compete with Prince, but it is a good open source alternative
A competent developer can generate PDF's with the mentioned libraries rather quickly. We deal with a lot of PDF generation where I work, and it is not something that enters our minds to outsource because it's pretty fast and easy to do. For us, the generated PDF's do not need great design or layout, they just need the info in a printable format.
That said, you may find a better audience with less tech savvy users that have a lot of reporting needs. I can't really think of a target audience off the top of my head. Good luck to you.
Paging is quite painful. I am writing my own code to split tables to fit into pages.
If you can solve this problem. I would gladly pay.
http://ror-snippets.tumblr.com/post/40142053834/converting-h...
Imo only a subset of people have pdf generation needs (mainly devs)
This service would provide a good alternative, and regardless of what the developer is making, the price of the service would be far lower than paying the dev for the amount of time they spent futzing around with PDFs in PHP.