Solo founder, CTO for a small team, or side-hustler. The story is the same. When your app goes down, you’re on the hook. So, what can you do to reduce those dreaded 2AM page alerts? There’s a lot of advice out there and the best of it falls into three groups: Be intentional Be honest about risk Buy, don’t build. Even then, most of that comes down to one key take away: getting value to users is the only thing that matters. There are no prizes for writing your own framework in an exotic language or tuning every last aspect of your server OS. Shipped code is everything. So, how does that translate to getting a better night’s sleep? Each step helps you reduce room for error. Let’s see how. Be intentional Starting a new project is like opening a toy box. There’s a world of possibilities. New technologies jostle for attention alongside old favorites. You get to learn by doing. Always wanted to try a NoSQL database? Great! Now, you can. Bored of React? Try Vue.JS, instead! But before you do, ask yourself a question: are you building a potential business or are you playing? Either answer is fine but the outcome is different. If learning something new is really what you want to do then create a hobby project. Playing with novel tech is great. But love it for what it is. It’s a chance to learn, not a business in the making. If delivering value to users is your main goal, then you need to be sure of how that impacts your technology choices. If you were an architect building an extension to your own house, you might experiment with unusual materials and techniques. If you’re building a new apartment block for clients, then you’d stick with tried and true methods that meet the brief, the budget, and the deadline. So, when you come to open that toy box, be intentional in making choices that simplify delivering value to your users. Be honest about risk Whether you're bootstrapped or funded, building a business is risky enough. Choosing a battle-tested tech stack is just one part of reducing risk. When we’re excited about a project, especially one that we’re building into a business, it’s easy to misjudge risk. To some extent, that’s healthy. Focus only on what could go wrong and you’d never open your laptop. I may be misremembering it, but there’s a saying that goes something like, “forewarned is good for your forearms”. Either way, knowing up front what might go wrong gives you a fighting chance when it does go wrong. Mapping out your risks doesn’t have to take long. Get a whiteboard, take each major part of your stack in turn, and write out anything that’s a realistic risk. Even thinking about the obvious stuff will help you come up with solutions. Buy, don’t build The last part is the easiest because it requires you to do less. Think back to why you’re doing this. There’s some unique value that you can bring to the world. Your one job is to deliver that value as efficiently as possible. If building your dream means working evenings and weekends, why would you want to spend them reinventing the wheel? And this isn’t just the obvious stuff. You probably haven’t considered writing your own frontend framework and no one is writing server side code in Assembler. But building your own server infrastructure and spending a chunk of your time on devops has become normalised in our culture. Outsource. Buy, don’t build. Find the fastest route from successful pull request to seeing that code in production. Deploy your product on a platform like Heroku, Google Cloud Run, or AWS Elastic Beanstalk. The point is to find the right tool for the job and then pay someone else to look after it, rather than deploy your code to a stock VM image that you need to manage into the wee hours. As the solo dev on a project, it’s your responsibility to stand on the shoulders of all those developers who went before you. Take advantage of other people’s expertise. If, later on, you need to swap a component out for something you’ve written yourself then take that decision when the need arises. It’s better to launch with off-the-shelf components that work rather than get stuck never finishing a home-grown solution. Sleep well, most of the time Bugs happen. Third-party systems go down. Corner cases become startlingly apparent at the moment you realise you hadn’t considered them. None of the advice here is to say that you can avoid the unknown. Instead, it’s about reducing your exposure to risk. Choosing Rails, Spring, or Django gives you the backing of a worldwide cohort of developers who have solved the same problems you’re working on. Mapping your risks gives you time to address them before they become a problem. Buying-in tooling and platforms means you can trust specialists to look after the commodity parts you need but that don’t make a material difference to your end users. As the solo developer on a project, maybe you can’t avoid ever being paged late at night but there’s a whole world of proven tech out there that can help you to reduce the risk.

Alongside

Google

Heroku

App Metrics 101: What You Should be Measuring

Subscribe to the Code[ish] Podcast

Read My Stories

Too Long; Didn't Read

Boost your HackerNoon story @ $159.99! 🚀

Three Bs to Avoid That 2AM alert

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

App Metrics 101: What You Should be Measuring

10 Lessons from 10 Years of AWS (part 2)

10 Lessons from 10 Years of AWS (part 1)

111 Stories To Learn About Architecture

13 Expert Tips to Improve Your Web Application Performance Today

App Metrics 101: What You Should be Measuring

10 Lessons from 10 Years of AWS (part 2)

10 Lessons from 10 Years of AWS (part 1)

111 Stories To Learn About Architecture

13 Expert Tips to Improve Your Web Application Performance Today

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps