5 things that helped me cut scope to build Futurospective
I recently built a new app from scratch and managed to go through the whole process — idea to re-learning code to publication — in 38 days. I already wrote a lengthy post about the high-level lessons learned but I wanted to get a bit more in depth and explain what happened behind the scenes.
Writing things down helps me organize my thoughts and see what I could have done better but I’ve also learned a lot from reading articles on the web. So maybe someone will benefit from my writing too?
So, without further ado, let’s dive into it.
I built Futurospective to help me fight imposter syndrome.
My confidence level resembles a roller-coaster where I can go through several days feeling like I’m totally nailing things, and then go through a trough of despair right after thinking that I’m just wasting time (Exhibit A with this project — I’ve been honestly surprised by the positive feedback I received).
So, to solve this problem I thought that I could periodically record a positive message that I would receive in the future when I might feel a bit down about myself.
I tried my best to keep the first version of the app simple and I wanted to share a few things that helped me ship my MVP. (For an experienced RN dev this would have been really long but I had to learn everything from scratch almost).
5 things I did to drastically simplify the roadmap
1. Distill the application down to its essence
That sounds obvious but when I build stuff for myself I often go straight into coding mode without giving it much thoughts beforehand. More often than not this results in me spending time solving problems that I could have avoided.
In this case I had a hard deadline, I needed to re-learn JS and I had to make sense of Redux. I wanted to make sure I wouldn’t waste time so I wrote down the core problem that I was trying to solve.
I want to record a message and get it back some time in the future.
I then identified my 3 high-level user stories:
- #1: As a user I can record a message to be published in the future.
- #2: As a user I can be notified when a message becomes available.
- #3 As a user I can view past messages that are available to me.
Doing this was probably the most important part of my project as it helped me make quick decisions about what would go into the MVP and what would stay out of it. For instance I decided to not implement the ability to save data remotely since my core goals would be met by keeping data on the phone.
My belief is that you shouldn’t have more than 5 of these top-level user stories — they’re almost like your elevator pitch. The risk in having more is that it can be later used to justify extra complexity while you want them instead to allow some flexibility. If, for instance, I found myself having trouble implementing video recording then I could have switched to saving text instead and still satisfy my #1 need.
2. Mapping user requirements to platforms capabilities
While I was pretty interested in learning more about React Native I had some good reasons to go mobile first rather than building a web application.
Futurospective is a personal application. By that I mean that the content you produce on it is intended to be for your eyes only. What that means is that Futurospective needed to satisfy the following conditions:
- Content must be saved against your account
- Content must be protected from other malicious users
- Users must be able to remove content if required
I could have built a web application that satisfies all these conditions but going mobile first would save me a lot of time.
Mobile phones are actually some tiny personal application servers.
- No need for account management: the mobile phone is unique the user.
- No need to manage an application server: all the logic would be handled on the phone.
- No need to manage a data store: data can be saved straight on the device.
- Data is already secured: I can rely on the existing password/thumbprint protection.
- Users own the data: they can easily delete everything by removing the app itself.
- No need to be highly available: The app is self-contained on the phone. If the phone is up & running then so is the application.
By spending some time upfront thinking about my core problems and the platform capabilities I made some decisions that saved me countless hours of coding. And there are also a lot of hidden costs to support a web application that needs to run 24/7 — I could avoid all that with a mobile app.
3. Picking React Native to build the applications
Prior to building Futurospective I had toyed a bit with React Native and I find it to be amazing. The same JS could be used to build an iOS and an Android application and I wouldn’t have to learn Swift or get back into Java.
I had some doubts about being able to use native capabilities of the devices but the React Native ecosystem is moving incredibly fast and I found several libraries that helped me solve some core issues:
- How to use the camera to record and play videos.
- How to push notifications locally.
- How to save structured data on the device.
Of course there are a few issues with React Native and I pulled my hair at times trying to debug things but overall I’d say that the cost of debugging and testing on 2 different devices was an order of magnitude lower than if I chose to build the MVP as a web app.
This is only true for Futurospective though. I might have picked a different approach if I was trying to build a more complex application because with each new screen and feature I’m doubling the cost of debugging and testing. In this case I managed to have the same code for both app but it took some efforts to get there as some libraries and patterns don’t work for both iOS and Android.
4. Sticking to video-only content
The 6th story that I wrote in my board was to allow users to record a text capsule. At the time I thought that maybe some people would be uncomfortable with the idea of recording a video of themselves.
But while it would give people more choices it would also add a lot of extra work:
- I would have to create a new screen to pick between text and video.
- I would have to implement screens to write, save and read text.
- I would have to handle text vs. video in the data model.
- I would have to handle text vs. video in the list of capsules.
- I would have to test / debug more to finish my app.
- Refactoring would probably have a greater scope as I would have to handle 2 types of recorded data.
Each one of these task is not hard by itself but it quickly adds up. And I could see that having a video-only app would make it much easier to use as well as being more impactful — a small text box wouldn’t convey as much emotion as a live content. (Images can be really powerful and you should read Gon if you can).
Sometimes less is more and in this case I definitely think that refusing to implement a feature makes the app more powerful as well as easier to code.
4. Setting attainable goals for design
I’m not good at UI design and it would take me hours to draft an icon that any designer could finish in a few minutes. So instead of setting my design goal to have a great looking application I wrote down the following:
This was a much more achievable goal for me and I relied on 2 great tools for that.
Paletton is a great tool to find a color palettes that would work with your product.
If you need buttons for your app I’d definitely encourage you to look into icon fonts instead of designing things yourselves. Icon fonts scale really well, are easy to use and there’s a great React Native package for it.
I’m not advocating bad design here and you need to absolutely pick something that makes sense for the users. But if you’re ready to bend a little you could gain a lot of time by using existing icon fonts (and seriously there are lots of options).
Things I would do differently in my next project
- Have a user flow next to me at all times
I made a user flow mid-project after implementing the basic camera recording capability. It wasn’t really a big issue but I reckon that on a bigger project I would have stuffed some things up.
- Make sure that I can automate the testing
I used a recent version of React Native that is relying on an alpha version of React. This caused me a lot of issues as I couldn’t implement automated end-to-end tests. I had to manually verify that the app was still working on iOS and Android after refactoring code or implementing new features.
There’s a bunch of other things I’ve written in lessons learned but those above can really be applied to any software project.
The application is open source and the board as well. Feel free to have a look at things and ask questions.