How I took my web-app to market in 3 days thanks to common services in the cloud | Hacker News Reader

How I took my web-app to market in 3 days thanks to common services in the cloud

tawheedkader.com

99 pointsTawheed34 comments

A lot of the comments here are kudos to the dev for his app - which is awesome. But what people are missing is how powerful services like Heroku can be for devs. I have students that I mentor building projects with Heroku and Rails, and it's amazing to see what they can do. Yes, prices go up when you need to scale out, but getting an idea out in front of people and seeing if people will use the product is so important. Spending weeks implementing a difficult payment gateway and setting up a scalable infrustructure only to find out that nobody cares about what you built is so costly compared to banging something out in a weekend.

In 3 days you can prove it. I built http://rendera.heroku.com in 1 day and launched it. People liked it enough to convince me to add all sorts of fun things to it. It still runs on the free plan, but if nobody liked it, I could have found that out and moved on to something else.

To the OP, nice job!

That's pretty darned neat.

I really like it but outlook has templates and Gmail has canned responses. Email tracking is nice but it's commonly used by your customers and it's a flawed metric as images are not always displayed (and counted).

It's a nice piece of work. Please update us after a month with how it's going.

The beauty of this is a) I get what I need for my primary business because Outlook and Gmail wasn't good enough and b) even if NO ONE else likes this, I've only lost 3 days, which I'm OK with.

I'll do a reflection on this in about a month or so.

Inspiring! A question: How much did it cost (in dollars, not sweat) to get these services started, and how much is it monthly?

I'm surely off-base, but I feel like it "should" all be free for something getting started (ie with very little traffic), because it would be a great way for all these services to get many initial users, some of which will become paying.

EDIT answers:

Heroku: free for dev, $15/month for production (it seems?) http://heroku.com/pricing#blossom-1-0

Sendgrid: free for 200 emails/day http://sendgrid.com/pricing.html

Charify: free for 50 customers http://chargify.com/pricing-and-signup/

Quick feedback - it was quite hard to spot a price without registering. I usually go to "sign up" page to see all of the packages, yet in this case the only place to find a price is to scroll down the front page and find it buried there after a few screens of text.

Nice copy on your site. It appears you are a good marketer :).

Thanks, but I actually consider myself to be a TERRIBLE marketer. However, I've been doing a lot of reading and learning around this and even tried to distill what I've learned into principles around effective landing pages: http://www.tawheedkader.com/2010/03/9-principles-behind-an-e...

Your positive feedback is encouraging, thanks!

Maybe with a longer development time you could have built something that would incur lower overhead over the long term. Heroku and Chargify become quite expensive if your business grows to any significant degree. Instead, building directly on top of the Paypal API and deploying to a hosting provider that will not bankrupt you as you scale would be a more optimal approach -- you won't get your site up in 3 days but with higher margins you will likely have fewer regrets down the road.

You can always reduce overhead after you gain some traction.

The principle is good. But is it really painless to change payment API and hosting platform?

That is a "good pain to have" as it were, and the reduced friction gets you iterating more quickly.

I call those "Maserati Problems", as in, "I'll think about how to deal with that as I drive around in my Maserati."

Eric Ries calls it Technical Debt

Technical Debt is different. Technical Debt slows future velocity for feature development / changing to fit customer needs. That you are "leaving money on the table" with these choices does not impede feature progress at all.

Thanks. Can you please elaborate with an example? :)

Here's an example for you:

I use Slicehost, which is rather more costly than similar VPS options such as Linode. This costs me something on the order of $2,000 a year -- but it works, almost flawlessly. With sufficient time available, I could theoretically migrate to Linode (or EC2 or wherever) and shave off ~40% of that bill, but I don't have to. There will never be a day where I say "Aww effity I wanted to develop features or do marketing today but I can't because if I don't get off Slicehost right the heck now I will suffer angst-inducing downtime."

Technical debt, on the other hand, looks something like this: the printing code in the Java version of my software is an offense against God, and I cannot incorporate new features into it without a complete rewrite. No kidding -- I want to be able to put a title on those bingo cards, but it architecturally just will not support that. It is a mess of kludges and a class hierarchy descending from FailFactoryServiceLocator, held together by duct tape and prayers. The fact that it functions at all is a miracle.

