I had this really great post on Hacker News forwarded my way. It was worth reprinting here so I can reference it later when I need it.
Ask HN: What should I build to support my web app?
What you need on day one:
- Something which solves problems for people. I assume you’ve got this covered.
- Some way to charge people money for solving their problems. I like Paypal with e-junkie — total integration time under 2 hours. Your mileage may vary if you do subscriptions rather than one-time payments. Subscriptions scare me. Look into Spreedly.
What you may eventually want to build, buy, adapt from OSS code, etc (I have all of these in production and run a very small business):
- Analytics software. Google Analytics is an easy snap-in for 1.0.
- Conversion tracking. Again, GA for easy snap-in.
- Funnel tracking. I like Mixpanel as opposed to GA. You can find out why later.
- A CMS to publish content (for any definition of content) in a fashion which scales out of proportion to your personal time invested.
- Blogging software because every small business should have a blog. WordPress is an easy snap-in.
- Mailing lists. I did this 3 years after starting my business. Knowing what I know now makes me sad I waited that long. MailChimp is an easy snap-in.
- A/B testing. There are three acceptable options for Rails developers: A/Bingo, Vanity, or write your own. Friends don’t let friends use Google Website Optimizer. (I wrote A/Bingo, take this recommendation with a grain of salt.)
- Application health monitoring. At the simplest level, you want to make sure that when somebody comes to your front page it returns HTTP 200. For that, mon.itor.us is an easy snap-in. You can make this arbitrarily complex. For example, I test every “moving part” on my site in an automated manner so that I hear about stuff breaking before my users do. You can read about a recent failure of this system (and all my other QC systems) on my blog. When it works nobody hears about it. :)
- Anti-spam stuff. Possibly applicable depending on what your application lets people do.
- An admin interface optimized for performing common customer service tasks. I don’t know what those are for your business. As you find out what they are, automate or eliminate as many as possible.
- An admin dashboard collecting in a single place the stats/graphs/etc that drive your decisionmaking. I have an article about this.
- Optional but recommended: you presumably have some sort of bookkeeping or accounting practices because eventually you’ll need to file taxes. This process presumably requires some sort of input from your business. Automate the creation of that input.
- Widgets for distributing your content on other people’s website are a low-investment way to get exposure which scales out of proportion to time invested.
- Database backups. Do you use MySQL? automysqlbackup is a script created by the hands of God Himself and then planted into the minds of some programmer. (Nota bene this assumes you have one SQL server with modest demands on it. Works for me, not for Facebook.)
- Backups for all that stuff that isn’t on the database. I let Slicehost handle that.
- Every app will eventually re-implement email. So will yours.
- User satisfaction surveys. Easy, low-friction way to communicate with users and receive their verbalized expressions of how you can better support their needs. (Users are much more willing to offer comments if you say “survey” and give them a survey-looking form than if you ask for comments via email. Who knew?) Wufoo all the way here. Tip: give them something for participating.
- You may find it useful to publicly expose a portion of statistics about your application as a strategy for gaining attention. If so, you need to have the stats and have a visualization for them. Totally up to you on this one.
- Your application may need to perform longer running tasks outside the confines of the HTTP request/response cycle. Look into Delayed::Job.
- If you accept user input and then crunch on it you may find that users are more creative than you are at producing input which results in output that is undesirable. This might suggest to you that you should periodically run something roughly approximating a unit test or integration test on actual user input, in a scalable fashion, for example for identifying whether a bug reported by one user can be reproduced across other users.
That’s all I can think of at the moment. Good luck! (It might sound daunting. It isn’t. You only need two things today: solve problems, charge money for problems. Everything else can be bolted on one piece at a time as you go along.)