From Idea to Shipping in 4 Weeks
This week, I pressed publish on the first app I’ve released in 3 years. I’ve worked on a number of other projects during that time - but never actually shipped any of them. What was different about this one?
Start to finish, the entire project took a month.
Every time I work on an app, I struggle with three things:
No deadlines
No scoping
Too much detail
This project was my first stab at prioritizing output over feeling busy by doing peripheral work. I gave myself one month to brainstorm, write, test, and release the MVP (minimum viable product) for the app - it didn’t need to be perfect, but it did need to be in a shippable state. To add to the challenge, I also did the entire thing in a new tech stack (SwiftUI), which I’ll talk more about in a future post.
This is the four-week blueprint that I set out for myself when I started building the app - I intend to keep refining this in the coming months as I work on more projects.
Week 1: Working Prototype
The goal of the first weekend was to have a working prototype by Sunday night. I essentially treated those two days as a hackathon, cobbling things together into a usable shell that showed off the concept, minus some features, polish, and testing.
One of the best things I’ve learned is to figure out the hardest problems first when starting a new project. These are the challenges that you don’t immediately know how to solve, and if you can’t solve them, it’s the end of the road. The sooner you can figure out whether your idea is plausible, the less time you’ll waste building parts of an app that you’ll need to scrap.
Given the simplicity of the app, I wasn’t too worried about insurmountable roadblocks, but I still focused on handling the biggest challenges upfront. It didn’t matter if the app was pretty, well-built, or buggy - at the end of the weekend, I had a proof of concept that I could play with, and I liked the project enough to want to keep building it out into something I could release.
Week 2: (Mostly) Feature-Complete, Refactoring
In the first week, I wasn’t able to implement all of the features I wanted for the MVP - the second week was spent filling in those gaps. These are the features that improve usability and quality of life, but the app was still useful without them (for example, the initial version of the app only allowed users to have a single move at a time - OK, but not great for anyone trying to move multiple kids into college).
I also started doing code refactoring where it made sense - in my initial sprint to get things working as fast as possible, I’d cut a lot of corners. This might be controversial, but I think that’s okay. What’s more important is being cognizant of which corners you can/should cut (and which ones will come back to haunt you later), and documenting your choices so you know what to fix down the line.
A pretty simple example of this was code reuse (or lack thereof) - there was a lot of duplicated logic that I had copy-pasted throughout the app before I knew what the interface would look like. Once things started to settle, I refactored pieces of the code to share logic where it made sense.
I also didn’t have a lot of experience with SwiftUI heading into this project - I’ve been actively learning it through tutorials for the past couple of months, but there’s a big difference between following along with someone else’s code and writing something from scratch. As a result, the code got cleaner throughout the project as I discovered better ways to solve problems related to managing state - and I’m pretty sure I’ll have a much easier time the next time I write a SwiftUI app.
Week 3: Stabilization, Refinement, and Testing
At this point, the app was fully functional, but there were a lot of rough edges related to the user experience. This was a combination of bugs, unintuitive design, and missing gestures that are OK in a prototype - but not for a shipping product.
Within the code, I was still doing some refactoring, trying to make things simpler and simpler to reduce code duplication and save future-me from some potential headaches. It also involved focusing on improving the app’s testability. This is the first of my (shipping) apps where I included automated test coverage, something that I’ve learned is incredibly valuable over the past 2.5 years of working in industry. Writing effective unit tests is challenging without a clean separation of concerns, and I spent several days rearranging the code to make the process of writing unit tests as streamlined as possible.
Speaking of test coverage - you can always add more test coverage. If I were to dedicate another month to working on this project, I would invest in additional testing - but the testing I did put in place was able to reveal some sneaky bugs, and it should provide some peace of mind when doing future updates.
Week 4: Manual Testing, Release Preparations
In the final days before release, I spent most of my time on testing (and addressing the issues I found). Despite all of the work I’d done to stabilize the app, there were still a ton of small paper cuts that needed to be addressed in the final days.
One of the main reasons for this is because developers generally interact with their software differently than end users.
While building the app, I was mostly doing surface level testing, ensuring that I could perform the basic operations. Real users don’t just add one task, type in a couple values, and make sure everything saved - they’re the ones really exercising the app, and they’re the ones who’ll be hitting all the edge cases.
The process of testing and fixing these kinds of issues was another hackathon-style weekend, which is something that I’d recommend avoiding…it created the feeling of needing to rush to get the app to a ‘done’ state. That being said, I don’t doubt that there are bugs in v1.0.0 of the app. My hope is that I’ve dealt with all of the significant issues, and that anything small that comes up can be addressed in patch releases on an as-needed basis.
The final step was actually releasing the app - this involved a last minute rebrand due to a lack of due diligence on my part when picking the original name, and I needed to build out test data that I could use for the App Store screenshots. There’s also a number of questions that Apple requires you to fill in about your app, as well as things like a description, tagline, etc. Once you’ve gone through this process once, it becomes a lot faster, but I remember this taking me a while when releasing some of my earlier apps.
Apple approved my app within 12 hours of putting it up for review, and it officially went on the App Store on Monday. It’s completely free for now, though that may change in the future depending on usage and how much more I invest into the project. More importantly, I actually shipped a project. I learned a lot while writing it, and it felt great to quickly move from an initial idea to releasing something.
I’ll be posting weekly updates here about what I’m building and what I’m learning along the way - if you want to see more articles like this, consider subscribing (you can also follow me on X for daily snippets).