The Never Ending SaaS/Web App development Story

The development of a new SaaS /Web app often takes longer than you want or expect. The problem is the devil is in the detail. And it takes time to get the small things right. Unfortunately most bootstrapped startups have very little time to get customer traction and revenues before the money runs out.

The main causes of website/ Web app  development delays are an unrealistic  project scope, not enough time for the finishing touches and late engagement with potential customers. From our startup experiences of building a website monitoring SaaS/web app keeping focused and realistic can go along way in saving time.

Developing  the dream (The Never Ending Story movie)

The five main reasons for SaaS/Web development delays:

1. Lack of resources – Obvious I know. After a lack of paying customers this is the biggest problem for most bootstrapping startups. Insufficient resources combined with an overly optimist project scope result in development delays. Startups need to be realistic  and minimal with their first version.
2. Feature creep – Developing software is dangerous. Its so easy to dream of what it could do. ‘Would’nt it be nice/cool’ features just keep being added into the work list once started. The downstream  effect can be very painful: constant delays in releasing, a half baked/unfinished app being released or the app never sees the light of day. Keep it simple!
3. Bug, bug & more bugs – Despite the tedious nature of regression testing and bug fixing it has to be done. As Paul Graham says,  “Users hate bugs, but they don’t seem to mind a minimal version 1, if there’s more coming soon.” We’ve found that fixing immediate code problems in-flow is the most effective way to to minimise bug fixing time in the long run.
4. Those little things – They take much more time than you think. Ryan Carson referred to them as Teaspoons: “You know when you are doing the washing up and you think you have done everything but then get to the bottom of the bowl and find 15 little teaspoons hanging around, and they take ages to finish! That’s us… lots of niggly little fixes, tweaks, minor design improvements.” Startups must allow the time to finish the job.
5. Customer engagement – Rather than adding in features you like or think would be useful get the app out with potential customers. Let them lead the way. Beta testers and potential customers will show you new unidentified needs. This way time is not wasted on unneeded features. Remember Release early and release often.

Towards the end of developing a new SaaS/web app it sometimes feels like you are taking one step forward  and then two back. Finishing a product is not simple. It’s time consuming and requires a big final push of effort and resources.

Once an app is out it’s only the start of the development story. An app is never really finished. It can always be improved, refined and optimised. It’s a continuous process. Enhancements, new minor and major features  will be needed to keep customers satisfied and to stay ahead of the competition. Its a Never End Story!

Sanity check your Web App dev strategy with Dion Hinchcliffe – PART 2

In my followup to PART 1 of this post I have listed Dion Hinchcliffe’s next 25 recommendation for developing a web app strategy:

Is your Web Architecture made from a house of cards?

1. Monetize every page view (26.) – As a SaaS app will be charging a monthly subscription service fee. So, no ads.
2. Users’ data belongs to them, not you (27.) – Tell Facebook this! We intend to enable customers to export their historical data as part of our service.
3. Go to the user, don’t only make them come to you. (28.) – Great ideas for creating Facebook applications, OpenSocial gadgets, and enabling use from mashups. Huddle.net have successfully taken this approach with Facebook, LinkedIN,etc.
4. SEO is as important as ever, so design for it (29) – We’ve learnt alot from this blog and E20portal.com on data URL address-ability.
5. Know thy popular Web standards and use them (30) – We think open standards is the future, so embrace it 😉
6. Understand and apply Web-Oriented Architecture (WOA) (31.) –  We are using a leading proven and stable web-app development framework for rapid dev and differentiation. We understand the need for standards for customer interaction.
7. Online products that build upon enterprise systems should use open SOA principles (32.) – SOA is not a factor for our service.
8. Strategically use feeds and syndication to enable deep content distribution (33.) We intend to offer feeds for key data points that matter to our customers. Our customers’ feedback will drive our direction.
9. Build on the shoulders of giants; don’t recreate what you can source from elsewhere (34.) –  ‘First Rule of Architecture Club’ – reuse where possible! Our framework gives us much reuse capabilities, however sometimes we have needed to build ground up to bring flexibility.
10. Register the user as soon as possible (35.) –  The 37Signal’s FedEx form is a great example of improved forms/registration. Simplicity is the key. Not thought about OpenID.. an idea to think about 🙂
11. Explicitly enable your users to co-develop the product (36.) – We want to co-dev as much as possible but first we need a product to start the conversations.
12. Provide the legal and collaborative foundations for others to build on your data and platform (37.) – Open API is a goal.
13. Design your product to build a strong network effect (38.) – Good idea for many social Web 2.0 apps but not sure this one fits so well with our service.
14. Know your Web 2.0 design patterns and business models (39.) – We believe we have a product and revenue model which should work.. Only time will tell.
15. Integrate a coherent social experience into your product (40) – Web infrastructure monitoring is primarily a internal concern.  However, experiences and advice could be shared on our forum.
16. Understand your business model and use it to drive your product design (41.) – We are going to be Freemium and our value proposition is tuned into the changes resulting from the current economic climate.
17. Embrace emergent development methods (42.) – Companies such as MindTouch and Intalio have embraced this Crowdsource approach, however healthy profits still  need to be made to survive and grow.
18. It’s all about usability, usability, and usability (43.) – An obvious but excellent point. UI is king!! And we want to put as much time and effort into this as we can afford.
19. Security isn’t an afterthought (44.) – Simon, my co-founder,  has a strong background in security working for a Global Credit card company/Bank. SaaS startups must understand security because it’s a major barrier to uptake.
20. Stress test regularly and before releases (45.) – Already cover this one.
21. Backup and disaster recovery, know your plan (46.) – Again Simon and I have a background in infrastructure so we know the rules and will stick to them
22. Good Web products understand that there is more than the Web (47.) – .Humm, let’s crawl first 😉
23. Look for emerging areas on the edge of the Web (48.) – Innovate but don’t educate the market at your expense. We are being careful with this one.
24. Plan to evolve over time, for a long time (49.) – That’s why we love the Tech business – it never sits still 🙂
25. Continually improve yourself and your Web 2.0 strategies (50) – Stop, reflect and start again. The best form of design 🙂

