Ask HN: When doing everything yourself, design or code first? Together?

People (in my experience, anyways) would prefer a product that is fast and gets the job done without fault or error over a product that looks really awesome but performs poorly and is buggy.

In other words you can put as much makeup on the pig as you like, but in the end it's still a pig.

Try telling that to one of my former bosses though ;)

The prevailing wisdom [1][2] is to sell/market the product first, so that you avoid wasting time building/designing a product that nobody wants.

[1] "Yes, but who said they'd actually buy the thing?" http://blog.asmartbear.com/customer-validation.html

[2] "Validating product ideas before building them" https://training.kalzumeus.com/newsletters/archive/validatin...

[3] "Do things that don't scale" http://paulgraham.com/ds.html

I think it somewhat depends on the market you're going after.

If you're doing b2b with a product that is clearly a differentiator, you can probably build an mvp and talk directly to customers and get them to try it out and get feedback. For this you may be able to get by with 'good enough' design.

If you're doing a consumer product, where you won't get to speak to most of the customers until after you get them interested or even using the product, then you may need to focus more on design.

Keep in mind, the less features you have, in theory the less design you need, so keeping it bare-bones at first is always a good start.

balance this:

"If you are not embarrassed by the first version of your product, you've launched too late." - Reid Hoffman

with this:

"Make something customers actually want." - pg

i once designed 20 screenshots of an iOS app before spending serious time with potential users. don't do that.

after that mistake, i'm currently demoing the world's ugliest MVP to potential customers. my MVP = a google form and a graph based on the data. i got my first verbal commitment from a customer after demoing this and mocking up the final product on a sheet of paper. (we agreed on price and initial functionality, despite the fact that 0 lines of code had been written.)

simply put: i'm building something his team can use. he gave me valuable feedback, threw in a few future feature requests and gave me a short list of other CEOs he wanted to refer me to. i also asked him to tweet about using my product. he agreed (and did).

just build something that does one thing very well, and get that in front of people. they'll tell you everything you need to know from that point on.

I just started to promote my side project[0] and I guess I am in a more or less comparable situation. I work alone and my time for this is limited.

First I focused on getting the product usable and that the documentation is somehow understandable with some code examples. My design skills are very limited, and since I build something for a technical audience, I though that the look of my website would not matter that much.

That was until Zach from headlinr[1] made me change the layout. Since I have a more or less decent looking website I get significantly more sign-ups and the logs show that visitors take more time to explore the content.

So with this new knowledge, I would vote for nice and shiny with minimal functionality first. Get something online as soon as possible. Just to get indexed etc. but do not underestimate the rejection caused by bad design.

[0] http://template2pdf.com/

[1] http://headlinr.com/

In my opinion, the early adopters are going to give it a shot anyways whether it has a good user interface or not, so you should just let it be a ugly prototype and focus on the functionality in the initial stages. Try and keep a simple interface, but don't try and make it attractive, just build in the minimalistic of it. Go put it out and take feedback and if the response on functionality is good, re iterate and make the interface better.

It is about striking a balance. You don't want to spend too long on something but at the same time, you don't want an ugly MVP that will turn off potential users.

I spent a few hours doing a decent website front with the essential details, with a working newsletter form, so that I can have that front up and running while working on an MVP. I wouldn't spend a few days or weeks on it. Same with the product - maybe allocate a certain amount of time where you would work on the design and then focus on the actual product itself.

I also agree in getting customer validation before spending too long (ie more than a year) on a certain product iteration