You can download the app here: https://apps.apple.com/au/app/everyday/id6505085902
Most of my career has been spent within the various forms of what could be described as “product teams’ — multidisciplinary group of people, charged with getting a mixture of software and services up on it’s feet to help and support users in doing the things they need to do. That’s probably the broadest way that I can describe the outcomes of the software making process. We make stuff that helps people better do what they need to do.
However recently, I’ve gone back to building my own things. Becoming a ‘product team of one’ and building my own things and taking up from on the number of games and utility apps I released to the AppStore around 10 years ago. All of these apps have expired, but I really wanted to go back to that phase in my life where I had multiple initiatives on the go.
The application I built was a simple pomodoro timer. I always seem to build timers, I’ve built 2 of them in the past. They’re my ‘go to’ first step whenever I start building anything new. In this case, the timer forms a small part of a much larger idea I have for a suite of productivity tools that work across MacOS and WatchOS.
The solo-approach is both refreshing and challenging. It provides an interesting counter-point to current roles within large organisation delivering ‘enterprise solutions’. At the same time exposing a few long-held beliefs and shapes your perspective on what’s important. I want to explore a few of them here, and see what stark differences there are between the work you do with others and the work you do when it’s just you.
What’s a viable MVP’s should be determined by your end goal.
This first release was my ‘MVP’. It wasn’t made to test a hypothesis, it was made so I could take a first step in delivering on a end-to-end production process. That is, taking and idea from inception all the way through to delivery within the AppStore and getting a first paying customer. Note: This happened at 8:454am, 12 hours after release.
As a solo developer, I had ambitious plans as to where I wanted to take this idea, but then I hit challenges to the time I could devote to this project, as well as limits to my own capabilities. I needed to scale back what I wanted to achieve in the first release. This was tough to do, but being frank about what I could achieve, and then re-framing it as a step towards a greater goal, really helped set what a viable first release should be. The ‘MVP’ wasn’t just a stripped down feature set of the full application, but a viable first step towards that goal. First steps are so important, that often it’s worth taking that step, regardless of what you do.
This is different to the many flavours of MVP’s I have experienced In enterprise, where an MVP is really just the first versions of the tool. It’s framed as an MVP because that title is usually used as excuse for gaps in performance and execution, with the suggestion that these things will be addresses in the future. They often never are, most likely as it’s never seen as a step towards some greater goal.
Technical hurdles are learning opportunities
Road blocks are inevitable. I’ve had many in the last few months, from gaps in my technical knowledge to internal blockers such as overcoming my need for perfection. In one case, an technical issue with auto-layout for a very simple part of the application took many many nights to resolve. I think in the end, it was written and re-written many times over several weeks. Why this is remarkable is that I could have solved this issue another way, removing the complex auto-layout requirements and displaying progress using a field and a number. I chose not to do it, because projects like these are also learning opportunities.
Reducing everything to only what you can make is really unambitious. It removes one of the key benefits of doing work like this, the opportunity to continually improve yourself and your capabilities. In many enterprises the search for efficiencies has driven this kind of behaviour out. Many designers can’t operate without a design system in place, and many developers rely heavily on frameworks which exert too much pressure on how software problems can be solved.
The other side to this is that moving away from style guides and frameworks, in this instance, gives you, as the maker, the opportunity to explore new areas in your work. I was interested in seeing how a nuemorphic approach would work in this context, what it means in terms of style and execution. What interactions work and what doesn’t. Was it really dead? Something that would be impossible to do if I was aligning with an organisation design system. Projects like this give you the opportunity to explore.
ChatGPT is a great teacher
Solving problems is monumentally easier with ChatGTP.
Using an LLM to help with low-level coding is a time-saver, but it’s also a great learning tool. In the past, I relied heavily on curated sites like stackOverflow to tackle all the programatic hurdles. ChatGPT though is next level as it provides code and context to specific questions. I often fed it my code and asked it help with parts of it. And I did this repeatedly to see a variety of approaches. The result is code that you can use directly in your work, code that is pretty specific to your context.
However, It is as a learning tool, where it excels. Many times I have asked it to explain, then re-explain things, like a tutor, so it’s value is not just the code it outputs but how it helps me become a better iOS developer.
However, I have built iOS apps for a few years, initially in Objective-C in, so my knowledge of MVC patterns, wasn’t that rusty. This meant that the quality of my queries probably helped generate quality responses from the LLM. If you were coming at this pretty green, than the value you can derive from using LLM’s may be more limited.
It’s hard to focus on what’s important
In many organisation, focusing on what’s really important is sometimes challenging, especially since a range of organisational priorities can effect what you (or the team) focus on. I’ve been in teams where wholesale changes in business direction has rendered many months of work to the bin. Likewise, individuals can exert top-down pressure on teams to focus on goals and outcomes that they see as important. Pushing the team to move into areas that are often not valuable or achieve the outcome you’re aiming for.
For a solo developer, you avoid many of these issues. It’s super easy to focus on what you want to achieve with what you’re building because it’s you (and only you) that decides what’s important. However, the ease in which you can make that single decision on where to focus can make it just as easy to abandon you efforts and shift to something else.
This is where I remind myself of an often-used quote from friend remarking that “there is a valley of death, littered with the corpses of unfinished side projects, left to perish as your attention shifts to the next new thing”
This is where diligence and consistency are some of the most important attributes to have. Basic habits, making yourself turn up every day, that’s what’s needed. And that’s what I hope this tool will end up being.
I love working in large enterprises and with large teams. For speed and range of execution, close partnerships across design, engineering, and strategy, can deliver amazing results. This is especially true for challenging and highly technical software — tools that support highly technical users and their capabilities. But coming at it from the angle of a Product team of 1, was an an eye-opener. As a learning process, nothing is better that first hand experience of the entire process. The tools available, from libraries through to GTP’s are massive aids, both in problem solving and for learning. But It’s greatest benefit is that it helped me refine my own design and development process, providing a deep understanding of this helps me operate more effectively in enterprise environment.
