HN Explorer

Ask HN: What is necessary for a launch?

6 points by chacham15 ↗ HN
I am working on a product which is an application with heavy server integration. I have this laundry list of features that I feel are necessary, but I dont know if they really are.

1. Monitoring - we currently have only the devs as users and therefore dont hit any server limits meaning that server monitoring hasnt been necessary. Going forward, I feel like this will be more important, but it seems to me like the pitfall that is always talked about where founders are worried about scaling without any users. Furthermore, we currently have no way of detecting or reporting an application crash. This will make it hard to iterate and fix problems without.

2. Server capacity - We are currently bootstrapped and running off of a single t1.micro instance. This is fine before launch as we only have devs as users. For a launch though, I do not think that it will be enough. Furthermore, we currently have the web server, blog, database, dns, mail, and application server running on the same machine. This feels like putting all our eggs in one basket. Moreover, we dont have any sort of cache setup.

3. Payments - we have no way of collecting money or even infrastructure to deal with the various plans that we will have to offer. While this feels important we arent even ready with a beta. We kinda want to get the product out and get a little bit of traction before implementing a payment system.

4. Analytics/Growth - We have no idea how our users will perceive/traverse the website. Furthermore, without things like A/B testing we have no idea what the best way to market the product is other than the experience we have from talking to people first hand.

5. Features that the users want - We want to implement the above things, but we realize that features that the users want in a way trumps the others.

So the question is how do you order these responsibilities and what level of these is acceptable for a launch?

7 comments

[ 3.1 ms ] story [ 25.1 ms ] thread
makerops
1. There are a ton of monitoring solutions out there, we need to know more about your stack first. This is easy enough nowadays to be a requirement imo, even for an MVP that actually has a semi-functioning app

2. Gross. Get all that stuff seperated as soon as feasible.

3. I like stripe, fwiw, and use it in all my webapps.

4. see answer 1

5. Talk to your users, a lot.

chacham15
We are currently using a LAMP stack. But we know that we need to do most if not all of these things, the question is what order? Where should we be spending our time?
simantel
I'd focus talking to potential customers and building out whatever features make the product "minimally viable" for them. If you're pretty sure you know what they need out of your product (which, unless you have credit card numbers, you probably shouldn't be), get your payment system sorted, throw Google Analytics in, and launch.

At that point you can start selling, selling, and selling some more. Dan Shipper wrote a great post about this today: http://danshipper.com/nothing-happens-until-the-sale-is-made

thibaut_barrere
0. A warm list of emails about people interested in the service (this really helps!).
rct
Use http://www.segment.io for your analytics. You insert only one script into your site and the service lets you use up to 30 different analytic providers. Many of these services provide the first 30 days for free, so try as many as you like and see which ones you like best.
xcbnxcbxmcb
You should maximize the "wow" moment your product delivers. Since you say it is heavy on "server integration", I guess you would need to focus on monitoring & server capacity and of course, features that directly address your users' problems instead of fringe, nice-to-have add-ons. Everything else (analytics, payments, non-core features) can be left out or done in a way that minimizes effort (Stripe + Google Analytics should take up very little of your time)

Your users are not all the people who visit your site because of the "launch" but those for whom you can solve "the problem" well. I will definitely go back to a product that solves my problem, even if it has a lot of bugs. As proof, I've used buggy UML tools, code editors, video/audio editing software for years because they're very good in at least one aspect I value.

A lower-risk approach: Suppose you list out the benefits of a "launch" (example: growth from 0 to 10K users, investor interest, attract/keep talent) and then separate out the components of a launch (example: Techcrunch release, beta mailing list, investor reach-out). You may be able to de-risk by going after individual components and only building whatever is necessary for each individual component. For example you can attack the mailing list first without worrying about scale to handle traffic that a press release would bring.