

Ask YC: Why build a solid product? - anonymousorry

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)<p>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"<p>Of course I disagreed! But my reasons weren't the clearest -- it was mostly instinctual.<p>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?
======
scrame
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.

------
Travis
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.

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

------
fjabre
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...

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

------
khangtoh
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_

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

