To this day, there's a couple of things where my workflow is "SSH into the box and run commands against the Rails console" because those tasks were never common/important/etc enough to justify even an hour writing up a tool to automate them.
I can't agree more. It took me a while to get there but in the end it's exactly what everybody should do.
As of right now I'm manually creating the accounts of new customers (has something to do with creating new database tables which is done half-automatically). Right now there is only a trickle of new customers (due to the lack of marketing) and it's not worth it (yet) to program a fully automated registration process which would require a registration form, payment processing and above mentioned account creation.
This is the key take away.
If you're doing an experiment, you're doing it to learn something and prove some hypothesis. The only thing that should delay you from launching is, "If we launch now, we won't be able to collect that data we need to test our hypothesis".
Learn and learn fast. That's it. You can't learn if you're not making contact with your customer. A 25 SLOC splash page that learns something is better than 2500 SLOC that just sit in your GitHub account.
I am not sure exactly why this is. Am I fearful of it being a failure or am I fearful of all the work I'll have to do when users start giving feedback. Perhaps it is not so much launch fear as launch fatigue.
It's reasonable to want to be in good shape when you put something out there. If you can't be responsive to users, you'll lose 'em.
My tip: go someplace quiet, warm, and pleasant for a couple of weeks. Read novels. Sleep late. Have a beer on the beach early in the afternoon. Go for long walks and maybe some long runs. Your love for what you do will return after a while.
I believe there is a growing number of startups that are realizing the importance of launching with a (fairly) polished product. There's just a ton of startups now, and standing out in the crowd is becoming more difficult.
When I hear "launch early" what I personally take it to mean is "iterate based on _real_ customer feedback", with the intention being you'll minimize wasted work. But this is how you should be running your business all the time - not just at the MVP stage.
Then I saw your comment about iterating on real customer feedback and I realised there's no difference between "releasing early" and "release a beta [early and get feedback early]", and obviously the time to release a beta varies depending on the product. If you think about Google or Shazaam or any technology-based service, the core algorithms took time to develop to a point where a beta made sense because access to the technology was the product. Or am I missing something?)
Agreed entirely about iterating based on real customer feedback, though.
It takes a lot of courage to burst your own bubble at the earliest possible opportunity.
That said, there is some truth to the fact that you need to love it before you can let others see it. It has to be clear to you why you yourself want to use it. We have gone out on many launches. Alpha, Beta, and now launching to the world on 17th April.
None of those early launches stuck! Why? Because it was still a Work-In-Progress. And it felt that way to our early users. It felt like we had to make excuses when presenting the product to friends and early adopters.
But the early product is not expected to be scalable. It just helps you avoid the problem of launching a late product with all the same major flaws.
I also get stuck on the question of how many features is 'enough' that users won't immediately leave, which is when you can begin testing your business assumptions
You have no idea how I like reading this. I'm sick of all those new websites that offer their service for free, hoping to figure out how to monetize later.
Every commit goes live as soon as the tests pass. We do have a staging server, but it's running the same code as in production. We use it for manual putzing around (so we don't mess up production data or clutter production logs), and we eventually added feature toggles so that a feature can appear only on staging.
That means we're releasing every few hours, which a) means we get feedback as soon as possible, and b) production bugs are pretty easy to run down, because you know just where to look.
If you're clear on that, you point to the doc and say "how does this new idea/feature help accomplish this?" and force a specific answer.
The best way to make people care about a product is get them to pay some money for it first.
I also launched a free version of our product after. While this one has a lot more users and is growing exponentially, the feedback is far sparser. People care for things they pay for and that attention is great for shaping the beginning of your startup.
I had a meeting with the brother earlier today. He runs an online wholesale business (I do all the tech stuff). I've been leaning towards launching a retail arm in our one EU country, and launching 3 new wholesale websites translated into Dutch, French, and whatever they speak in Belgium.
We decided instead to translate just the landing page 3 times into 3 languages, to set up a retail site landing page, and to run 4 Google ad campaigns for a couple of weeks, dropping a couple of hundred euro on each one - to see what happens... impressions, clicks, etc.
Here's he point. On HN, we hear non-stop about MVPs, and because of the site that's in it, it's all software or web services. But the reality is that everything that points towards an MVP being a good idea for software and web services, is also true for more traditional eCommerce and info sites.
Dutch and French. :-)
It seems like the real problem here is just not knowing your customers. By all means you should be beta testing with your friends and anyone else you can guilt into helping you. Don't launch blind.
These larger firms make their data available to smaller sites via APIs, allowing for firms like Yippit, Sqoot, etc to serve as aggregators. These sites then skim off the top of the deal sales, sometimes getting 50% of the commission on purchased deals.
The danger is that the larger sites that are the life blood of the system run on enormous deficits to maintain those armies of sales reps.
As DHH put it, local deals is like finding oil on the moon: a valuable resource that might ultimately prove too costly to extract.
We have group-buying (Groupon-style) deals, which has opened up the way somewhat, but I'm playing around with a more traditional deal-listing model that doesn't push merchants as hard. Do you think salespeople is the only way to keep merchants offering deals, for a listing model? It seems costly but also the only way to keep merchants listing deals even when the revenue outcomes of previous outings haven't been that spectacular.
I appreciate any thoughts you or anyone else might have on the issue - thanks!
However as Groupon has proven they are typically very dependent on expensive marketing channels in order to achieve growth. Over the last year or so the market has become really saturated with daily deals sites and so the competition for customers is fierce. I think as Groupon's woes become increasingly apparent, the daily deals bubble will start to implode (if it hasn't begun to already)...
