The best and worst thing about solo development is the “solo” part. There’s a lot of freedom in working alone, and that freedom can be inspiring, but it can also become a debilitating hindrance to productivity and progress. Victor Ayomipo shares his personal lessons on what it takes to navigate solo development and build the “right” app.
As expected from anyone who has ever tried building anything solo, my goal was not to build an app but the app — the one app that’s so good you wonder how you ever survived without it. I had everything in place: wireframes, a to-do list, project structure — you name it. Then I started building. Just not the product. I started with the landing page for it, which took me four days, and I hadn’t even touched the app’s core features yet. The idea itself was so good I had to start marketing it right away!
I found myself making every detail perfect: every color, shadow, gradient, font size, margin, and padding had to be spot on. I don’t even want to say how long the logo took.
Spoiler:
No one cares about your logo.
Why did I get so stuck on something that was never even part of the core app I wanted so badly to build? Why wasn’t I nagging myself to move on when I clearly needed to?
The reality of solo development is that there is no one to tell you when to stop or simply say, “Yo, this is good enough! Move on.“ Most users don’t care whether a login button is yellow or green. What they want (and need) is a button that works and solves their problem when clicking it.
Test Early And Often
Unnecessary tweaks, indecisive UI decisions, and perfectionism are the core reasons I spend more time on things than necessary.
Like most solo developers, I also started with the hope of pushing out builds with the efficiency of a large-scale team. But it is easier said than done.
When building solo, you start coding, then you maybe notice a design flaw, and you switch to fixing it, then a bug appears, and you try fixing that, and voilà — the day is gone. There comes a time when it hits you that, “You know what? It’s time to build messy.” That’s when good intentions of project and product management go out the window, and that’s when I find myself working by the seat of my pants rather than plowing forward with defined goals and actionable tasks that are based on good UI/UX principles, like storyboards, user personas, and basic prioritization.
This realization is something you have to experience to grasp fully. The trick I’ve learned is to focus on getting something out there for people to see and then work on actual feedback. In other words,
“
Because guess what? Even if you have the greatest app idea in the world, you’re never going to make it perfect until you start receiving feedback on it. You’re no mind reader — as much as we all want to be one — and some insights (often the most relevant) can only be received through real user feedback and analytics. Sure, your early assumptions may be correct, but how do you know until you ship them and start evaluating them?
Nowadays, I like to tell others (and myself) to work from hypotheses instead of absolutes. Make an assertion, describe how you intend to test it, and then ship it. With that, you can gather relevant insights that you can use to get closer to perfection — whatever that is.
Strength In Recognizing Weakness
Let’s be real: Building a full application on your own is not an easy feat. I’d say it’s like trying to build a house by yourself; it seems doable, but the reality is that it takes a lot more hands than the ones you have to make it happen. And not only to make it happen but to make it happen well.
There’s only so much one person can do, and admitting your strengths and weaknesses up-front will serve you well by avoiding the trap that you can do it all alone.
I once attempted to build a project management app alone. I knew it might be difficult, but I was confident. Within a few days, this “simple” project grew legs and expanded with new features like team collaboration, analytics, time tracking, and custom reports being added, many of which I was super excited to make.
Building a full app takes a lot of time. Think about it; you’re doing the work of a team all alone without any help. There’s no one to provide you with design assets, content, or back-end development. No stakeholder to “swoop and poop” on your ideas (which might be a good thing). Every decision, every line of code, and every design element is 100% on you alone.
It is technically possible to build a full-featured app solo, but when you think about it, there’s a reason why the concept of MVP exists. Take Instagram, for example; it wasn’t launched with reels, stories, creator’s insights, and so on. It started with one simple thing: photo sharing.
All I’m trying to say is start small, launch, and let users guide the evolution of the product. And if you can recruit more hands to help, that would be even better. Just remember to leverage your strengths and reinforce your weaknesses by leaning on other people’s strengths.
Yes, Think Like an MVP
The concept of a minimum viable product (MVP) has always been fascinating to me. In its simplest form, it means building the basic version of your idea that technically works and getting it in front of users. Yes, this is such a straightforward and widely distributed tip, but it’s still one of the hardest principles for solo developers to follow, particularly for me.
I mentioned earlier that my “genius” app idea grew legs. And lots of them. I had more ideas than I knew what to do with, and I hadn’t even written a reasonable amount of code! Sure, this app could be enhanced to support face ID, dark mode, advanced security, real-time results, and a bunch of other features. But all these could take months of development for an app that you’re not even certain users want.
I’ve learned to ask myself: “What would this project look like if it was easy to build?”. It’s so surreal how the answer almost always aligns with what users want. If you can distill your grand idea into a single indispensable idea that does one or two things extremely well, I think you’ll find — as I have — that the final result is laser-focused on solving real user problems.
Ship the simplest version first. Dark mode can wait. All you need is a well-defined idea, a hypothesis to test, and a functional prototype to validate that hypothesis; anything else is probably noise.
Handle Imperfection Gracefully
You may have heard about the “Ship it Fast” approach to development and instantly recognize the parallels between it and what I’ve discussed so far. In a sense, “Ship it Fast” is ultimately another way of describing an MVP: get the idea out fast and iterate on it just as quickly.
Some might disagree with the ship-fast approach and consider it reckless and unprofessional, which is understandable because, as developers, we care deeply about the quality of our work. However,
“
That’s why I like to tell other developers that shipping an MVP is the safest, most professional way to approach development. It forces you to stay in scope and on task without succumbing to your whimsies. I even go so far as to make myself swear an “Oath of Focus” at the start of every project.
I, Vayo, hereby solemnly swear (with one hand on this design blueprint) to make no changes, no additions, and no extra features until this app is fully built in all its MVP glory. I pledge to avoid the temptations of endless tweaking and the thoughts of “just one more feature.”
Only when a completed prototype is achieved will I consider any new features, enhancements, or tweaks.
Signed,
Vayo, Keeper of the MVP
Remember, there’s no one there to hold you accountable when you develop on your own. Taking a brief moment to pause and accepting that my first version won’t be flawless helps put me in the right headspace early in the project.
Prioritize What Matters
I have noticed that no matter what I build, there’s always going to be bugs. Always. If Google still has bugs in the Google Notes app, trust me, then it’s fine for a solo developer to accept that bugs will always be a part of any project.
Look at flaky tests. For instance, you could run a test over 1,000 times and get all greens, and then the next day, you run the same test, an error shows. It’s just the nature of software development. And for the case of endlessly adding features, it never ends either. There’s always going to be a new feature that you’re excited about. The challenge is to curb some of that enthusiasm and shelve it responsibly for a later time when it makes sense to work on it.
I’ve learned to categorize bugs and features into two types: intrusive and non-intrusive. Intrusive are those things that prevent projects from functioning properly until fixed, like crashes and serious errors. The non-intrusive items are silent ones. Sure, they should be fixed, but the product will work just fine and won’t prevent users from getting value if they aren’t addressed right away.
You may want to categorize your bugs and features in other ways, and I’ve seen plenty of other examples, including:
- High value, low value;
- High effort, low effort;
- High-cost, low-cost;
- Need to have, nice to have.
I’ve even seen developers and teams use these categorizations to create some fancy priority “score” that considers each category. Whatever it is that helps you stay focused and on-task is going to be the right approach for you more than what specific category you use.
Live With Your Stack
Here’s a classic conundrum in development circles:
Should I use React? Or NextJS? Or wait, how about Vue? I heard it’s more optimized. But hold on, I read that React Redux is dead and that Zustand is the new hot tool.
And just like that, you’ve spent an entire day thinking about nothing but the tech stack you’re using to build the darn thing.
We all know that an average user could care less about the tech stack under the hood. Go ahead and ask your mom what tech stack WhatsApp is built on, and let me know what she says. Most times, it’s just us who obsesses about tech stacks, and that usually only happens when we’re asked to check under the hood.
I have come to accept that there will always be new tech stacks released every single day with the promise of 50% performance and 10% less code. That new tool might scale better, but do I actually have a scaling problem with my current number of zero users? Probably not.
My advice:
Pick the tools you work with best and stick to those tools until they start working against you.
“
There’s no use fighting something early if something you already know and use gets the job done. Basically, don’t prematurely optimize or constantly chase the latest shiny object.
Do Design Before The First Line of Code
I know lots of solo developers out there suck at design, and I’m probably among the top 50. My design process has traditionally been to open VS Code, create a new project, and start building the idea in whatever way comes to mind. No design assets, comps, or wireframes to work with — just pure, unstructured improvisation. That’s not a good idea, and it’s a habit I’m actively trying to break.
These days, I make sure to have a blueprint of what I’m building before I start writing code. Once I have that, I make sure to follow through and not change anything to respect my “Oath of Focus.”
I like how many teams call comps and wireframes “project artifacts.” They are pieces of evidence that provide a source of truth for how something looks and works. You might be the sort of person who works better with sets of requirements, and that’s totally fine. But having some sort of documentation that you can point back to in your work is like having a turn-by-turn navigation on a long road trip — it’s indispensable for getting where you need to go.
And what if you’re like me and don’t pride yourself on being the best designer? That’s another opportunity to admit your weaknesses up-front and recruit help from someone with those strengths. That way, you can articulate the goal and focus on what you’re good at.
Give Yourself Timelines
Personally, without deadlines, I’m almost unstoppable at procrastinating. I’ve started setting time limits when building any project, as it helps with procrastination and makes sure something is pushed out at a specified time. Although this won’t work without accountability, I feel the two work hand in hand.
I set a 2–3 week deadline to build a project. And no matter what, as soon as that time is up, I must post or share the work in its current state on my socials. Because of this, I’m not in my comfort zone anymore because I won’t want to share a half-baked project with the public; I’m conditioned to work faster and get it all done. It’s interesting to see the length of time you can go if you can trick your brain.
I realize that this is an extreme constraint, and it may not work for you. I’m just the kind of person who needs to know what my boundaries are. Setting deadlines and respecting them makes me a more disciplined developer. More than that, it makes me work efficiently because I stop overthinking things when I know I have a fixed amount of time, and that leads to faster builds.
Conclusion
The best and worst thing about solo development is the “solo” part. There’s a lot of freedom in working alone, and that freedom can be inspiring. However, all that freedom can be intoxicating, and if left unchecked, it becomes a debilitating hindrance to productivity and progress. That’s a good reason why solo development isn’t for everyone. Some folks will respond a lot better to a team environment.
But if you are a solo developer, then I hope my personal experiences are helpful to you. I’ve had to look hard at myself in the mirror many days to come to realize that I am not a perfect developer who can build the “perfect” app alone. It takes planning, discipline, and humility to make anything, especially the right app that does exactly the right thing.
Ideas are cheap and easy, but stepping out of our freedom and adding our own constraints based on progress over perfection is the secret sauce that keeps us moving and spending our time on those essential things.
