Are you thinking about implementing a web2print application? If it's a custom project for one of your large accounts, you can find some other posts on this site that point you in the right direction. But what if you want to create a single web2print solution for all of your end customers? Here are some things you will have to consider when starting the project.
Customization
A first very important question is whether or not you will accept customization for the web2print project. If not, there are a lot of solutions available with out of the box functionalities that might suit you. Our own DMP FLO Suite Web2print Edition is just one of them. But out of the box will only get you so far. If you want the web2print solution to integrate seamlessly with your existing infrastructure or with your wishes, you might want to consider a customized project. But even in this case, you typically find the web2print application that provides the closest match to your wishes.
Functionalities
Regardless of the decision on customization, you will need to gather the specifications of all of the functionalities you want to provide to your end customers. Will it be simple online submittal of PDF documents? Will it include stock orders? Do you want to include simple or complex variable data documents, maybe using more advanced features of InDesign Server? Direct mailing functionalities? All of these and many more will determine the direction you're going to follow.
Also consider the logical source of these functionalities. If stock orders are required, you will most likely need a direct link to your MIS software. And this almost invariably requires custom code to be written. Similarly if you want to implement a single sign-on system, where users log in with accounts from pre-existing solutions.
Interface
How will you want to visualize your web2print solution to the end customers? A few things are implied for any web2print application. First of all, it has to be really simple for the end user. They can't require a training or a manual. Secondly, at leas in most cases, you will want to skin each storefront for the individual end customer. Often this is simple replacement of colors and logos, but it might be more complex.
A problem of out of the box web2print solutions is that they need to be as simple as possible for the widest possible audience. While this is usually a good thing, it might not suit your needs. If your target audience is more specialized, they might require an interface with more features. While this brings more complexity to the solution, your target audience won't experience it like that. For them, the new features will make sense, and provide them with a better workflow.
Another issue is integration into existing applications. The out of the box web2print application will be one more application for the end user to log in to. So it might make more sense to integrate the web2print interface into your existing websites. In some cases this might be possible out of the box (by integrating the interface in iframes, for example). But more tight integrations often require some customization. This can mean a simple HTML integration, but it might go as far as building the entire interface in the existing solution (with webservices to the web2print solution to call the advanced graphical functionalities).
Output
Finally, you'll also need to identify all of the needed output formats for the web2print solution. In many cases the web2print solution will create PDF files, which are forwarded automatically to your production workflows (usually with JDF files). But maybe you will also need to connect separately to your accounting software. Or send reports to your customers.