How to begin a project with just an idea

You could use what are called "user stories" to generate a list of things that need to happen to bring it to life without having to nail every single thing down beforehand. Think of a statement "As a <role> I want to <action>" which applies to your idea. Add it to an issue tracker like trello or just write it down if you don't want to set up infrastructure just yet. Build up enough of those that you can get going. Add more as they occur to you. If it becomes more than a side project and you start working on it with other people look into agile methodologies such as eXtreme Programming (XP) and Scrum and adapt as necessary.

Dont get hung up on the details right now. Get a prototype done as embrace the mantra of "perfect is the enemy of good". You will learn more by actually shipping something, even if it is very flaky.

The best advice I could give is to start small!! We all know that you have the most amazing idea that will allow users to launch themselves on a rocket into space (or whatever) but before you can build a rocket ship you have to build a skateboard. Try to identify what your "minimum viable product" is--the simplest version of what you ultimately want to build. Keep a separate list of features that you want to add, and your product will grow organically over time. But start by focusing on one thing! After all, it doesn't help you to have an app that users can almost log in to and almost invite their friends to use and almost etc. It does help to have an app that does one thing really well, and grow it from there.

I always start sketching and building the UI. It becomes more and more clear what needs to be done on the backend to support that UI with the required db and other code.
The most important thing is to not get hung up on details in the UI dev like shadows or background colors. Also things like profile pictures, I usually just put placehold.it there.

Good luck with building your app!

I usually start building the core feature without even thinking about the whole app with user authentification etc.

Once the core feature works, I quickly design a landing page and the few screens I need to allow users use the core feature (I use Sketch for this). Then, I create a Rails app (you can pick up the stack you prefer here) and build the app according to my sketch design.

My philosophy is to launch as quickly as possible the first version of your app. Then, you can iterate and talk to your first users in order to make it better.

Start with a very simple domain model as a strawman to help you understand and iron out the first complexities of the problem you are trying to solve. If you can explain the structure of the idea it will make it much easier. Then as Dian says start to break that model down using user stories or feature lists. This will help take that domain model to the next level.

Once you have that in place, focus on the problems that don't have easy answers. This should be obvious now that you have a model in place as they will be the parts you are struggling to describe. If you sort these first you won't get caught at the end with an unfixable problem :-)

Hope that helps...

this might not work for you, but it works for me since my thinking is very unconscious and loose and unstructured.

i think first about what i want to do. i then try to put it out in front of my eyes hypothetically to see exactly what the user should see. for example, if im writing a REST API, i will write out a few endpoints and responses on my whiteboard e.g. i will write GET https://app.io/resource and then underneath it write

bla: {
  "bla": 1,
  "bla2": 2.0,
  "bla3": "3",
  ...
}

as a json response.

if i want to write a react-powered ui, i might first write it in vanilla js and write really specific functions to get it done. if it involves a <Modal text="bla" link="bla"/> i will write an onclick declaration in a button and everything to simulate it.

its similar to what other people do. empathize with the user!!

what this has to do with me processing things unconsciously is that as i do this kind of work and force myself to work in limitations, scoping, or goals, i end up churning smaller details more effectively, such as what kind of data type to give a particular piece of information, or what headers to respond back with, or if i should use Oauth2, or whatever. this is very efficient because im working AND mulling over something at the same time

Assuming that my idea is too complex to be solved just by myself, and I would need to gather a group of other people in order to even start, I would be interested to hear how I can protect my odea from being stolen and taken to some other more powerful company. NDA? PoC? It is not only about how we start but how we start wisely.

Just a small tip that I like to do, I tend to rely on Trello to keep my user stories organized. I can access it anywhere and can easily keep track of what is finished and what needs worked on.

Edit: Just saw someone else just recommended Trello, did not intentionally repeat the idea.

I love using story maps. When done properly, they literally lay out a product and development roadmap before you. I was going to describe it in my own words, but it's probably best to quote a great article on the subject:

Arranging user stories into a helpful shape – a map has worked well for me.

It’s a simple idea really. A small story map might look something like this:

At the top of the map are “big stories.” I call them user activities (borrowing the term from UX people like Larry Constantine and Don Norman). An activity is sort of a big thing that people do – something that has lots of steps, and doesn’t always have a precise workflow. If I was building an email system (which I’d never be foolish enough to do) I might have an activity called: “managing email”, and “configuring email servers”, and “setting up out of office responses.”

A story for an “activity” might read: As a consultant I want to manage my email so I can keep up with clients, colleagues, and friends.

But that’s way too big of a story to put into an iteration or sprint.

That story breaks down into other stories like “send message,” “read message,” “delete message,” “mark message as spam” – stuff like that. I call these user tasks. (Again a word used by UX people.) For lots of Agile people “tasks” refer to the things that developers do to finish user stories. Really a task is something that someone does to reach a goal. A user task is what users do to reach their goals, developer tasks are what developers do to create stories, Ant tasks are what ant does to… well… do whatever you’re doing with Ant.

I simply arrange the small things under the big things in a bit of a grid form.