Indie App Development — Importance of planning.
In a previous story, I mentioned one of the largest hurdles I’ve had to overcome with my app, HeatBuddy. In this story, I plan to tell a little more about what I’ve learned about the importance of planning.
Time spent planning, saves time during development.
When I started planning out my app, I had planned the very basics such as what I expected the app to do, the design and what the views would look like, as well as what the flow would be. Once that was done, I jumped head first into development.
After jumping in, I quickly learned that there was more planning to be done than just getting the views and design done. I had developed three or four of my views and ran into quite a snag. I completely overlooked the planning of the logic for these views. What happened next, was a week or two of unplanned poorly written code blocks thrust together to force things to work.
This mashing of logic to force things together would cause me a huge hurdle in the near future.
Scope matters.
The scope of your project defines its outcome and the estimated time it would take to reach various steps along the way. I define my scope likely differently compared to others. Below is an outline of how I define the scope of my projects.
- Define the minimal viable product (MVP).
- Determine frameworks, resources and technologies needed.
- Identify back-end requirements and decide on which to use (Firebase or Vapor).
- Design MVP views and outline models and view models.
- Set timeline goals to achieve various milestones.
- Build.
With the information above, it will give you an idea of what steps you’ll need to take to reach your initial goal.
Define the MVP & Identify Frameworks
During the planning process, you’ll want to identify what frameworks or technologies you may use. For instance, if your application is a map-based app, you may decide to use Apple MapKit, or use MapBox for more customization.
Ship early, ship often.
This is what I was told when I started on this journey, the idea behind it is you want to ship your minimal viable product early, get the base features in and send it. This will help you build a user base and assist in feeling out the market.
Identify backend components and needs
This was one of my shortcomings when building HeatBuddy and it was, what I am calling my double-edged sword. The initial goal was to use Firebase because this would give me the quickest and cheapest start-up to launch the MVP. Except, I didn’t just launch the MVP… I shipped a pretty polished version of the app which lead me down a slippery slope.
After hitting some edge cases with Firebase, it was determined that I would begin learning Vapor. Which meant having to understand numerous new concepts including authentication, API structuring, web sockets, and more. This created, and to this date is still creating some delays. With that being said, I do not regret taking the route I did. It has caused me to learn so much more in a shorter period of time, simply out of necessity.
Design the MVP & Outline the Models & View Models
Designing can be fun, or it could be completely overwhelming if you’re like me and lack that creative eye. In that case, I typically turn to sites such as Dribbble, and that allows me to gather some ideas and get a picture of what I’d like it to look like.
The other important thing to be keen on is the Apple Human Interface Guidelines. This will give you important details on ensuring that your application maintains the standards required for the App Store while keeping accessibility and best practices in mind.
In terms of outlining the models and view models… without getting into application architecture. You’ll find there is more than one way to handle this however, you will see buzzwords such as VIPER, MVVM, MVC, and even fancy stuff like TCA. At the end of the day, I can only say that which you choose will depend on the scope and size of the application. Keep it simple. Keep your logic separated from your views.
Setting Goals and Timelines.
Once I set my goals for my MVP, I then start organizing an actual kanban board, or even just a simple list of tasks broken down. I tend to use Github issues as this allows me to create branches for those tasks, then write pull requests. This helps me in the future when I am working within a team as well.
With the goals defined, I tend to like to set both hard deadlines and soft deadlines. These hard deadlines are just that, they are hard — meaning they are not negotiable. These deadlines must be met before working on other features or backlog items and they are typically part of my MVP. Soft deadlines are the opposite, they’re on a floating scale. For items that can be flexed or are not core features, I consider having soft deadlines.
Proper Planning Prevents Poor Performance
Conclusion
To wrap things up, ensuring that you plan out your new app idea is incredibly important. This will not only save you time but save you a headache of having to completely refactor your application or rework the logic.
Let’s Connect!
If you have any questions, or want to chat — reach out to me on Twitter @halluxdev!
