Live data from Hacker News

Ask HN: How do you generally build a product?

news.ycombinator.com

41–50 of 73 posts

Re: Ask HN: How do you generally build a product?

#41

Think of a product name. Buy the domain name. Launch a cloud linux server, install web server, database, application server. Configure it all up to talk to each other. Build the user creation and auth system. Implement email system for user emails. Start building the hardest bits of the application first, try to get a minimal end to end implementation of the system, iterate over the minimal version improving stuff un…

That's what I've been doing, not even kidding, and I'm not so sure this is the right strategy because this has got me to abandon some nice ideas.

Re: Ask HN: How do you generally build a product?

#42

To build a product, I look to see if I can get something out in a 2 week so I can at least dogfooding it. The purpose is I should be able to use it daily asap to keep my momentum and solve my own pain point. Without seeing the pain, I'll easily lost motivation and give up. I also try to pick a product idea that emphasize my strong skill and less depend on my weak spot. A case study, for my email forwarding app https:…

I always start with the fantasy that I can get an application built in two weeks.

That's how long it takes to get the MVP out there but coupling for procrastination, it takes longer than 2 weeks to get it out even though the actual work for the MVP does get done within two weeks.

Re: Ask HN: How do you generally build a product?

#43
post #33

Is there a streamlined checklist or skeleton for planning various parts (backend, frontend, etc.) of a project?

Skeletons and frameworks should be avoided at all costs. Frameworks are sometimes useful if you know one well but if you're new to it its gonna be a huge time sink. Skeletons are similar issue to frameworks, they give you a whole lot of boiler plate and distract you from solving the problem tying you up with the authors picky conventions. The best framework is a .PHP file running on Apache.

You are right about frameworks taking a lot of time and stall your idea if you aren't already good at one. However, if you are alright with not being to able to build your idea right then and there and are willing to extend the timeline by a few weeks, you might learn something new for ideas later. Last year, it took me 8 weeks to build something that could've been done in 4 weeks max but I'm glad I did that because I learnt Django quite well and now I'm using it to build my other ideas.

Re: Ask HN: How do you generally build a product?

#44

I write it in Haskell and the breakdown of problem-solving is 10% coding and 90% subconscious thoughts while doing the dishes.

The sub-conscious thoughts float away for me whenever I sit at my desk again so I've decided to take, this is corny, but I just take voice notes or any kind of notes, no matter how small the thoughts on my idea are. I later review those notes, write the best ones down in ClickUp/Notion and well, make a feature timeline for them.

Re: Ask HN: How do you generally build a product?

#45
> how do you find the time to build that idea out

Based on this, I'm assuming you want to build an idea that makes money first.

You need to solve a problem that's worth paying for. Easily said, of course.

The Mom Test[0] is a book about how to ask questions that are worth pursuing as a business.

> do some of the good ideas get left out?

That's the question really to focus on. Don't worry about developers or building yet - the first question to ask is - is there really a problem here?

The first step really is about a basic litmus test. What's the cheapest way to "test" the idea without a costly build? End user research, landing page with some targeted traffic,

All about getting to a few potential customers who will give you feedback.

After that, then I say start building.

If you build in a vacuum (you and some developers), you're likely to get it very wrong.

[0] https://www.amazon.com/Mom-Test-customers-business-everyone-...

Re: Ask HN: How do you generally build a product?

#46
post #2

It sounds like everything you mentioned falls under the heading of software project planning. Are you familiar with those techniques already and possibly asking whether those should be applied to personal side projects?

To some extent, yes, my question is about how "other" people plan their ideas and projects. I'm familiar with those techniques but I would like to know how others' timeline from an idea to a product looks like. When do they start getting other developers to work with them, how easy it is for them to convince others, etc.

Re: Ask HN: How do you generally build a product?

#47

> how do you find the time to build that idea out Based on this, I'm assuming you want to build an idea that makes money first. You need to solve a problem that's worth paying for. Easily said, of course. The Mom Test[0] is a book about how to ask questions that are worth pursuing as a business. > do some of the good ideas get left out? That's the question really to focus on. Don't worry about developers or building…

You made a valid point about building in vacuum, that's exactly what I was doing with one of my projects last year and was wondering why I couldn't get any users who were sticking around. Sometimes, it can be the painfully bad UI but when that's not an issue either, you know, it's probably the problem you picked to work on itself.

So I'm assuming, before working on anything that you think might make some money or be useful to others, there always has to be some form of idea validation.

Nevertheless, what about the developers who don't have extensive developer networks nor the budget ( think : high school student or a 30 year old who can't convince colleagues to just quit their jobs and start working full-time with them ) but great ideas, which let's assume pass the Mom test. What do they do to get the word out for developers to start working with them, after all?

Re: Ask HN: How do you generally build a product?

#48
post #20

1) First start with trying to sketch out (write out) the solution on paper. Writing out your solution forces you to think the problem through. Psychologically, you don't see it as being stressful or as tasking as writing code which means you're more likely to stick with it for some days. 2) Try to work on your idea at least 4 or 5 days of the week, no matter how small the time. You don't have to write code. Sometimes…

On top of this, pick a technology you already know, and start building. Write about what you're building. As an example, here's a thread of what I'm currently working on: https://twitter.com/RozenMD/status/1364881512500404224?s=20

Interesting that you mentioned about writing what you're building, there's something I found recently that helps with this https://www.buildinpublic.xyz. I'll be trying this strategy out for getting the word out.

Re: Ask HN: How do you generally build a product?

#49

TBH I've created so many things over the years I've learnt my lesson. Now, I always start with a marketing plan: * Who's your target market, and how big is it and what are they likely to pay? * What do they want? * How will you create value you can capture? * How will you reach them? * What's the competition? If you can't answer these or don't get decent answers, bin it and move on. It's easy as an engineer to build…

Same except I don't bin it, I put it in the "projects for fun" box.

NB: "What's the competition" is a very hard question when you're trying to innovate.

Re: Ask HN: How do you generally build a product?

#50
Wanted to emphasise the value component.

If your building a product to sell (versus something for personal use) then you should try to quantify the value someone will get out of it (not always easy) - but - if you can model this then that helps with your strategy for pricing.

Put simply - if client gets $X value from the product you should be able to capture % of $X.

Post reply on HN