Building an App as a Solo Developer — 6 Stage Development Plan
A solo developer building a fully featured commercial application faces a number of challenges not faced by startups and dev teams, the largest of which is he’s on his own: one decision maker, one perspective, one opinion, one set of skills and experience.
There’s no one to shout out when a bad decision is made, there’s no voice of dissent in the room, no one suggesting alternative solutions. The solitary developer has only his own experience and knowledge to rely upon when building something new and pushing it out to market.
What’s generally absent from the solo developer’s toolkit, and what would help mitigate the effects of this isolation is a detailed development plan, a full roadmap taking in the first year of the app’s development.
My six stage development plan for building a new app is designed for solo developers just like me, looking to take a new product from initial idea all the way to a commercial application selling to users and companies around the world.
Saying “Ship it” is easy. Actually shipping that polished app is hard. Most solo developers fall down because of a failure to plan. They’re devs, so they want to code, not write documentation or outlines. But it’s that strict development plan that makes the difference between success and failure for so many side-project devs.
Why six stages? Why not a long list of features and to-do items?
You need milestones. You need to feel that sense of achievement as you complete Stage 2 and move on to Stage 3. You need production release builds with sets of features planned out in advance. You need to see those release dates coming and celebrate as they happen.
You need to be able to drag a feature from Stage 3 and drop it into Stage 4 or even Stage 6 after early users express complete disinterest. You need a structured place to add new features and ideas that will come to you as you work, instead of rushing headlong into building them now.
Before I dig into the six stages, a word of caution. This plan is all about the technical process of building your app; it does not address the product / market fit question. Are you building something people want? Something that people will pay for? Are you solving a genuine problem or addressing a real pain point? That’s the subject of another post (or book), but for now I’ll point you to a truly excellent book written by Rob Fitzpatrick called The Mom Test. I wish I’d had access to this book ten years ago.
Once you have your idea firmly fixed in your mind, you need to identify the niche market you’ll be building your early versions for. You should select the smallest niche possible so you can more easily dominate that sector. You’re a one man band, not Microsoft. You don’t have the resources or the time to build a generic app right now, and if you did you have no way to reach all those potential users.
Start small and stay focused on your niche.
Stage 1. Decisions
Before you write a single line of code, before you pull together any wire-frames or sketches, you need to make some decisions on the tech stack you’ll be using for your new app. To do this, look at two things: the requirements of the app and your own skill set.
If you’re building a desktop app, will it need to be cross platform? For a web app, will it be used primarily on mobile devices, on lap tops and desktops, or on both? Once you’ve worked out what the use cases will be, you can decide what kinds of tech you should be looking at.
The next step is to look at your own areas of expertise and see if these can be used to build everything you need. If you’re a .Net guy like me, is .Net Core strong enough to build out your backend? If your database experience is all Oracle, is that a viable database to use for a SaaS app? If not, you’ll have to step outside your comfort zone and choose something else.
What about the UI? If you’re a full stack developer with strong experience with Angular, then you’re in luck. If your UI experience is all jQuery version 1, you need to take a hard look at whether that particular library is strong enough for the app you’re looking to build. If you’re a backend developer with little UI experience, you need to look for a UI framework that’s quick and intuitive to learn.
Let’s assume that your experience gives you 80% of the skills you need out of the box. That leaves 20% of the tech you’ll be using that you’re unfamiliar with. You need to start learning this right now. Watch some videos on Pluralsight, Coursera, or YouTube. Buy a book or two on Amazon and plow through them quickly.
Look into third party tools that can save you time. You don’t have to decide on these right now, but you should be aware of them so that when you do reach the stage that they might be useful you don’t find yourself spending a month building your own solution when an off-the-shelf package would do all the work for you at a small cost. Do this before you move to Stage 2, before you write any code for your app.
What about the hosting? Do you need to decide on this right away or can it wait? My experience here tells me to wait it out. Your early pre-release versions will all be running locally. You can decide on Azure, AWS, DigitalOcean, etc. further down the road as you get closer to that first public release.
Stage 2. Localhost
Trim your Stage 2 feature list to the bone. In Stage 2 you don’t want a list of features your early users must have, you want a core set of features without which there is no app. Why? Because you don’t truthfully know what that must-have feature list is yet — you’ll learn that over time as your app starts interacting with users.
So what does a basic working instance consist of? It should allow you to open the app, edit or make changes, and save those changes to the database at the backend.
The goal of Stage 2 is to pull the disparate parts of your application together and make sure they work and flow in sync, that all the bits are in place. Your UI framework and code is all building, it’s communicating with your backend correctly, which in turn is reading and writing to your database.
That’s it.
It doesn’t need to be pretty. It doesn’t need to have a user log in mechanism — at this stage you are the sole user. It doesn’t need to be communicating with any services hosted on Azure or pulling in any external data sources.
Make it run locally, and then start using it yourself as much as possible. Let the dogfooding begin.
Stage 3. Show Hacker News
This is when you show Hacker News. And this is when you ask users to pay you money.
Your first beta release should contain the basic functionality that allows a user to do something valuable and important to them. It’s an MVP where the primary emphasis is on Viable. When you first came up with the idea for your app, you had a starting point, a basic set of functionality that lay at the heart of your offering. That functionality needs to be there now, and it needs to work well and look slick and professional.
At this point you need to investigate and decide on where you’ll be hosting. You also need to allow for user authentication and identity management — preferably using a third party resource that you may have to pay for. I’d recommend taking a look at AuthO.
You should be focusing on what makes your product unique, what separates it out from the competition. You should not be reinventing the wheel, building out login and authentication modules, or rolling your own payment methods. Investigate and decide on third party tools to do these mundane but super important tasks for you. Keep your focus on the unique features of your app, not on the things it shares with all other apps.
Release your beta version and then tell people about it. Your target user at Stage 3 should be the visionaries, pre-early adopters who love trying out new things. Hacker News is where you’ll find them.
Stage 4. Tell the world
Your app is ready for prime time. Now is the time to tell the world, or at least the world where your niche users live and breathe. It has a rich, if incomplete set of features, and it meets most of the needs of the niche market you’ve chosen to target. It should contain many of those enticing features you dreamed up over the weeks or months prior to writing code.
This is the product that a dev team at a large company can often spend months or even years building, and that you’ve now pushed out rapidly. How do you achieve this?
Way back in Stage 1 you made decisions about your tech stack. You decided on languages and frameworks. You should also have decided on whether you were going to roll your own UI components or go with commercial suites of components. Most developers love building new things. Their default answer is always to build their own.
As with authentication and payment modules, this is often a mistake. Sure, it gives you total control over how your components look and feel and behave, but it adds hugely to the time it takes to build your app. Remember, you’re a one man shop on a budget, you don’t have the luxury of spending weeks on every component. You need to be building faster and with greater confidence.
Professional third party component suites will allow you to do that, and will add a consistency that is often missing from solo developer apps. I’d recommend taking at look at DevExtreme for a frontend example of what third party tools can provide off-the-shelf. Don’t shy away from backend components either. Remember, you should be spending your time on what makes your product unique, not reinventing the wheel.
Now go tell the world about your fantastic new app.
Stage 5. Integration
Now is the time to release that Pro or Enterprise edition. If you’re building a B2B app, add in a single sign on option coupled with premium support, all accessible from a new pricing tier targeting larger companies.
If you followed the earlier advice in Stage 3 and used a third party to handle your authentication and identity management, this should be a simple box ticking exercise instead of a major piece of development.
Stage 5 is also where you should look at integrating with other apps and services. Grow your users and audience through add ins and plugins, make it as easy as possible for a new user to fit your app into their existing workflow. Mailchimp is a prime example of how a small company can grow through integrating with other apps.
Stage 6: Expansion
You now have a polished, professional app that meets the needs of small and large users in your target niche. Time to expand and take over the world.
Just as Facebook began at Harvard, dominating a small segment of users before expanding outwards to the wider world, you too should use the beachhead you established building your core app for a small niche and expand outwards.
All those generic features that you left out because they were not specific or targeted enough for your initial users need to be re-opened and looked at with a wider user base in mind.
At this stage you’re no longer a solo developer. Expansion has enabled you to start hiring more devs. You have UX people, dedicated UI designers who bemoan the fact that you chose that third party component suite way back when, and experienced backend guys who constantly critique your early architecture.
Such is life. Welcome to success.
Originally published at http://darrendevitt.com on April 3, 2020.
