20
17 Comments

What is your planning process when building an app from scratch?

For some reason when I get an idea and try to start building, I just get overwhelmed. Maybe I just start writing code too soon or maybe I just need more patience, I don’t know. What does your process look like when building from scratch?

  1. 3

    My advice on that subject would be to consider that you're not racing against your idea, for that reason if you really want to work on something worth your time there are a few points you should take into consideration before you start:

    1. Always start with the problem definition, try to understand what you want to build and for whom you're building it, understand the problem you're solving.
    2. Then get yourself and do a little research, try to validate your hypthosesis so you can save your future self from wasting your time, gather as much as information you can (data from your potential users, market, competitors).
    3. When you have enough data, start to analyze them so that your decision can be data-driven.
    4. If you get to this point that means you have done a great job and you're probably ready to think about the conception of your app. Here you can build sketch/wireframe/prototype and see how your app would look like.
    5. Here you're get to the implementation phase, try to use an agile framework like (scrum/kaban) so you can focusing on continuous delivery.
    6. Test before you launch, get people to test your app idea. Keep what's good and remove what isn't. Build-Test-Launch.

    If you're working alone that's a lot work but be assured this process will help you to avoid building something that nobody wants. Building a great tech powered service/product takes time and a lot of effort try not to rush because you only have an idea.

    An idea is worth building only if we can validate the hypothesis we have in our heads.

    Ideas are cheap, execution is everything.

  2. 3

    • Outline main features
    • Sketch out screens
    • Create user stories / tasks to break up work
    • Start development and any other work (e.g. domain setup, social media accounts, etc)

    This is my process when working on apps by myself. The biggest thing I've learned is not to spend too much time on the mockups for pages. This is at least true for me, since I'm not proficient with design software so it takes a lot of time to design out mockups, so I just stick with wireframes.

    For context, I've only built 2 small apps (and currently building another one now):

  3. 2

    1. Capture
    I always start with creating a note in Notion and keeping in mind I have this topic.
    First day I try to write down my raw ideas as they come.
    Every day if I see something related to it I add as reference to this note and add screenshots and my notes. I also add everything that inspires me and what can be useful.
    Some times brilliant ideas come when I am in shower or during walks, so I make sure I have my phone with me to capture those ideas, if I didn't capture it I tend to forget it just in 1 hour.

    2. Research
    It takes time for my ideas to get some specific shape, and at this point I already can think of some keywords and describe problem better. At this point I start looking for existing solutions and capturing screenshots of things that I liked the most. Then I am trying to use this solutions and write down all the flaws, pros and cons. If at this point I find a good product or combination of products I try to estimate how much time would it take for me to build mine and if it worth it. Some times it just worth to pay for existing solution.
    At this point I some times tend to ask questions around (my friends, colleagues, social networks, twitter, IH, etc.) or even conduct surveys. For some technical problems it also make sense at this point to work on technical proof of concept, to check if it's technically possible.

    3. Outline
    After I have some ideas I try to see the bigger picture. I start with a sitemap and user journeys. I love process described in Design Sprint by GV.

    4. Sketch
    I always start sketching with pen and paper. It gives more flexibility to express ideas and it works faster than any special software. My sketches are super simple most of the time.

    5. Prototype
    When I see big picture and understand user journeys only one task left for me - make this experience as smooth as possible - create User Interface, come up with some elements and pattern, colors and fonts, etc. In the end I have a solution that one can see and taste.
    It's time for user tests and check all my assumptions.

    6. Build
    Once I am satisfied with results it's time to build. If at some point something went wrong, I step back in my process.

  4. 2

    Can't believe nobody has said this yet, but:

    Talk To Customers

    If you're planning features or, even worse, writing code without having spoken to prospective customers, you run the very real risk of making something nobody will want or buy. Or even if it is something people want and will buy, the more you know about your target customer, what their strongest pain points are, and what they're currently doing to solve it, the better all your planning will be.

    1. 1

      Very important point. Even I was surprised that many people didn't mention about validating the idea before building something.

  5. 2

    I write down modules then work on them one by one, this helps keeping the scope narrow and progress in an iterative way 👍🏻 I coach founders and startups on productivity and efficiency so maybe DM me @joeblas?

  6. 2

    Check out "Shape Up Stop Running in Circles and Ship Work that Matters" by Ryan Singer
    https://basecamp.com/shapeup/shape-up.pdf

    It proposes an interesting approach used by Basecamp to plan and build new features into their software.

    1. 2

      Wow, nice resource thank you for sharing it.

  7. 2

    Try reading Getting Real, it will give you a good idea of how some of the prose do it. It’s from the developers that build Ruby

  8. 1

    Hey @joeblas. This is a great question. I just finished creating a course about how to build and kickstart your MVP. I outline a 7 step process for bringing an idea through to validation as follows:

    1. Express your idea
    2. List and prioritize your MVP Features
    3. Timebox your release schedule
    4. Build Your Lean MVP
    5. Decide on some KPIs
    6. Release it
    7. Measure, Learn, Iterate

    If you want the course I'd love for you to take a look at it.

    I also think that having a community of others to help you get feedback and iterate is very important. Hence why we are creating a community of entrepreneurs, creators and builders at Startup Sanctuary.

    I hope this helps.

  9. 1

    In the past I worked on projects just for fun, thinking about an idea and then start building it, without much research. It's a great way to learn and experiment, but no idea ever went further than experimental prototype stage.

    With my latest idea I've decided to go the organized route – Thought of use cases, feature set, market fit, business model first and then opened up a survey.

    As soon as I have 100 replies and/or over 50% are positive, I'll start defining an MVP structure, then build the most basic features to make it viable and ask the people that allowed me to contact them for feedback. Reiterate from there until I have something that can go public and then start marketing to make it official 🚀

  10. 1

    Yeah honestly, I would love to find a framework for this. Asked a similar but different question here

    https://www.indiehackers.com/post/is-there-a-service-to-help-you-scope-out-a-web-project-1ee0fb28ba

  11. 1

    I try to design a lot at first, it’s more of a preference though because I know how I get with code and I tend to spend too much time in areas that aren’t necessary for prototyping and getting something out the door.

    My rule of thumb is spend time being playful with your project and ideas. Just see what it is your brain is wanting to create and go from there. You’ll find some way to organize it into a cohesive routine with incremental progress along the way.

  12. 1

    I am trying to think about main feature and simplify it as much as possible to test it out. Then I just open code editor, create empty app and start coding it.

    My first goal is to create something very basic so I can get feel for what I am trying to do. There is generally no design, no user accounts or anything else really. I am also don't care that much about database structure which is going to be throwed away few times anyway.

    Core of most apps is usually quite simple if you don't take edge cases in account. And I like to abandon these prototypes few times until I think I have something on my hands and then I am creating another new app from scratch and start with user account (if needed) some basic design system and recreate prototype with more production level code.

    Most of the apps I've created had like 5 throwaway prototypes with various levels of exploration done on them.

  13. 3

    This comment was deleted 5 months ago.

    1. 2

      Everyone should do this before starting coding

  14. 3

    This comment was deleted 2 years ago.

  15. 17

    This comment was deleted a year ago.

    1. 5

      That’s good advice, thanks! I like the idea of stepping away from it for a while and coming back.

      1. 1

        This comment was deleted a year ago.

Trending on Indie Hackers
Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 29 comments My Top 20 Free Tools That I Use Everyday as an Indie Hacker 18 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments How I Launched FrontendEase 13 comments