6 lessons after publishing my first app to App Store & Google Play

Paweł Łubiarz
11 min readApr 20, 2020

Three years ago, our web application received 30 press publications including Forbes, just in two weeks. Our users enjoyed the service itself but strongly required to have it in a more handy version.

Unfortunately, the technical debt of our MVP made it completely unprofitable to maintain the platform. Additionally, as a young founder in the role of Product Owner, I had no experience with mobile apps.

As a result of our technical capabilities shortage, the project was frozen. It took us three years to reassemble a new, seasoned team and publish the App in App Store & Google Play.

Why it took us so long?

First of all, I quit my job in the public relations sector and switched to IT to better understand how to revive the project.

When I was working on MyLuggage after hours, I was simultaneously participating in dozens of other IT projects. New perspectives resulted in a decent investment round which has brought us back to the game.

Till that point, you may wonder…

How my lessons might help you in your business?

After getting more and more experience in app development I realised that other founders face almost the problems, which in most cases lead to bad decisions.

After making an honest retrospection of my own business and getting a closer look at other projects I ended up with two conclusions:

  • The pool of potential cost savings lies predominantly in the pre-development phase
  • The cost of bad decisions might even double or triple the development cost

By applying the newly acquired knowledge, our second approach to app development was a success. The 6 lessons below contain best practices which allowed us to publish the app and receive positive feedback from our early adopters. These lessons will help you to recognize and eliminate potential mistakes, which may result in saving cash while keeping you focused on the most important thing: delivering the value for your users.

1. Don’t start the development before prototyping

As an Owner, you might think that you know clearly what you want. However, it is often the case — consciously or not — that you do not know what your customers want. Without building a clickable prototype, your product is more likely to face errors design logic. These misconceptions will definitely lead to negative feedback from users.

The consequences of skipping the prototyping phase will be visible in costs, as well as in the prolonged development time.

What is prototyping? It’s an opportunity to get an idea of what the final product will look like before additional resources, such as time and money, are put into finalizing the product itself. It gives you an opportunity to evaluate the product, ensure it’s performing as intended, and determine if improvements need to be made.

Without clickable wireframes, you won’t have a chance to test the logic of your platform or ask users for feedback. You can improve the feedback output by making your prototype clickable so everybody will get a feeling that is indistinguishable from the real experience.

The chart below presents the relationship between a scenario with the testing phase at the beginning and without it. The critical problem about development without a prototyping phase is a missed chance to test the product before the development begins. In another case, to test the product you will have to wait actually till… it is ready to test, with hundreds of hours spent on development. In result, all changes inexorably balloon the cost and delay the release date.

The increased cost of development without prototyping

Prototyping lowers the cost of development, but how about the timing? Does the additional development phase exceed the overall project time? You might think that prototyping doesn’t exceed the time of development, but it’s the opposite. When it comes to testing when the development phase is more advanced it occurs that the product needs a lot of improvements, which are really costly as they weren’t planned at the beginning.

How to create a clickable prototype

It’s easy. There are many very intuitive tools like InVision, Adobe XD, Sketch or Zeplin. Nevertheless, it all starts on paper and whiteboard. If you want to drill into prototyping, read more information here.

What was missing in my case?

Wireframes were present, but sufficient testing with end-users was not conducted. We tested the wireframes only internally. Thanks to our great team the UX experience was rated really well, but the most important screen of the app wad dubbed short of “overwhelming”. We had to commit additional resources to map, solve and develop a proper solution. It could have been avoided by running the clickable prototype with end-users and just asking the right questions.

2. Focus on the product

Predicting revenue streams in startups before the development stage is a puzzle of its own. From one side, your potential investors might tell you to provide detailed analysis for the market and predictions about your revenue streams (that was my case). On the other hand, they might just want to make sure that you know how to work with numbers and you are not oblivious to marketing in general.

As it happens, it’s almost always about the second case. Without users & real product, you can only guess what part of the market might be yours. Even with numbers, the reality shows that in most cases it’s a wild guess. Below you can see how this relationship works.

The relation between time spent on estimating revenue and accuracy. The % of accuracy is based on sight.

For some reason, I put everything in a table. I created a massive spreadsheet with tons of data. It came across as extremely impressive, I’ve learned a lot and… wasted a lot of time on making estimations without any sense. Even with all those numbers, I got rejected by all investors. Why?

I wasn’t focused on a product. The numbers can’t get real If you don’t deliver a must-have product. How can you achieve this when your focus is somewhere else?

Lessons learned:

  • estimation is only an estimation, the end-numbers will be different
  • spending more time on forecasting at some point is no longer effective
  • the big picture & your accounting skills matters

When looking for an investor or a co-founder, do not attempt to convince everyone what your earings will look like in five years. Powerful spreadsheets are not so potent a sales tool at the end of the day. Your skills & product vision matters.

The main goal of preparing all of this estimations & paperwork is to make sure that you know your market and you won’t have problems with similar estimations in the future.

3. Choose the right technology stack

If you’re not a technical expert that might be a tough beast to tame. There are various tech solutions where each of them might have a significant impact on development costs, app performance or general maintenance in the long run.

In the beginning, my challenge was all about money, as each technology might have more or less expensive professional developers. The cost could be depended on how many specialists are on the market or how complicated it is to code in a certain technology. Costs are also depended also on development time as again each technology has also a subtly different speed of development.

If this wasn’t bad enough, there are major differences between apps. You could make a choice between Native Apps (built with specific technology and language for a specific platform like Java for Android, Swift for iOS) and Hybrid Apps (using web technologies like HTML, CSS and JavaScript).

