,

Mobile App Startups: Tech Stack

Thryv gets many questions about this, especially from startups who are still looking for technical co-founders. Where should you start? What technologies are easiest to recruit for, and what are their tradeoffs? Well, this article should give you a good starting point.

Server

Your server is where you store all the data that needs to be displayed. Almost every startup will need a server.

The in-vogue thing to do at this point, especially if you’ll be building both a website and an app, is to build a JSON API that sits on your server. JSON is a common format for communicating between different types of applications, and an API is a set of capabilities that an outside application can utilize.

With that in mind, the question is often this: what’s the best way to build a JSON API? There are several options.

Ruby on Rails

Ruby on Rails, or simply ‘Rails,’ is a very common and reliable technology. Rails has the advantage of being quick to setup. It’s generally pretty easy to add features to a Rails API, and there are tons of developers who know how to use Rails. The disadvantages generally come as you get larger; Rails does many things for you, so doing more specific things can start being more trouble than it’s worth. That said, the speed you gain at the beginning can often outweigh the costs down the line, and many prominent companies use Rails at scale.

Node.js

Node can be a very advantageous technology to use, especially when the developers who are helping you work primarily on the ‘frontend’ of your website/app. Node uses javascript, which is a vital frontend web technology, but it uses it on the ‘backend,’ meaning that developers who generally work on one can easily get up to speed on the other.

Python (Django or Flask)

Python is a beloved programming language in many circles. Building websites and APIs in Python is enjoyable for many developers because it is so easy to work with. It also has some advantages in raw speed without sacrificing much in the way of development velocity. However, it doesn’t have quite the same developer pool as javascript, and it can be a bit more work than Rails to get something up quickly.

Database

The most common database format at this point is probably PostgreSQL. Postgres, as it’s colloquially called, is robust and professional, and belongs to a family called ‘relational’ databases. It can be a little tricky to setup, but it’s the workhorse of many modern server applications.

For specific types of problems, a non-relational database may be preferable. In those cases, MongoDB is probably the most popular choice.

App

When building an app, there are tons of choices. In Thryv’s opinion, though, there are only three good ones.

Going Native

This means programming in Objective-C or Swift on iOS, or Java or Kotlin on Android. Going native gives you the highest potential for a quality app. iOS and Android phones are built and optimized to run native apps well, so they’re always a safe bet, especially when you’re targeting only one platform to start. However, it can be difficult for small teams to rapidly iterate on two separate platforms, in which case it may be wise to consider a cross platform approach.

React Native

React Native is the latest in mobile development from Facebook. It allows you to quickly build native looking apps on both iOS and Android at the same time. Moreover, since it’s in javascript, you have a large pool of developers who can work on your app. There are, however, downsides. React Native does not match native performance, and there are certainly things that are difficult to do with it. Additionally, since it’s a part of the javascript ecosystem, things move very quickly, which means they break often.

React Native, in our opinion, is a classic high risk/high reward technology.

Flutter

Flutter is a new cross platform framework from Google. There are some large technical differences between Flutter and React Native, but they break down to two things: speed and styling. Flutter apps, due to Flutter’s architecture, will run smoother and probably be easier to build than React Native. That said, Flutter limits you stylistically: if you like Google’s Material Design then it will be a fast, easy to use option for you, but if you want to deviate from Material Design, you may want to consider React Native instead.

Web

There are so many options for building a website today. Most startups generally need at least a landing page, but if that is, in fact, all they need, there are a myriad of solutions that they can use: WordPress, Wix, Instapage, Squarespace… and many, many others. If you need to build a dynamic website, there are a few technologies people generally use. All the technologies mentioned in the Server section apply here, but it can be difficult to make them work with an API as we described. As a result, we recommend React for your dynamic website needs. React is the foundation on which React Native is built, so if you’re building your app in React Native, you maybe able to share code between them. Otherwise, you may also consider a framework called Angular. Both allow you to build beautiful, modern websites with the highest level of flexibility.

Infrastructure

Where should you host your web properties? There are two places we generally use (and, in fact, one is built on top of the other).

Most startups eventually move to Amazon Web Services (or AWS for short), and any tech person you talk to will have heard of it. AWS offers a lot of flexibility, and is excellent at helping you keep costs down. Unfortunately, it can be hard to setup, and there are so many knobs and buttons to tinker with that it can be quite intimidating.

For this reason, we often recommend that startups start out using Heroku, a Platform as a Service (PaaS) offering built on top of AWS which takes care of most of the configuration for you. Your developers will be able to easily deploy your code with few tradeoffs when it comes to performance and cost.

Need help?

Do you need help deciding what kind of tech stack you should go with? Then contact us! We’ll be delighted to chat with you about what you need, and help you get it done.

Requesting new features for your app

Asking for new or different features in your app can be easier in some cases more than others. If you took our advice in Fixed Price vs. Time and Materials this just comes down to normal courtesy, politeness, and thinking things through. If you didn’t take our advice and signed a SoW with a strict, fixed scope, then this can be a huge issue which needs to be navigated carefully. Regardless, the process starts out the same, and it starts out with you.

Step one: Customer discovery

Do you really need this change? Have you validated it with your customers? How important is it to make this change? Making changes in the middle of a project can be dangerous, so doing at least some light research into how much you need to make the change is critical.

Step two: Business discovery

How hard is it to make this change? How much time will it take? How much will it cost? Businesses can often be surprised by how much work and money it takes to make what may seem to them to be a relatively simple change. Make sure you discuss such things with your development provider to determine what kind of complexity you’re dealing with, as this often affects whether you want to commit to it.

Step three: Timing the work

You’ve decided that you definitely need to make this change, and you’re comfortable with the difficulty level. Now the question is, when do you do it? Sometimes changes make more sense to do later, and occasionally even after launch of the product. It may also be easier to make the change after some other work is completed, which could save you time and money in the long run. As before, communicate with your development provider to fit the change into your development schedule.

Step four: Contract considerations (optional)

If you have a fixed price project, you’ll want to amend your SOW or, potentially, get a new SOW altogether if the change is large enough. This is one of the downsides to fixed price projects, since a) lawyers are expensive, and you may need one to review the new scope, and b) if the change needs to happen immediately, this process can really slow down development.

Every project will involve changes in scope and features, so keep this in mind when you’re considering signing a contract with a fixed scope, as it won’t truly reflect the reality of development. Regardless, if you follow these steps, requesting new features and changes to existing features will go much more smoothly for everyone involved.

,

Google Play Indie Success Story Interview

In AppMaster’s podcast Google Play Indie Success Story with Elliot Schrock, host and marketing consultant Steve P. Young digs in to find out how some app developers are getting more success using Google Android revenue, and the hard lessons learned about choosing an icon for your app.

Founder and Mobile Architect Elliot Schrock is interviewed this week on the Appmaster.co podcast about his approach to market research, and user analytics… but on the way, he reveals his philosophy of taking care of users, applying the Golden Rule to app design, and his love of open source code.

And there’s a plug for one of the go-to apps on his phone you probably haven’t heard of. Hint: it makes you a better, more successful person.

Don’t miss his insights on:

  • App store SEO
  • User behavior
  • Selling apps
  • Prototyping and minimum viable products
  • Competitive research
  • Efficient coding

It’s just 36 minutes (which flies by), including the intro and outro.