Interestingly there were some negative comments of Dion’s post:

“this is a terrible article… it’s like hearing about someone is development saying ‘be nice, love others, do your homework'”.  I responded saying:

“I do not believe there is an ‘insightful’ silver bullet solution any problems in life including web app dev. Following the basic principles extremely well is often the answer plus a little bit of lady luck. But we often find the obvious is hard to follow.”

Sanity check your Web App dev strategy with Dion Hinchcliffe & co

Dion Hinchcliffe recently published a great blog post, ’50 Essential Strategies For Creating A Successful Web 2.0 Product’. Dion highlights the success of online web app’s coming from software architecture and product design. I know Dion and have featured Dion Hinchcliffe’s blog on our E20portal.com website. Dion is heavily focused on Web2.0 and Enterprise IT architecture. You only have to look at Twitters ups and downs to see the effect weak foundations can have on a web app. The challenge is should you prepare your web app for scaling now or worry about it later.

Oh no, Twitters down again!!  (Febuary 2009)

We liked Dion’s post so much we checked his architecture/design recommendations against our startup web app to see if we’re on the right tracks:

1. Start with a simple problem– Web infrastructure monitoring is a mature sector and we are focused on one simple solution.
2. Create prototypes as early as possible – We built an inexpensive prototype late last year
3. Get people on the network to work with the product prototype rapidly and often – We are trying v.hard to get our beta out as soon as possible.
4. Release early and release often– As a SaaS provider releasing often is the norm
5. Manage your software development and operations to real numbers that matter – We’ve already commercial identified key performance indicators
6. Gather usage data from your users and input it back into product design as often as possible – We are very keen to do this but need to work more on click stream analytics
7. Put off irreversible architecture and product design decisions as long as possible – Tricky to do
8. Choose the technologies later and think carefully about what your product will do first – Yes, problem first platform second
9. When you do select technologies, consider current skill sets and staff availability– We’ve chosen one of the big mainstream platforms/frameworks
10. Balance programmer productivity with operational costs – A careful balancing act. Time will tell on this.
11. Variability in the productivity amongst programmers and development platforms each varies by an order of magnitude– We have not hit the challenge yet.
12. Plan for testing to be a larger part of software development process than non-Web applications – We already had Cross browser testing, usability challneges when building E20portal.com. We should load test The Aware Monitoring app – Thanks Dion 🙂
13. Move beyond traditional application hosting– We defiantly want the benefits grid /cloud hosting can bring
14. Have an open source strategy – We are using Open source 😉
15. Consider mobile users as important as your regular browser customers – This is an important point to keep it in mind.
16. Search is the new navigation, make it easy to use in your application– Again this is an important point and we need to be mindful.
17. Whenever users can provide data to your product, enable them – We need to crawl before we can walk
18. Offer an open API so that your Web application can be extended by partners around the world– I’d love to have an Open API but it’s over the horizon
19. Make sure your product can be spread around the Web by users, provide widgets, badges, and gadgets – Excellent point! 🙂 One we have thought about.
20. Create features to make the product distribute virally – As point 19.
21. The link is the fundamental unit of thought on the Web, therefore richly link-enable your applications – We like linking 🙂
22. Create an online user community for your product and nurture it– I’m not so sure about putting too much time into a full blown online community. Perhaps a forum..We’ll see..
23. Offer a up-to-date, clean, compelling application design – Dion is spot on :), this is vital in the Web app space. Need to put in the time and effort
24. Load-time and responsiveness matter, measure and optimize for them on a regular basis – It has to be!
25. User experience should follow a “complexity gradient.” – Another good idea 🙂

We found reviewing our progress against Dion’s points a great sanity check. I’ll post the next 25 points another day. On our journey we’ve found lots of helpful advice including Joel on Software, 37Signals, etc. This link to a video from  Dharmesh Shah is very, very useful for new tech startups eager to learn from the mistakes/pitfall of others.

I think the challenge is  how much upfront effort do you put into the architecture, as most Web Apps ain’t going to sky rocket to rockstar status i.e. Twitter. Leah Culver learnt along the way with Pownce (now part of SixApart) and had scaling challenges. Feedburner put alot of upfront effort into the architecture design and produced a scalable stable app. Unfortunately architecture design costs time and money in the short run if you prepare for scale. However it also costs in the long if you don’t prepare and then have to re-architect. Its all a matter of calculated risks