Building good software is hard… really hard actually.
…doing it on ultra-short timelines is just insane.
Question: So how do we build kickass iOS apps in just 7 days for a fixed costs?Answer: Our crystal clear process.
Even with the amazing people on our team, we would fail without our amazing development process. We keep things simple too: Our process is only 5 steps. The first two focus on “smart-brain” activities, the second two are “dumb-brain” activities, and the fifth is to party (seriously).
What you’re about to read is a brief overview of how we make iOS app in 7 days. This is the first article in a series that describes our 5 step process and we’ll detail each step in the rest of the series. The 5 steps are:
1) Define & Design
2) Architect
3) Build v0.8 and get client feedback
4) Finish v0.9 and test
5) Deliver the final app and Celebrate!
10,080 Minutes
There are over ten-thousand minutes in 7 days. That sounds like plenty of time to execute on something amazing. But 10,000 minutes can evaporating in front of our eyes if we don’t have a plan upfront and to stick to it… while also rolling with the punches along the way. That’s why the first two steps are dedicated to making decisions.
Step 1: Design & Define
Purpose: To understand the client’s vision and agree on a precise specification for the app.
After a client reaches out and we learn about their needs, we decide whether the client’s project and personality are a good fit for who we are and what we do.
We start with the client’s vision and turn it into a feature list and interactive mock-ups. Our clients show up with a lot of different starting points – anything from pixel-perfect illustrator files to an idea (“we need an app that shows users a list of their prescription medications”). What we do is take these various inputs and insert them into our process. Our most successful apps and clients don’t always have it all figured out when they come to us – which is great since we can help a lot with clarifying their goal and building the best app possible on their timeline and budget.
An open minded client with a willingness to collaborate is the biggest factor for a successful development sprint.
The Design & Define step is further broken into 4 parts which we’ll cover in detail in a future post:
- Defining the app’s goals and functionality
- Deciding what’s in and what’s out
- Designing the app (both on paper and digitally)
- Collecting feedback
Step 2: Architect
Purpose: To translate the precise specifications (spec) from the design step into technical, actionable development tasks.
The completed feature list contains precision but is not yet in a very technical language. At this point our Architects translate the precise spec we’ve agreed on into a technical spec. Once translated, all the hard technical decisions can be made up-front and hundreds of detailed development tasks are created. Here we’ll also tackle any high-risk development tasks – anything that might kill the project if we fail to deliver on them.
Architecting a new app is further broken into several steps (which we’ll cover in detail in a future post):
- Translate our precise language into a technical language
- Identify as many stumbling blocks as we can before we start coding
- Make hundreds of design and technical decisions
- Perform the highest risk development tasks to buy-down risk
Step 3: Build MVP 0.8
Purpose: Crank out code to quickly get the basic app done and into the client’s hands.
Enter the dumb brain! The tasks are set, several rounds of tough decisions have already been made, priorities are known, and now it’s time to execute. While we sometimes call this a “code-monkey” phase internally, this is when our developers get sit down and crank out the very valuable code that makes an app actually work.
Our internal Quality Assurance (QA) team follows along, reviewing code and the current state of the app to catch any issues as they enter the codebase. At the end of several days of hard-core coding the client receives the very first realization of their idea. We deliver as much of the finished product as we possibly can so that we can spend the next day or so tweaking the app with the client’s feedback.
The basic elements of this building v0.8 are:
- Development
- Quality Assurance (QA)
- Listening to feedback from client
Step 4: Build v0.9
Purpose: To act on client feedback and polish the app.
Dumb brain continued! We take client and user feedback and do our very best to integrate as many improvements as we can. Throughout this period we shift our focus from developing new features to polishing the app and fixing any bugs we’ve discovered.
The development team isn’t making any new decisions, but simply executing on the decisions and priorities that we’ve already made. Once we push MVP 0.9 to the client, we’re almost completely focused on crushing bugs and not on rolling out new features.
The elements of Building v0.9 are:
- Decide on what changes we want to make to the original plan
- Execute on them
- and do Quality Assurance (QA)
Step 5: Ship v1.0 & Party
Purpose: To crush bugs, wrap up loose ends, and celebrate what we’ve built together.
After the previous step, we’ve identified all of the fixes that we need to make so that we can execute on them and hit our client’s deadline. The Quality Assurance team tests things again and again so that the final version of the MVP is as close to perfect as we can make it.
After we’re all feeling good, we ship the app…and party.
It may seem ridiculous to actually include a party in our process but we’ve learned that’s it’s essential for generating momentum for the client and launching the app on the right foot. And you never know who will show up to the celebration – your future investor, your growth hacker, or your new CTO.
Shipping v1.0 is easy, we:
- Destroy all bugs
- Deliver v1.0 to either beta customers or the App Store
- and Party!
We’ll go over each step of our development process in depth in future posts but in this post we’ve shared what we do at the 30,000-ft level.
If you only take one thing away from this post, here’s what it should be: Solving complex problems requires separating decision-making (“smart brain”) from execution (“dumb brain”). #tweetMe
If you’re interested in learning more about our process, check out one of our client spotlights: The PocketLab, which raised over $100,000 from over 900 backers to bring really cool sensor technology into the hands of explorers and students everywhere.
Two things for the comments:
1) If you’ve ever thought about building a business with a mobile app, tell me how you’d go about getting your dream built.
2) If you’re a developer, tell me about your process for doing high quality work on tight timelines.