9 Mistakes That Cost Me Money When Launching My App

From the first line of code to the first dollars in revenue, here are the things I'd do differently

After launching Olog 13 weeks ago, I'm excited to say that it's now generating a small amount of revenue.

The journey from the first line of code to having paying customers was riddled with excitement, misery, and unfortunately, a whole suite of mistakes that I'd never like to make again.

It's my hope that by sharing some of these mistakes, as well as the lessons learned, I'll be able to prevent you from making them in your own business projects in the future.

Here are 9 Mistakes That Cost Me Money When Launching My App:

#1 - Not launching with a way to get paid

While this may sound somewhat obvious to some readers, Silicon Valley culture has very much popularised the idea that if you hit a critical mass of users, your company will be worth an extraordinary amount of money regardless of your actual revenue.

This is true for a minority of companies only. Specifically, the cohort of venture-backed startups that are in markets that depend on either lengthy periods of research and development (R&D) or network effects, like social media.

For almost every other type of company, especially the bootstrapped solopreneur-type companies, you should build a way to get paid as soon as possible.

Otherwise, you're leaving money on the table.

When it comes to Olog, I launched it 13 weeks ago, but only added payments about 2 weeks ago. About 2 days later, I had my first paying customer, who bought an annual subscription to use the service.

There are many reasons to ask for payment early, but here are the two simplest and most important:

• It tests the most important assumption about your business - that users are willing to pay for what you're offering. No other analytics metric can provide assurances about this like revenue can.
• It greatly simplifies the process of building your company. As a solopreneur, it's so easy to get distracted by any of the hundred things you could be working on. Without revenue you can get stuck down unimportant rabbit holes very quickly. Having revenue sets a clear trajectory: make this number go up over time.

Lesson Learned: Put up a pay wall as soon as possible, even if your product does not meet your vision yet. Delaying this only leads to misery.

#2 - Spending Several Days Building an Illegal Stripe Integration

Both Apple and Google have quite strict rules around how you can accept payments within apps that are available in their respective app stores. This is primarily to ensure they get their 30% cut of all in-app purchases, a practice which has attracted much attention from anti-trust regulators.

Despite knowing that this rule existed, I decided to spend 3 or 4 days building a Stripe payment integration into Olog, thinking I could legally approach users outside of the app ecosystem to ask them for payment, essentially side-stepping the 30% platform fee.

Unfortunately that is not the case, as is clearly stated in the Apple App Store Review Guidelines:

In essence I wasted several thousand dollars worth of my own development time in the hopes of maybe saving myself a few bucks by illegally dodging the platform fee.

It was not worth it to try something so sneaky this early in the app's lifecycle. 30% of $0 is still $0.

Lessons Learned: Make sure you're up to date with the rules of the platforms you're launching on, and avoid premature optimisations at all cost.

Bizarrely, since I went through all this, Apple have announced they will let developers accept other payment methods but these changes are yet to take effect. Watch this space.

#3 - Not Building in Public

It's quite fashionable for developers on social media to build their apps in public - sharing screenshots, ideas, problems and successes they experience along the way. The idea behind this is that by documenting the journey from idea to launch and beyond, you build a very authentic following, simply by publicly documenting the process of building your project.

I ultimately decided not to do this for Olog, instead preferring to dedicating all of my time to building the features as fast as I possibly could. This was primarily because my target audience - Australian junior doctors - aren't exactly scrolling their Twitter feed at all hours of the day.

By the time the app was ready to release, I realised that having no people I could email on launch day is a big issue. I did have about 20 emails I'd collected just by talking to potential users, but I can see now how having more earlier on would have moved things along rapidly.

I also think the single most important aspect of building a following online is to share content consistently, and that takes time to demonstrate. I can hardly just flick that switch on now.

Lesson Learned: Build in public by consistently sharing your progress as you go. This will give you a following to announce your launch to when the time comes.

#4 - Not Adding my Feedback Button Earlier

Okay, this one didn't cost me money as much as it cost me opportunities, but anyway.

A few weeks ago I added a "Report a problem or make a suggestion" button right into the home screen of the app:

Rather than hiding a button like this deep in the settings, I wanted to make it as easy as possible for people to contact me if they had bright ideas or ran into a problem.

Since then, I've had 20+ messages that have had suggestions, bugs, problems or even friendly messages, all of which is 100% user-initiated.

Even better, because the feedback button goes straight to my email inbox, I'm often able to fix problems for users within a few minutes of them happening, leading to a far better user experience.

