Ask HN: How do you start development of your latest great idea? | Hacker News Reader

Ask HN: How do you start development of your latest great idea?

3 pointskhingebjerg5 comments

I'm interested in hearing about how you aproach the initial development efforts.

Choosing technology. Do you go with what you know, or sometimes see it as an opportunity to try something new?

Getting started on a prototype. Do you start on paper, i.e. some sort of design, or do you jump heads first into coding?

If it's a something with a front end, do you start with that, or do you prefer to start with the back end?

Any other insights, on how you attack your new ideas, are greatly appreciated.

View on HN

Usually I'm building something to scratch my own itch, so I typically jump right into coding. In fact, I usually don't start by thinking, "I should do this as a project." I start just by doing it to solve my own problem, then realize it's pretty cool and I should expand/release it.

That being said, I usually start building out the front-end first. Understanding actual user interaction and use cases is pre-requisite for designing appropriate data models and storage solutions. I basically try to get something up and running as fast as possible, while minimizing the cost to change directions.

For a simpler project, I usually start by building a basic library of classes/functions I know I'll need (for example, a database factory class and MySQL or PostgreSQL interface, helper functions for cleaning querystrings and form fields, etc.). Then I'll do a basic mockup of the front page and at least one or two internal pages (if they differ from the default page).

Finally I start building code out, starting with a very basic theme for the front end and concentrating on any security that needs to be in place.

Yes, I generally start from a blank slate each time, just using pieces of code I already have. I don't use frameworks or CSS grids.

I start with brain storming how it will be used. What are the use cases? This is easy if you are scratching your own itch. More difficult if you not.

Then pair down the ideas/use cases/requirments to what you need for an MVP.

Then I like to work on the data models and back end. But that is where my strengths are. If it is a complex problem, I like doing some design work to make sure a) its doable b) that I don't code myself into a corner.

That said, I'd like to all the above very quickly and get to the coding. I have found at times that I get stuck spinning my wheels. It helps to get input on any of the above from another person.

I love writing snippets of code. Usually they form the basis of a much larger, well architected idea.

But at the beginning everything starts out with just one or two files. Figure out what you want to get done and just do it. Don't worry about if it is ugly or not. You are just proving an idea.

If you are attacking a much larger concept you still want to start small. If it is a web application make sure you use a framework.

Once you know you can do it then you start architecting. Make a list of tech choices you know or want to learn and might be a good fit.

Brainstorm with a group of people I respect. Put the idea to the test to foresee inconvenients and opportunities I may not have considered after a long time thinking about it myself.

Then I just go and code the core of it ugly and fast into simple tests to make sure it'll fly.

Then I go out and start building a first release with minimum functionality, release it to a closed alpha test group, iterate, iterate, iterate, go beta and cross my fingers.

Reply on news.ycombinator.com