Besides improving our flagship product SmartInspect, we’ve started working on a completely new product a few months ago. We aren’t ready to announce what it is just yet, but we will hopefully be able to share some early screenshots and more information in the coming weeks on our company blog. Our next product will be delivered as an installable web application. Similar to applications such as FogBugz or WordPress, customers will be able to download our application and install and host it directly on their servers. We decided to go with an installable version of the product first (instead of offering it as a hosted solution), because we believe that our target market still prefers to host their sensitive data themselves.

One of the first decisions we had to make regarding the product was to choose a development stack. This sounds easier than it really is: there are quite a few requirements that a development stack and platform has to meet in order make it suitable for an installable product. When you develop a hosted solution, you don’t have to care so much about things like ease of deployment, cross-platform support or support for multiple databases. Other requirements such as Unicode support are also a lot easier to implement if you can control every little detail of the run-time environment. So these are our main requirements for an ideal development stack:

  • Ease of deployment
    Because our customers have to install the application themselves, it must be very easy to deploy. The application will of course come with a convenient installer to setup a database, configure the initial settings and so on. However, a platform with complex dependencies should be avoided as it would cause endless support headaches and would make it much harder for customers to evaluate our product.

  • MVC framework
    We have been using different frameworks and patterns for web development over the years and we strongly believe in using the MVC pattern for building web applications. Our ideal web development stack comes with a solid and clean MVC framework to make it easier to build a maintainable application.

  • Cross-platform
    We fully expect that 80%+ of our customers will install our web application on a Windows server (those are still extremely popular for internal application and workgroup servers). However, to make it easier for us to offer hosted trials (or even fully hosted application instances), we also need the application to run on Linux machines. Linux support is also handy for customers with distributed teams who want to host our application on cheap dedicated Linux servers on the net.

  • Multiple databases
    Similar to the cross-platform requirement, our development stack of choice should support multiple databases. Many companies already have a preference for a certain database (because it’s already installed, maintained and backuped etc), so having easy-to-use support for multiple databases is a big plus. We initially plan to support MS SQL and MySQL only, but we might add support for additional databases such as PostreSQL in the future.

  • Support for Unicode and localization
    In an ideal world, every application would have great Unicode and localization support. In reality, though, many applications (and web frameworks) still have a lot of problems with non-Western characters, languages and locales. To make our application suitable for an international audience, good Unicode and localization support in a web framework is key.

  • Safe future and strong community
    Of course, the ideal development stack and platform has a strong and clear future. However, it’s not easy to tell which technologies have a safe future. Open platforms with a strong community certainly have better chances to survive in case the owner or original organization behind it loses interest.

I can already reveal that none of the evaluated platforms and frameworks met all our requirements. Some platforms make it really easy to deploy applications and have excellent Unicode support, but fail the cross-platform requirement at the same time. Other frameworks and stacks provide great cross-platform support, but have really bad support for Unicode.

If you are planning to build a web application yourself, make sure to read the upcoming second part of this series to learn about the pros and cons of the available development stacks and platforms (if you haven’t subscribed to this blog yet, here’s the feed). I will also reveal which development stack we have chosen and explain the reasons behind the decision.

Related posts:

  1. Choosing a Development Stack for Installable Web Applications: Part II

Found this article useful? Make sure to subscribe to the No bug left behind feed or via email and don't miss our future articles about software quality, performance, usability and related topics. This blog also features the regular Software Quality Digest with links to relevant articles, discussions and other resources.

4 Responses

  1. Rob Kinyon Says:

    Have you considered Catalyst (MVC) + DBIx::Class (ORM) + Moose (OO)? This is a Perl stack with a huge community of developers behind it.

  2. Dennis Gurock Says:

    Hey Rob,

    we haven’t considered Catalyst when we looked at available frameworks. I will make sure to consider it for a future project, as it looks quite nice. I’m not so sure if I really want to use Perl for developing an entire product though.

  3. Rob Kinyon Says:

    Dennis -

    I’m curious – Why not use Perl for developing an entire product? We hear that a lot from non-Perlers and it seems to be a very odd statement to make. What exactly is it about Perl that turns you off?

    Thanks,
    Rob

  4. Dennis Gurock Says:

    Rob,

    I have thought about the reasons myself when I posted my comment, and I think it boils down to the fact tht I actually know no one who is building a full product with Perl myself. For most other web technologies, be it ASP.NET, Rails, PHP, Python, Java .. I know multiple people who successfully use it, and this makes it a lot easier to go with such technologies. I know it’s probably rubbish and I’m sure that there’s nothing wrong with Perl from a technology standpoint (at least I’m sure it’s superior to PHP, which has quite a few technical problems, although it’s extremely easy to deploy). And I also used Perl in the past (not for web stuff though), but for me, even if it’s probably not really justified, Perl sounds like a legacy technology that I probably wouldn’t choose to build a new product.

    Regards,
    Dennis