I knew that anyone who had ever built anything alone would understand my goal. My goal was to create the app, the one app so good that you wonder how you survived without it. I had it all: wireframes and a to-do checklist, project structure, you name it. Then I began building. Just not the product. I spent four days creating the landing page, and I still hadn’t touched the app’s core functions. The idea was so great that I had to market it immediately! I spent hours perfecting every detail: color, gradient, font, size, margin and padding. I won’t say how long it took to create the logo. Spoiler:No one cares about the logo. Why did I spend so much time on something that wasn’t even a part of the app I wanted to build? Why didn’t I push myself to move forward when I knew I needed to? In solo development, there is no one who can tell you to stop or to say, “Yo! This is good enough!” Most users don’t really care if a login button is green or yellow. What they want and need is a button which solves their problem upon clicking it. Test Early and Often I spend more than necessary time on things because of unnecessary tweaks, indecisive decisions about the UI, and perfectionism. I started out like most solo developers with the goal of being able to push out builds as efficiently as a large team. It is easier said than accomplished. You start by coding. Then you notice a design problem and fix it. A bug then appears and you try to fix that. You will reach a point where you realize, “You know…?” It’s time to build mess. That’s when all the good intentions of product and project management go out the door, and I find myself working on the fly rather than focusing on defined goals and actionable steps that are based upon good UI/UX principals, such as storyboards and user personas. You have to live it to fully grasp this realization. I’ve learned to first focus on getting the idea out there and then to work on feedback. It’s important to get an idea out there, iterate and refine it rather than trying to achieve perfection from the start. Guess what? Even if you think you have the best app idea, you won’t be able to make it perfect unless you get feedback. Even though we’d all like to be able to read minds, you can’t. Some of the most valuable insights are only available through user feedback and analytics. Your initial assumptions may be accurate, but how can you tell until you start shipping and evaluating your product? Today, I tell myself and others to start with hypotheses rather than absolutes. Make a statement, describe the way you plan to test it and then ship it. You can then gather valuable insights to help you get closer to perfection, whatever that may be. Strength in Recognizing Weakness Let’s face it: building a complete application by yourself is not easy. I would say that it’s similar to trying to build a home by yourself. It seems possible, but in reality it takes more hands to make it happen. Not only do you want it to happen, but you also want it to happen well. You can only do so much as a single person. Admitting your strengths and weakness up front will help you avoid the trap of thinking you can do everything alone. I once tried to build a project-management app by myself. I knew it would be difficult, but was confident. This “simple project” grew legs within a few days and expanded, adding new features such as team collaboration, analytics and time tracking. I was excited to add many of these. It takes a long time to build a complete app. Imagine that you are doing the work of an entire team without any assistance. No one is going to help you with content, design assets, or backend development. No one to “swoop in and poop on your ideas” (which could be a good thing). You are responsible for every decision, every line in code, and each design element. Although it is technically possible to create a fully-featured application by yourself, the concept of MVP was created for a reason. Instagram was not launched with reels and stories, creator insights, etc. It began with a simple idea: photo sharing. I’m just trying to say that you should start small, launch the product, and let the users guide its evolution. It would be great if you could recruit more people to help. Remember to use your strengths to reinforce your weaknesses and leverage other people’s strength. Yes, Think like an MVP I’ve always been fascinated by the concept of a minimal viable product (MVP). In its simplest form it means creating a basic version of your concept that works technically and putting it in front users. This is a simple and widely-distributed tip, but for me, it’s one of the most difficult principles to follow. I mentioned that my “genius app” idea gained legs. There were a lot of them. I had so many ideas that I didn’t know what to do, and I hadn’t even written any code! This app could be improved to support face-ID, dark mode and advanced security. It could also have real-time results. All these features could take months to develop for an app you are not even sure users will want. I’ve learned to always ask myself, “What would the project look like if you made it easy to build?” It’s amazing how the answer almost always aligns exactly with what users want. If you can distill a grand idea down to a single indispensable concept that does one or a few things exceptionally well, you will find — just as I did — that the end result is laser focused on solving real user issues. Ship the simplest first. Dark mode can wait. You only need a clearly defined idea, a hypothesis that you can test, and a working prototype to prove your hypothesis. Anything else is likely noise. Handle Imperfections Gracefully You might have heard of the “Ship it Fast”, a development approach that is similar to what I’ve described so far. “Ship it Fast”, in a way, is another way to describe an MVP. Get the idea out quickly and iterate just as fast. Some may disagree with the approach of “ship-fast” and consider it reckless or unprofessional. This is understandable, because as developers we care deeply about our work. Ship-fast mentality does not mean to ignore quality, but to get something out ASAP so that you can learn from the real user experience. Ship it now and perfect it later. It’s for this reason that I tell other developers to ship an MVP as the most professional and safest way to approach development. It forces you to stay on task and in scope without giving in to your whims. I go so far as making myself swear an “Oath of Focus”, at the beginning of every project. Vayo hereby solemnly vows (with one hand placed on this design blueprint), to make no changes, additions, or extra features until the app is fully developed in its MVP glory. I promise to avoid the temptations and thoughts of “just adding one more feature.”