The main advantage of a hybrid app is that it can be built for any platform from a single code base, which means that you can save time by creating only one app instead of writing it separately for Android and iOS. Here you can learn more about the differences between Hybrid and Native apps.

Our choice? Ionic. We’ve decided to use Ionic framework with Angular for our Frontend and Laraverl PHP for the backend part of the app.

We were looking for a solution which will allow us to have the same backend for both web & mobile app. Thanks to this solution once you create an account within the app you will see the same content on our website.

Moreover, after analysing the app architecture we came up with the conclusion that hybrid app will be much faster in our case. We could also use a lot of native elements offered by Ionic.

Drawbacks? Problems with performance. Native apps, in general, are faster than hybrid apps. We’re facing small problems with the app speed, but so far it is not prohibitive. All in all, If I had an opportunity to change my decision I would stay with the Ionic, mostly because of the size of our team and the budget.

What technology would be best for your app? I believe it depends on the available resources. I would say that if you have enough money and your team is capable of delivering a native application you should definitely go for it. On the other hand, hybrid apps will save you a lot of time in the beginning but might be harder to maintain in the future.

4. Test the product during the development phase

Fortunately, in this case, I managed to keep things within acceptable reigns, but after working in a software house for a while I can’t skip this point without a comment. Some founders tend to test the product a few days before the expected release date. They believe that the tech team should solve every problem and they’re going mad when things don’t go as expected.

Testing the app during the development phase

This approach won’t work. When we’re not conscious about what’s going on in the first development phases we give up the context and opportunity to apply any adjustments live.

Testing just before the release generates a lot of unexpected tasks, so once it happens it’s almost clear that we will miss the release date. Moreover, this is not the end of your problems. The cost of implementing all of these changes will be higher than at the beginning because those changes weren’t planned when the architecture of the app was created.

In most cases, development teams work in iterations (two-week sprints), which aim to deliver new functionalities sprint after sprint. As a Product Owner, you have to always test the product and based on presented deliverables adjust further plans for development.

When it comes to testing, I always advise to work on as real content as possible. Many projects start with a design phase using dummy content (Lorem Ipsum text), but these potential savings will lead to many unpredictable edge-cases in future development. Thanks to this approach you would increase your chance to spot potential errors in platform logic and layout.

5. Expect the delay

That might come across as bizarre, but trust me, after developing over a dozen apps, it’s clear to me that almost all organizations fail on delivering software on time. There are a lot of reasons, but from the MVP perspective in most cases, it is a lack of experience in product development.

I believe that seniority both from product & technical perspective occurs in strong and effective ability to spot and predict potential risks in the project. Lack of these experience means that the more you get into it, the more complicated it becomes. As explained in previous lessons, any course correction will be more and more expensive.

If you’re not a technical person and you don’t have a technical co-founder it’s more than likely that you won’t deliver your product on time. What could help?

  • Technical advisor
  • Technical co-founder

In my opinion, you have to have someone on-site, or you need to spend some time and get more low-level knowledge about the development process. Otherwise, you won’t be able to judge what is truth and what is fiction.

Even with technical expertise delivering on time is a paramount challenge. Software development doesn’t work like normal manufacture. You can’t purchase it like a hammer in the hardware store, so it lasts for ages. Software tends to have regress bugs and unexpected problems which might delay the product arrival.

As a Product Owner, you will have to often choose between the quality and use of resources. Keeping your budget tight might be imperative in many technological compromises which later on might be aggravating, to put mildly.

My advice: never assume initial assumptions as final deliverables. If you want to deliver a solid product you have to be open for feedback and adjust the development process to business realities.

6. Wait with scaling, focus on early adopters

The last lesson was learned three years ago when I published a web version of our MVP. Because of my background in public relations sector, I’ve decided to start flaunting my startup in media, so we could acquire more users for free. The results were there, with 30 publications within two weeks and my first article in Forbes.

So what was wrong? We were not ready for unknown users, who weren’t interested in giving us feedback. Their simple desire was to use the service. Getting traction on early-stage without proper feedback might lead you to unexpected results. In our case, it occurred that users definitely wanted a more handy solution. They also wanted to access the app content offline.

In most cases, in such a situation the challenge would be to identify the solutions and apply proper implementation. In MyLuggage we knew that developing a mobile application will solve the pain points of our users.

I wouldn’t go to Forbes today, at least not now. The fact that our product was hot for a while but it was not yet ready for more users set us a dilemma — whether to invest in the current platform or focus on a new one. We dealt with the wrong problems. Before you go to the media, make sure you have a must-have product.

Bonus: start planning your launch strategy in advance

When you go public, timing is extremely important. The media, the customers, and your stakeholders will follow your actions. You can’t start planning all of these for one week before the launch date. Proper planning might require actions even for three months before the release. If you’re curious about how to plan a successful product market launch read my previous article.

Your feedback matters to me

Three years ago, 10,000 people used the web-based MVP, and some people shared their impressions. The app was built on their feedback and now it would be great to hear your opinion, so we could improve our product again!

Moreover, maybe besides testing, you would benefit from using our app? If you like traveling, MyLuggage might help you with preparing for any trip you want. Our app personalised packing lists matching your destination, so your travel might be stress-free.

Once again, If you find this article useful, test MyLuggage and let me know what we could do better by completing this survey or send me an email.

App download: Android & IOS

If your planning to work on your own product, follow my profile and get more free tips about product development.

--

--

Paweł Łubiarz

Product Manager at Piwik PRO | MyLuggage Founder | Helping startups to kick-off their products