Live data from Hacker News

Ask HN: How do you generally build a product?

news.ycombinator.com

31–40 of 73 posts

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

#31

I'd recommend starting out with a landing page first before you build the app. Like a really nice, well-designed one, that captures your vision and core points. Just copy some startup landing page you like and tweak it. Create from scratch or use webpage builder. Gives you advantages: something you can share with others, a developed/implemented vision, something you can actually launch at any time without the underly…

Honestly, this sounds terrible. If there is something the software world does not need then it's landing pages for vaporware.

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

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

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

#34
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://hanami.run

1. Create a PoC without any UI. As in, backend only, no database, just JSON so I can configure it. the app boot, load data from that JSON file. If I need to change anything, I edit that JSON file, The app reload it.

2. It works. Awesome. The core of business work. It's useful to my daily work. I can hook up domain to it and forward email

3. Started to get on front-end. Get a few friend, ask for their feedback. Setup a weekly sync with them. This is important. It forced to make progress

4. Get a google docs for what I should ship and what I achieve that week.

5. Continue use it daily. See pain point. Keep improving. Example, I never though I'll log email. But eventually I added that features and people love it. I never though I'll need an API for email forwarding but turn out many users want ability to curl and get email in JSON format

As you can see, my product is heavily depended on my pain point. Without me having a need to use that product myself, I think it's hard to build.

So my process is always to look for what I wish should existed and go do it, weekly sync, have a few friends to give you feedback/beta tester every week, congratulate small wins.

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

#35
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.

I would like to nuance your statement a little bit. I agree that learning a new framework alongside building your project is a bad idea. But if there is a framework that you know well and it fits the project then definitely use it.

I have my standard stack of backend/frontend/database/infra tools that I know inside out and fit most web projects. So whenever I have a new project idea it takes me 20 minutes to get hello world from frontend through backend to db and back. And then I can start building using the FE/BE frameworks I already know.

Edit: I now see you mentioned this in the second paragraph so my comment is redundant.

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

#36
It's a long long process to answer your question. The best thing to do is to get started.

I am currently building https://textgun.io to integrate SMS with zapier ( which integrates with 3,000 apps). Yes, it's already has been done with other SMS vendors, but I am looking to disrupt twilio's greedy pricing... It's currently in beta on zapier for those who asked .

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

#37
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 until it’s holding together as a full application, tune, polish, do the deployment stuff.... domain name, google analytics, backups, open the firewall launch. Wonder how the fuck to get users, shut it down, build something else.

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

#39

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.

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

#40
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 stuff, but if you build it, they probably won't come, so you might as well work out whether you're wasting your time in advance instead of at the end.

Post reply on HN