Ask YC: Why build a solid product? | Hacker News Reader

Ask YC: Why build a solid product?

So a friend of mine wants me to try doing a venture with him, selling merchandise in China. I'd be on the developer end programming what's basically a purchasing site like Buy.com but for China. As a RoR developer, I wanted to build the project out with "best practices" (TDD, agile, whatever)

There's another developer on the team however: he thinks it's a good idea to use PHP and to build a "crappy product, get some revenue, pitch to VCs and build a solid product later"

Of course I disagreed! But my reasons weren't the clearest -- it was mostly instinctual.

What are reasons for and against building a crappy product first and improving it later? To me, i guess my best argument was wasted time and money early on. Is there any more to it than that?

View on HN

I've faced this a couple times. Basically, they want something they can show off and dont really know or care about the quality of the work. The problem is that all of the corners cut early on begin to accumulate, and major design issues quickly become daily maintenance headaches once something is in production and up to the point of "pitching". What is more likely to happen is you will have a bunch of basic stuff that is relatively easy to implement and any advanced/killer features will become very hard to implement, and most of the effort will just go in to keeping it going, rather than improving it.

Chances are, taking the quick-and-dirty approach won't get to the deadline either, it will just show pieces of early functionality earlier, but wont have a foundation to get to the solid product.

The early development you do is laying a foundation, while you are in that phase, you can still scrap pieces of it wholesale and rewrite it, but once you start building on that foundation, you will not be able to make a skyscraper if you are building it on a tar pit lined with tin foil.

And "best practices" (TDD,agile,whatever) are no guarantee that you will get it right, either.

I'm a PHP dev, so I'm a little biased. But still.

Use whatever will get you to a minimum viable product fastest. How you build the application should have little impact on your business. If you can build the PHP app 5 times faster, and you need to execute quickly (say, short runway upcoming?), using RoR (and the 5x longer dev cycle) would be a poor decision.

Don't get obsessed about your code. Get obsessed about your product. And the best way to do that is to build a throwaway, quickly, so you can talk to customers with it.

I think the developer is right. Why don't you use something off-the-shelf?

One reason would simply be you won't be at 100% if your heart isn't in it..

Also, there's a huge difference between building something bare bones to release with and setting out to build something 'crappy'.. The latter sounding like a recipe for disaster.

In any event, that's a pretty big disagreement to be having this early on...

Vote me down, but RoR and solid Product don't go hand in hand for me.

Simple, with the same amount of time you take to build a _crappy_ product with PHP, you can build a solid product with Ruby on Rails _Period_

To me, it sounds like the developer doesn't want to learn RoR, so he found a convenient excuse.

Reply on news.ycombinator.com