That is technical debt: I would like to incorporate new features my customers want into that version of the program, but I just can't until I rip its rotten heart out and start over. That is, in fact, so much technical debt that I'm probably just going to End Of Life the sucker and concentrate on the web version and my new projects rather than deal with it.

patio11 gave a great example from his project, but I'll add one other thing.

I actually have an extra category for tickets that I file explicitly called "technical debt." Whenever I "screw my future self," as I heard someone call it once, I make sure to write it up, so that when I have some spare time, I can go back and fix it.

Most of these issues are fairly minor. "I know I have the same code here, here, and here, I should refactor it." Next time I'm touching that part of the codebase, I'll take care of it. But knowing is half the battle.

Hosting platform isn't too bad, but changing payment API is a real pain since it's basically impossible to move existing subscriptions to a new system without user interaction.

However, I think Chargify is probably the best route for anyone doing subscription based stuff. Managing billing for subscriptions is such a pain in the ass, and these guys seem to understand that at the core.

I'm on Amazon SimplePay right now and I'd switch to Chargify in a heartbeat...if I could move over my existing subscribers ;)

Can someone explain exactly how different it is to build on top of PayPal API vs Chargify API?

- What are the fees I have to pay?

- What are the features I get?

I'm thinking of trying an idea of a paid service for a first time and just trying to figure it out.

I haven't implemented Chargify on my site yet, but I did sign up for the beta and have looked it over. Plus, I've been running subscriptions via Amazon FPS for about 2.5 years now.

By far, the #1 thing I like with Chargify is the ability to modify existing subscriptions. With Amazon (and PayPal too, I believe), once a user signs up with a rate and term, it's locked in. To change the rate they'd need to go through the workflow again. So, if you say $5/mo and want to move to $10/mo, you're screwed. Good luck getting them to go through the checkout again.

Not that this is something you'd want to do all the time, but perhaps you've been doing something for a couple years and want to raise your prices a little. Or, you want to add another tier of service and automatically bump some customers into it. It's easy with Chargify, and very hard with the others.

There's other stuff too, but it's hard to articulate. Believe me, having been there, I would highly suggest that anyone seriously evaluate Chargify over PayPal or Amazon SimplePay. Definitely DO NOT roll your own, like I chose to originally. It will be an unending source of pain.

Thanks to Heroku we don't have any sysadmins on staff, and none of us have to think about system administration for even a quarter of a second. That time then goes into product development and increasing revenue. It'd be WAY more expensive to have one of our developers doing system work, or, even worse, to actually pay someone full-time to handle it.

The only people complaining about Heroku pricing are those who aren't generating revenue, for profitable companies, it's a no-brainer.

Nice work!

Since you're already letting people login with google, it might make it easier for people to pay if you accepted payment via google checkout.

Sorry about that guys, I was trying to write a little script to auto-post and it had a bug.

Correct link: http://www.tawheedkader.com/2010/04/how-i-used-heroku-chargi...

Maybe you can you put in a redirect using mod_rewrite

done!

After reading the blog post, I decided to hook up my little web app that I have been working on to use SendGrid. Although I had some trouble configuring it to work with Godaddy's Shared Hosting, I quickly took advantage of their email api. This is a pretty neat service and having 200 emails/day for me to use is great for testing.

Thanks for the insights and highlighting this service :)

nicely done! this post inspires me to take action and create some of the ideas i had, seeing that they can be done so quickly.

For some reason, the link is here: http://www.tawheedkader.com/2010/04/how-i-used-heroku-chargi...

HTTP/1.1 404 Not Found

Not trying to be a jerk but your logo is quite similar to Socialwok.com

dude... my "logo" is two pieces of text because I was too lazy to create a real logo

He's talking about the BrainTrust.io logo in the sidebar. They do look quite similar, though it's not relevant to this thread at all.

Everything is derivative

Reply on news.ycombinator.com