Getting ready to build an app

If you've decided that you need to build an app, then the next step is to ask yourself the following questions:

• What exactly does the app need to do?

• Will the app be private or public?

• Who will be developing the app?

• Who will be designing the UI?

• What is the budget and timeline?

Once you've answered these questions, you should have a rough idea of the big pieces involved in creating the app. The set of features required to build a software is often referred to as the scope.

Determining an application's scope even at a high level is a skill that requires practice. This typically starts as a document that lists the overall purpose, feature list, integration points with Shopify (if known), dependencies on external services or software libraries, proprietary business logic, architectural decisions (language, platform, server requirements, and so on), budget, timeframe, and anything else that will impact the application life cycle.

Creating in-depth specs is beyond the scope of this book, though in general more information at this phase is better (it's easier to trim features and defer them at a later phase as development progresses rather than trying to cram in new ones that were forgotten in the beginning).

At the very least, a list of must-have features is necessary. Even if you are doing the development yourself and the feature set is small, it's a good skill to learn and will often reveal aspects and features that weren't originally planned. This is the technique we'll be using throughout this book. We are going to list out the high-level features that we want to build and turn each one into a sprint. A sprint is an agile methodology term that denotes a discrete amount of work. Usually, a sprint lasts for two weeks or less. In our case, each sprint will last only a few hours because our feature set is simple.

For a larger app, the simplest way to start is to list out all the features, prioritize them, and then set a cutoff based on time and budget. Even if it never progresses beyond a simple list, you'll have something to measure progress against while the app is being developed. Without this list, all the features (complete and pending) will only be in your head.

An analogy for this would be going to the grocery store without a list. Chances are, most of the things you need will end up in the cart, but undoubtedly, you'll either forget a few things (feature deficiency), spend excess time roaming the aisles trying to remember what you need by seeing something you forgot on the shelf (inefficient development/refactoring), or add things that aren't on the list (scope creep). The worst situation to be in is to have all the ingredients to make lunch tomorrow but be unable to make dinner tonight because you forgot something important!