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?

Did you find this post useful? Show some love!

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.

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.

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

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

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.

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.

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!

Ben Halpern DEV.TO FOUNDER

Hey there, we see you aren't signed in. (Yes you, the reader. This is a fake comment.)

Please consider creating an account on dev.to. It literally takes a few seconds and we'd appreciate the support so much. ❤️

Plus, no fake comments when you're signed in. 🙃

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.

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

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

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

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.

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

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

@ 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 :)

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.

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.

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.

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:

story_map_diagram

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.

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

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

Thanks all for the great tips, really appreciated and helpful!

Classic DEV Post from May 21

Quick Advice For Junior Devs

Some thoughts for junior devs.

READ POST
Follow @mattsparks to see more of their posts in your feed.
dev.to is now open source!
View Announcement Post View GitHub Repo
mshwf
.NET developer
Trending on dev.to
What's the deal with downing PHP development?
#discuss
Looking For a Simpler Way To Develop WordPress Themes Locally.
#wordpress #discuss #help
Style your Terminal better by mastering these settings 🤩
#terminal #productivity #tools #webdev
How Do You Really Get Hired?
#careers #beginners #discuss
Software Made Simple
#design #simple #productivity #devtips
How many computers do you use?
#discuss
Open Source Has Not Failed. Don't Cover Up Corporate Abuse of Open Source
#opensource #technology #career #rant
Dev.To Discord Channel?
#discuss