DEV Community


Posted on

How to begin a project with just an idea

Hi, I have an idea of an application, I'm excited about it, I'm a junior, I'm good with my stack so I have no technical problems, the problem is, how do I start, and from where, how to collect my ideas to form a solid shape of a project. I feel if I started writing down all the details, it'd be time consuming and distract me.
so is there methodologies (for programmers) to learn how to organize a new project, to keep it interesting and maintained?

Top comments (34)

dmfay profile image
Dian Fay • Edited

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.

tuxbsd profile image
Josh Stephens

Epics and User stories are two topics I feel I am weak with. Really need to spend more time learning about them. I tend to just grab a note book and start jotting everything down from class structure to database tables. Then I quickly become overwhelmed. Going to start trying this out. Hopefully I will get more projects done.

marconicolodi profile image
Marco Nicolodi • Edited

Nice answer. I also recommend Lean startup techniques to validade If users would buy your product and the lean inception agile technique to really get to know your product, what it does best, how is it different from the competition, and how to choose tasks and prioritize them. The point being: don't build it before you validade that users are willing to pay for it

moopet profile image
Ben Sinclair

Caveat: this is only relevant for the sorts of projects where you want to sell the end result.

mshwf profile image

Thanks for these valuable tips, very helpful to start a project without distraction

quii profile image
Chris James

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.

mshwf profile image

Thanks Chris!

isaacdlyman profile image
Isaac Lyman

This is how I do it. There's no substitute for excitement, so during the initial excitement about the project it's good to quick-code a whole bunch of stuff that you can refine later.

sophiedebenedetto profile image
Sophie DeBenedetto

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.

nestedsoftware profile image
Nested Software • Edited

This! I find that it’s easy for me to get overwhelmed trying to do too much at once. Simplifying helps a lot. Sketch out one feature. Implement that one feature. Rinse, repeat. :)

rimij405 profile image
Ian Effendi

This answer definitely resonated with me; sometimes you just need someone to put the words in the right order. Thank you.

laszlolm profile image
Laszlo L Mari

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

Good luck with building your app!

mshwf profile image

Thanks, I like this idea!

nicolrx profile image
nico_lrx • Edited

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.

mshwf profile image

I'm fan of this philosophy too 👋. Thanks!

naeprobs profile image

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

mshwf profile image
mshwf • Edited

Thanks, this will help me begin the project without distraction.

31547 profile image
31547 • Edited

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

moniuch profile image

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.

ikemkrueger profile image
Ikem Krueger

How can I protect my idea from being stolen?

That question is a good candidate for #discuss.

allanjeremy profile image
Allan N Jeremy

I was actually going to write this.

allanjeremy profile image
Allan N Jeremy

Feel free to join in the discussion

jacobtstaggs profile image
Jacob Staggs • Edited

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.

jessefulton profile image
Jesse Fulton

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.

jessefulton profile image
Jesse Fulton • Edited

Another very important guideline for early-stage projects, is to have a strong understanding of why it's worth implementing specific features or doing things a certain way. Usually it's easy to justify this why (or why not) if you've done the research :).

david_j_eddy profile image
David J Eddy

Paper + pencil = start drawing bubbles that are features. Build a dependency diagram. This helps to show you where to start building and what the important parts of your application are.

The more you plan, the less you re-program. Some papers I have read state that planning and validation should take approx. 30% of the project total initial build time.

User stories are a good start as well.
Copyright the idea first, for legal coverage; then talk to target users and get feedback.
Research, has anyone do it already, or anything similar?

Don't get stuck on 'it has to be perfect'. Get is done. Having something done is better than a billion best wishes.

luispa profile image

@ think about the flow of your idea (quick and general)

@ draw it! (Don’t think about the details yet)

@ start build the ui.

@ keep track of the activities that you do, and the pending things.

@ create a prototype. And another but better, and another but better... and so on, you get it :)

simoroshka profile image
Anna Simoroshka

Start messing around and putting together what seems to be the basic stuff, start getting lost in all things you found you don't yet know, decide that you need a different stack, rewrite everything, spend a month getting authentication down, write those user stories in the meanwhile because smart people told you so, get completely overwhelmed, continue working on three different things at a time because they are all connected to one story, get some people on your team, change half of the stack again, write down all specifications, let some test users in, fix bugs for a month, rewrite half of the code............ in a year you will be far from a junior developer, that's for sure. Don't be afraid to make mistakes. Good luck! :)

allanjeremy profile image
Allan N Jeremy • Edited

I like to break any project into 3 steps: why, who, how


Why are you building the project? Determining this in advance helps you to maintain the motivation when you feel side tracked/bored, which will eventually happen.

Writing this down and reading it when you feel like quitting can help reignite the initial spark/feeling.

Why would anyone use my product over another? (This especially matters when you are creating a product to be used by others and helps define your competitive advantage). Plus it helps you innovate more. In the case of a portfolio website, this could be asked as: "why would they choose me?" Or better yet "why do I stand out?"


Who would use this? (Again, matters if you are creating a project for someone other than yourself to use). In the case of a product, this is also where you determine your target market. There can be multiple usrt groups that serve as your target market. For example, an ecommerce project may have buyers and sellers as your target users. You will then write two different sets of user stories.

This part helps you determine the features you need. You can then write user stories based on the target users you have discovered above. In the aforementioned example, we would have two sets of user stories. Where the buyer and the seller interact, we can try to optimize for both but in individual cases we can optimize for the different target users

This really helps you from having unnecessary features


How will you build it?

You figure out the architecture and design of the software you are making based on the previous steps.

This is where you pick a stack/tech to use. Guessing you already figured this part out, seeing as you already have a stack.


You have done ample planning & figured out how everything is generally going to work before writing a single line of code.

I can't emphasize how important planning is! Without it, it is easy to get carried away implementing unnecessary features & writing bad unmaintainable & unscalable code

Anyway. This is where you create your MVP (minimum viable product). Get your product out in the hands of users (if any) as soon as possible. They will guide your future iterations

Remember that your assumptions about users may mostly be wrong, so don't waste too much time building an overly complex product behind closed doors

Could write a lot more on starting a project (might as well convert this comment into a post) but this is simplified and seems to work.

This response was written on a phone. Apologies if there are any mistakes

Tools that can help

Only mentioned a few that have almost no learning curve

Google keep - user stories/taking notes. Free

Trello - planning. Freemium. You can use it for free and can pay for extra features

Bootstrap studio - rapid ui prototyping. About 25$ for an annual license and 60$ for lifetime

Adobe XD - UI/UX prototyping. Supports mobile prototyping

@ben Notice me senpai

nashpl profile image
Krzysztof Buczynski

I usualy carry a notebook with me. I write all ideas i have for my projects. Don't make this hard and something that you have to do. Make it a game, plesure something fun to do