What are some common things to consider when developing a web-based application to be sold [closed]

Question

I'm developing an application for an internal customer. One of the requirements is that it be developed in such a way that it could potentially be sold to other organizations. The application is a tracking application for a fund-raising organization that will manage their donations, donors, participants, and events. I already know that I'll need to develop a plugin architecture for authentication (authorization will be handled internally) and to derive demographic data from an external directory.

The application will be built on ASP.NET/C#/Linq/SQL Server. At this point I'm not really open to supporting alternative databases, but I'm thinking I could do this in the future via different Linq drivers, if necessary.

All of the web applications that I've built to date have been custom implementations so I'd like to know if there are other things that I need to address via plugins and/or configuration items. Any input would be helpful.

Thanks.

Answer 1

I want to caution you against trying to make the "do everything" framework. This is a common mistake that a lot of developers make when trying to build their first few mass-market software apps.

You have a customer already, and they are likely bankrolling the initial version of the application. You need to deliver as much of what this customer needs as fast as you can or it fails before you even get to thinking about the mass-market.

Do yourself a favor and expect that this is the only customer that will EVER use or buy the application. Design your application pretty much the exact same as you would have designed any of your other custom apps in the past.

All you need to do in order to scale it out to other customers later is to stick to the stock asp.net features and functionality as much as possible, keep it as simple and lean as possible, and cut as many "advanced" features from version 1.x as you can get away with.

1.x will be your proving ground. Make sure you deliver an application that does what your initial customer needs it to do and that it does it exceedingly well.

If you are successful, and 1.x does actually meet most of your initial customer's requirements then you will know you also have an application that will meet most of the needs of any of your customers. Congratulations, you are already most of the way towards having a viable commercial market application!

Things to watch out for:

1. Do you really need to support multiple database platforms? Sure, you might have "some" customers that might "prefer" MySql to SQL Server. You will be tempted to try and write some magic DAL that can support Oracle, MySQL, VistaDB, SQL Server, etc. just by changing some config options or making the right selection in an installer. But the fact is that this kind of "platform" neutrality adds massive complexity to your design and imposes severe limitations on what features you take advantage of. Things like the provider design pattern may fool you into thinking that this kind of design isn't so hard... but you would be wrong. Be pragmatic and design your application so that it will be acceptable to 90% of your potential market. With data access in particular it is generally safe to say that 90% or more of the market willing to install and run an ASP.NET application are also capable and willing to use SQLExpress or SQL Server. In most cases You will save much more money and time by designing for just SQL server than you will ever make in additional sales from supporting multiple databases.

2. Try to avoid making "everything" configurable via online admin tools. For example, you will be tempted to have ALL text in the application configurable by admin tools. That's great, but it is also expensive. It takes longer to develop, requires that you increase the scope of your application to include a whole mess of admin tools that you wouldn't have otherwise needed, and it makes the application more complex and difficult to use for the 90% of your customers that don't mind the default text.

3. Carefully consider localization. If you don't think you will have a large international market stick to one language. Localization isn't too hard, but it does complicate every aspect of your code a little... and that adds up to a lot in any application of any size at all. My rule of thumb is to target only the language of my initial market. If the app has interest in other markets then I go back and do localization in version 2.x after I recoup some cash from version 1.0 and prove the application has a viable market in the first place. But if you know you will be in more than one language or culture, support localization from the very beginning.

4. For version 1.0, don't worry too much about drop-in modules or fancy service APIs. If you already had a lot of experience in reusable frameworks you would be able to have this stuff in version 1.0, but if you lack experience in this kind of architectures you will just waste too much time on these features in version 1.x and you will likely still get it wrong and have to re-architect in version 2.x anyway.

5. Make sure the application has REALLY good reporting. For the kind of application you are talking about, this will be what decides if the application even has a market at all. You need pretty reports that are not only sortable/filterable on screen, but are also printable. Put your money and time into this out of the gate.

Answer 2

The most important thing is to design it in such a way that it is completely generic i.e. there is no client specific information hard coded or embedded.

Anything client specific must be configurable through meta-data. How you do this is completely up to you, but the main ways are through XML, Database or properties files.

If you design it this way it could be on sold to any number of clients who will each have their own configuration files or data.

Answer 3

Abarax gave a great answer, I'd emphasise that you should consider Localisation - both for spoken languages (english, french, german, etc) and the Organisation's language e.g. some places may call it a Timesheet, Docket or Work Order, and each one will whine and whine and whine if everything doesn't match up with what they've always called something.