So you focus on getting your “don’t worry be crappy” code together to bootstrap your startup and get something the real world can play with. All the user-oriented features you need are there for 1.0.
But what about the rest? What about the things you need to make the service tick, to keep in touch with the users etc? These things are really important, as you can bet things are not going to go smoothly all the time, especially at the beginning.
We’re just going through this phase – all the basic 1.0 coding is near completion, and now we need to make sure we don’t miss out any major “duh” features we need to keep things going.
Off the top of my head, I can think of the following:
- Effective web stats so you can see how people are using the site
- Database backup policy and off-site backup of your users’ data
- A mechanism to easily send downtime/update/marketing emails to all your registered users
- The ability to add a banner on the site to indicate scheduled downtime
- A predefined plan of action to take if the servers are swamped
- A way to update key content without a redeploy (= scheduled downtime!)
- Basic reporting to see how many new users you are getting, and what they are doing – over and above webstats, a summary of your domain objects etc.
- Make sure load/health reporting is set up and working in advance
- Detailed functional tests and/or manual test plans ready and in place. You tested 1.0 right?
Do you have anything to add to this?
UPDATE: commenters have also very wisely suggested -
- Screencast showing users how to use the service
- Issue tracker for support
I found out today about Google’s new Latitude service. This is basically a “where are my friends” application that uses position information from your phone to update their central servers, and people who you grant access to your location info can see where you were (not are – depends on when you report in!).
Now this is particularly interesting to me as I have a fairly well developed idea for such a service, and had begun implementing this using the iPhone with a custom iPhone application (and of course a Grails application for the back end).
My immediate thought was “phew! Glad I didn’t spend any more time on that. Note to self: check own ideas for ‘behemoth trouncing risk’ in future”. Not to mention some relief that I wouldn’t have to implement the service myself now Google has “done it”.
However, then I started to think a little more and looked at their offering a bit closer – as much as I can with nobody using it and no iPhone support yet.
This made me realise a few things:
- The behemoth does not always get it right, or rather tends to cater for the very high volume use-case which is not necessarily where the financial gain is to be mad
- I have not seen their phone app yet, but I am wondering if it will have the right “drop dead simple” UI it requires
- The behemoth when trying to handle the generic mass-market use cases, can not always create the seamless and simple UI required for users to love (and continue to use) a service
- Most importantly – this kind of usage is not, in my view, what this technology is best for. I think the money to be made here is on smaller groups of users, and users in specific organisations.
Sure Google will have some plans further down the pipe – I’m sure an API will come (“Show where you are on your blog”, “Get location of friend X” etc). Its also surprising they don’t have an iPhone app (rather than an iphone customized web site) for this already.
However I think there’s a fair bit of money to be made with such a service that focusses on making sure parents know where their kids were when they said they’d check in, and for small-scale logistics for companies. The application UI -has- to be top-notch, and the functions it provides have to relate to the market place. There’s possibly a couple of different client apps that could be made to front the same back end.
So if you’ve got a some spare cash and want to fill what I believe remains a gap in the market, drop me a line and I can flesh out the ideas for you