I will only consider new features, improvements, or tweaks after a prototype has been completed.

Signed,

Vayo, Keeper Of The MVP Remember that you are responsible for your own development. Accepting that my first version will not be perfect and taking a moment to pause helps me get into the right mindset early on in the project. Prioritize What’s Important I’ve noticed that no matter what product I create, there will always be bugs. Always. I’m sure that if Google has bugs in its Google Notes app then a solo developer can accept that bugs are always going to be a part any project. Look at flaky test results. You could, for example, run a test 1,000 times and receive all greens. The next day, when you run the test again, an error appears. It’s the nature of software. It’s the same with endlessly adding new features. You’ll always be excited about a new feature. The challenge is to control some of this enthusiasm and put it on hold until a time when it’s appropriate to work on it. I’ve learned how to categorize features and bugs into two categories: intrusive or non-intrusive. The intrusive items are those that prevent a project from working properly until they are fixed, such as crashes and serious errors. Silent items are non-intrusive. They should be fixed, yes, but they won’t stop the product from working and users will still get value if you don’t fix them right away. You can categorize bugs and features in many ways. I’ve seen examples such as: High value, Low value; High effort and low effort; High cost and low cost; Need to have and nice to have. I’ve seen teams and developers use these categorizations in order to create a fancy “priority score” that takes into account each category. It’s more important to focus on your task and stay focused than which category you choose. Live with Your Stack This is a classic question in the development community: Should I use React or NextJS? Or NextJS? Or what about Vue or NextJS? I’ve heard it’s better optimized. But wait, I just read that React Redux has died and that Zustand is now the hot tool. You’ve just spent an entire day thinking only about the tech stack that you’re using. We all know the average user doesn’t care about the tech stack. Ask your mother what tech stack WhatsApp was built on and let me know her answer. Most of the time, we are the only ones who obsess over tech stacks. We usually only do so when asked to look under hood. I’ve accepted that new tech stacks will be released every day, promising 50% performance and 10% fewer lines of code. This new tool may scale better, but am I really having a scaling issue with my current zero users? Most likely not. My advice is to stick with the tools that you find most useful until they begin to work against you. It’s not worth fighting early if you already know what works. Don’t optimize prematurely or chase the latest shiny thing. Do Design Before the First Line of Code There are many solo developers who are terrible at design. I’m probably in the top 50. My design process is to open VS Code and create a new Project, then start building the idea however it comes to me. There are no design assets, wireframes, or comps to use. Just pure, unstructured, improvisation. This is not a good habit, and I’m actively working to break it. Today, I always make sure I have a blueprint before I begin writing code. Once I have it, I follow through and don’t change anything. I respect my “Oath Of Focus.” I love how many teams refer to comps and wireframes as “project artifacts” because they are pieces of evidence which provide a source for truth about how something looks and functions. It’s perfectly fine if you work better with a set of requirements. It’s like having a road map on a long trip. It’s essential to get where you want to go. What if you are like me and do not consider yourself to be the best designer? This is another chance to admit your shortcomings and ask for help from someone who has those strengths. You can then focus on your strengths and articulate the goal. Give Yourself Deadlines I am almost unstoppable in procrastinating without deadlines. I have started setting time limits for any project. It helps me to procrastinate and ensures that something is completed at a specific time. This won’t work if you don’t have accountability, but I think the two go hand in hand. I set a deadline of 2-3 weeks to complete a project. No matter what, I have to post or share my work in its current form on social media as soon as the time limit is over. This has forced me to get out of my comfort zone because I don’t want to share half-baked projects with the public. I am now conditioned to work more quickly and finish everything. It’s amazing how long you can work if you can trick yourself. I know that this is a very extreme constraint and it may not be for you. I’m the type of person who has to know where my boundaries are. Setting deadlines, and observing them, makes me a disciplined developer. It also makes me more efficient because I don’t overthink things when I have a set amount of time. This leads to faster builds. Conclusion The “solo” aspect of solo development can be both the best and worst part. Working alone can bring a great deal of freedom, which can be inspiring. All that freedom, however, can be intoxicating and, if left unchecked becomes a debilitating hindrance for productivity and progress. Solo development is not for everyone. Some people will respond better to a group environment. If you are a sole developer, I hope that my personal experiences will be helpful to you. I had to look at myself in the face many times to realize that I was not a perfect app developer who could build the “perfect” application alone. To make anything, but especially an app that does the right thing, it takes planning, discipline and humility. Ideas are cheap and easy but adding constraints based on progress rather than perfection is what keeps us moving. Further Reading on SmashingMag: “What is the perfect design process?,” Vitaly Friedman, “Design Under Constraints – Challenges, Opportunities and Practical Strategies,” Paul Boag, “Improving the Double Diamond Design Process,” Andy Budd, “Unexpected learnings from coding artwork every day for five years,” Saskia Freike