My experience building startup apps 9-5 for 3+ years

Building only! I wont be focusing on finding good project ideas or how to get funding, since I have no experience in this.

Hopefully my experience working for a venture studio developing Apps with multiple startups and established companies will shed a light into what it takes building software. I hope I can share some tips working with founders in the industry. Hopefully it will help out those who are not technical and would like to dip their toes in a technical project. 

note: I wont be focusing on finding good project ideas or how to get funding, since I have no experience in this. 

 There a few key points I want to mention starting out. 

(Job background: This job has taught me very quickly different stacks as I was building different applications all the time for different clients. In the long run I switched because of many of the startups would not get far and it could get quite exhausting building a new startup over and over and never being able to show something for it. The projects have never failed because of the tech but because of the underlying business idea not being viable and the founders would choose to pursue different ventures.)

Fixed costs

• Startups can be expensive to run and owners would not pay on time. Development is expensive by itself, there are fixed costs that come with developing software in a modern way. We have come a long way from drag and dropping sites to FTP servers. Almost any project will require the following:

  • CI/CD platforms to test and deploy code

  • hosting for backend, frontend, database, backups

  • domains

  • mailing list management

  • email suites

  • iOS/Android developer accounts and release fees

  • translation platforms to manage translations

  • headless CMS platforms for managing content

• When starting out it can feel like “Death by a Thousand Cuts” and many startup owners would end up wanting us to develop something just to avoid adding another fixed fee. Which in the long run would add more and more technical debt to the project because we have to now maintain the extra tool we developed for them.

• Clients that would leave us with the monthly fees and promise to pay in the future when they land an investment.

Development of the MVP

A team of two developers (frontend/backend) and a designer can develop a MVP for you under a few months as long the ideas and designs are set in stone. Here are more do-s and don't-s that I have learned so you don't have to.

• Do:

  • Get a third party technical consultant to estimate the costs and possibly setup the infrastructure requirements based on the design.

  • Get a full time team whenever possible. It is difficult to keep the projects context when working on multiple projects resulting in lower quality outcome if you juggle multiple projects. Often development is not the hardest part but understanding what to develop.

  • Get a design and designer before you start any development (you can start wire-framing yourself). There is nothing worse than developing a feature that is not properly thought out. Having to go back and remake it. Resulting in lost time, effort and money. Use Figma!

  • Start out with a smaller team

  • Keep the scope clean. Don't add features without testing them with users. Establish feedback loops. Keep the products purpose simple.

• Don't:

  • Not sharing your ideas. Ideas are plentiful, but Execution is what matters and it is hard

  • NO-CODE platforms. While it might feel great that you are able to do some progress alone. Eventually you will need a custom feature which is just not possible on these platforms. The developer team will have to start over.

  • Pay for infrastructure development for users that you don't have yet. Don't overestimate how much traffic your site will be getting.

  • Lack of vision, the-every-app, adding every feature you can come up with. Instead focus on getting each feature you release done properly. In development often the last 5% polishing takes the longest time.

  • Release too late your MVP. Often clients would keep adding features without validating the current state of the app. Jumping from features to other new features.

Do you really need an App? 

When it comes to developing mobile applications, there are a few different options available. One is to develop natively for iOS and Android. Or focusing on delivering on a single platform first.

• Pros:

  • have access to all of the device's features and capabilities, such as the camera, GPS, and accelerometer.

  • tend to have better performance because they are optimised for the specific platform they are running on.

• Cons:

  • Developing natively for both iOS and Android requires separate teams of developers, each with expertise in their respective platforms.
    The development process can be slower and more costly, as the same app has to be developed twice and often the teams end up with different products and delivery times.

Another option is to use a cross-platform framework, such as React Native or Flutter, which allows developers to create apps that can run on both iOS and Android with a single codebase. These also have their pro-s and drawbacks.

• Pros:

  • Cross-platform frameworks allow for a single codebase to be used for both iOS and Android, which can save time and resources.

  • React Native and Flutter are both open-source and have a large and active community of developers who contribute to its development and provide support.

  • Big ecosystem of packages ready to be consumed

• Cons:

  • Breaking changes which usually come with new OS releases take longer to implement since you are relying on the cross-platform framework to get updated first and other packages that you rely on.

  • The performance of cross-platform apps can be slower than native apps because they are not optimised for a specific platform.

  • Cross-platform frameworks may not have full access to all of the device's features and capabilities, and may require additional workarounds.

  • There might be compatibility issues with specific device or OS version.

 The third option is to use a website that acts as an app, also known as a Progressive Web App (PWA).

• Pros:

  • PWAs can be accessed from any device, including desktop and mobile, without having to go through an app store.

  • PWAs can be cached on the device for offline use, which can improve the user experience.

  • PWAs are generally cheaper and faster to develop than native apps.

• Cons:

  • PWAs may not have access to some of the native device features and capabilities (ex: deeplinking).

  • PWAs may not have the same level of performance as native apps.

  • PWAs may not have access to app stores, which can limit their visibility and distribution.

Our bread and butter was in cross platform React Native Apps. While it comes with many positives we had many times racked up enough technical debt to have to start the project over from a fresh base. Updates took days to finish and then required extensive testing and some of our apps could have been PWAs. 

This is somewhat of just an intro to what I think can help a newcomer. Feel free to reach out if you have any questions!