I just wonder if there were any early users who ran into problems who I could have helped more efficiently if I had this button in place earlier.

Lesson Learned: Put your feedback button in an unmissable, prominent location if you want people to use it. It's so important, especially in the early days.

#5 - Spending a Week Building a Feature No-one Wanted

Fairly early on in the process of building Olog, I got an idea for what I thought was a "killer feature" - something that would make Olog's offering so good that people would be almost oligated to use it.

That feature was GPS work tracking - a system that automatically documents the time that you arrive and leave your work place using GPS:

No-one had specifically requested this feature, but I had my heart set on the fact this was going to be the secret sauce that made Olog great.

As it turns out, this feature gets very little attention or use at all. Only one third of new Olog users choose to turn it on.

And between multiple operating systems, dozens of different devices, a range of different connectivity conditions in emergency departments and the like, troubleshooting the works with GPS work tracking has been very difficult.

Funnily enough, no-one seems to care that it doesn't work that well at times. I haven't had a single complaint about it.

Lesson Learned: Your assumptions about which features your users want might be wrong, so don't invest a lot of resources in building them until you have evidence that users want what you're building.

#6 - Spending too long thinking about theoretically correct software architecture

Elegant software design certainly has its place. If you're building something to a specification for a large contract, or to deploy right into an environment where you know a large amount of mission-critical information is going to be exchanged, you should absolutely design your software system with this in mind.

However, when you're building an app that you're not sure will get any use whatsoever, spending days crafting the perfect architecture diagram is an easy way to waste time. I'm not saying don't think about this at all - it can be useful - I'm merely saying it can also be a really nice way to feel productive when you're actually getting nothing tangible done at all.

I think the scientist and academic in me always really wants to have "technically correct" infrastructure, but experience has told me that in the hack-and-slash world of software sidehustling, it's very hard to do this correctly when the requirements of your app are likely to change so frequently.

Lesson Learned: Follow the 80/20 rule when it comes to software architecture in side-hustle projects. For 20% of the effort and time invesment, you get 80% of the benefits.

#7 - Waiting too long to build lifecycle emails

I watched a talk recently by solo SaaS juggernaut Patrick McKenzie who evangelised the power of lifecycle emails.

Have you ever joined a new website, and then wondered why they send you a frustrating amount of emails every time someone sends you a message or comments on something you've created?

The reason is because these lifecycle emails are unreasonably effective at re-engaging you into their service.

The difference between lifecycle emails and your common or garden variety emails is that they contain personalised information that a user might find useful right at the very time that they receive it.

For example, in Olog's case, if you have unclaimed overtime in your Olog account but haven't used the app in a while, I built a system that will send you a reminder about the money sitting there, waiting for you to claim.

This system has been extremely effective at prompting people to re-engage with the app, and in fact, all of my sales have come from users who have been re-engaged with lifecycle emails.

Lesson Learned: Well-timed lifecycle emails are a license to print money.

#8 - Not bottling my content marketing ideas earlier

Since launching Olog and shifting away from product development and more towards marketing, it's occurred to me that it's really hard to just sit down at your desk and spontaneously create compelling content. Creativity doesn't strike on demand.

In truth, all the while through building Olog I had spontaneous ideas for promotion - whether I was programming, cooking, or in the shower at the time. Such is the way the creative mind works.

What's important though, is to bottle and organise these shots of inspiration whenever they may strike. It's really hard to remember these otherwise.

A few weeks ago I set up a Notion dashboard with all my Olog content marketing ideas:

And with the Notion mobile app, any time I get an idea for an interesting piece of content, I can add it to the marketing dashboard and save it for later. That way, no ideas slip through the cracks, and I have a repository of ideas I can access when inspiration is running low.

Lesson Learned: The human mind is creating 24 hours a day. Put systems in place to bottle these creations and re-purpose them at your convenience.

#9 - Not talking to organisations earlier

Without saying too much, let's just say there are some large organisations I'd like to integrate Olog into in the future.

My experience with change management inside large healthcare organistions is that everything takes time: getting a meeting, getting an approval, or reaching any sort of consensus opinion can take months or even years depending on the project size.

I think I felt compelled to having a working product before I began these discussions which has ultimately put the project back several months in terms of progress towards integration.

Had I simply taken some half-baked screenshots and sent some "let's chat" emails on day 0, I suspect I'd be several months further along the line than I am now.

Lesson Learned: Rome wasn't built in a day. If you're dealing with large organisations, you don't need a working prototype. Start your discussions early.

You can learn more about Olog by going to the Olog landing page.