Building your first app is never an easy thing. Three months ago, we embarked on building a native iOS app (written in Swift 2.0) for WayUp, the largest marketplace for college students to find employment. We started with a clean slate: no process, no code, and a brand new team (1 designer, 2 engineers, and 1 product manager). After defined some guiding principles, we bought into them and went to work. The result: this week, our app was accepted by Apple on the first try.
Identify and perfect the bare necessities.
The app’s features and functionality were deliberately and thoughtfully chosen. We didn’t want to have a bloated MVP, so we built the app to address only the most critical pieces of the job application process. There is no message center yet, there is no career advice (though keep an eye out for those features in the future!). We wanted to keep it simple and give our students what they need – JOBS.
Our app consists of the following major pieces of functionality:
We knew that the first two items above (Registration/Login and Job Application) were crucial to the app. We wanted our users to have a good first impression of the app; that meant we wanted to make it super easy to sign up and create an experience that was delightful to the user. In order to do this, we wanted to make sure that we left time to iterate on the signup and job application process. It was crucial that we nailed that and didn’t leave it until the end.
Establish a process that plays to your strengths
“We are going to be agile!” I always love that phrase: usually it’s muttered by people who haven’t really run development teams before. For us, agile, waterfall, scrum, kanban, extreme programming, none of it really mattered. What was important was that we established a process that allowed us to do the following:
In a team of people with distinct skill sets, it’s easy to get into the “it’s not my job” mentality. We avoided that by being completely transparent with the codebase, Sketch files, and Pivotal Tracker project. Anyone could file a bug and propose changes, anyone could modify and export design assets, and anyone could modify the codebase and make builds. This allowed the team to work faster, teach each other new skills, and (more importantly) build trust in one another. We developed a workflow that roughly looked like this:
Once these steps were complete we considered functionality “done” and would deliver a canary build to the company. After establishing this workflow, our goal was to deploy to the canary channel at least once a week and flow that feedback right back into the product, which we did. We delivered 8 builds internally to the company before we submitted the final app for review.
Mitigate your risk
Our process helped us inherently be risk averse:
People all too often fall into the trap of defining too much functionality and allowing apps to become overwhelming, so keep your first version simple and make sure you have a good testing strategy that allows for time to iterate. Most importantly, build a culture around the app. Even if you follow some of the suggestions laid out above, you still need your team to put in the time to build, test, and refine countless times before you get it right.
Good luck!
The job or internship search can feel like a rollercoaster, filled with thrilling highs— like…
Calling all undergrads and recent grads: kickstart your career with Kohl's! Finding the right path…
Deciding on a career path can be daunting, especially for students early in their post-secondary…
BlackRock is a global asset manager and a leading provider of investment, advisory, and risk…
Early career opportunities vary from summer internships and externships to entry-level positions. When exploring possibilities…
For some, going back to school after graduating college sounds like a nightmare. For others,…