You know what you want to create, and you know the people that are crying out for your app idea.

Before you start down the path of building the next killer app, first let’s look at 3 tech concepts that you really need to understand.

1. The Cloud.

Your app idea may or may not need the cloud.  Understanding whether your app needs it or not is important.  It might need it upfront, or it could be added later if appropriate, or it might never be necessary for your particular idea.  But don’t assume that because everyone is talking about the cloud that your app must be built on it.

Put simply, the cloud is a collection of computer resources (hard disks, CPUs, memory etc) which are connected to the internet, and provide a collection of software resources (programs, components, services etc) which can be used for building and hosting digital applications.

We are currently building an app for agricultural equipment which will make a huge difference to the users of the equipment by tracking the work that the equipment is doing, but (at least for the initial version of the app) having this information in the cloud is unnecessary.  Instead, what is paramount is easy and reliable connection to the equipment, and easy use of the equipment in locations that likely don’t have internet access.  This is an example of where trying to put this app into the cloud would be a mistake.

Another app our team is currently building involves management of a 4-way relationship, co-ordinating meetings, processes, files, and user roles. This app, which will initially only be used on desktop computers, utilises cloud technologies every step of the way.  The use of the cloud for this app will reduce hosting costs (paying by operation rather than server), allow best of breed software to be used for each piece of functionality due to the availability of a range of components and languages in the cloud platform, and reduce development costs via the many components that can be employed to achieve the required functionality.  Using the cloud also allows easy scaling of the app across Australia and globally if necessary.

If using the cloud for your app is the right choice, the next decision is which cloud!  AWS, Microsoft Azure and Google Cloud are the 3 most well-known choices of cloud platforms.  These 3 are fierce competitors and have been known to offer very generous incentives for startups to pick their platform over one of the other 2.  However, there are numerous others, including local cloud providers.

It is important to choose a cloud platform that gives you the technology that you most need, at the best price, and requiring the least amount of development effort.  Australian businesses are often motivated to keep their technology hosted on Australian shores, so when you are comparing cloud platforms, ensure that you are looking at the price for Australian presence.

2. Technology Design.

The upfront technical design of your app is arguably the most important part of the creation of your app idea.

Before deciding on how the app is to be structured, a development team will need to understand the required functionality – both for the MVP (‘minimum viable product’) version of the app, as well as what you have planned for your app further down the track.  That is, there will be features that you leave out, to be added only once you have proven it to be successful, and once you have enough users to justify the investment in the additional features.

Technical design involves many different activities, depending on the idea, but will likely include:

• Choice of cloud (if appropriate).
• Database model, describing the data to be held within the app.
• Code structure (more about this in a moment).
• Component model, describing the pre-existing components to be used to deliver the app features, including performance, scalability and security.

The underlying code structure is the aspect of the app that the non-technical person will likely be the most oblivious about.  Often the person with the idea for the app knows absolutely what they want to deliver to the target end users, can articulate the requirements very well, can appreciate the design of the app screens and how a user will interact with them, and will be very happy to test an app to see if the solution is being delivered.  However, all this can be done without regard to the underlying code structure.

Yet, the code structure will have a huge impact on ease of development, ease of maintenance, and whether the new feature you forgot to mention upfront (or that only comes to your attention when you see the app in use by your intended audience) can be easily added without having to start the development all over again.

This is where a layered & modular approach to the structure of the codebase is paramount.  Building on a cloud platform somewhat pushes your developers down this path, but it is still worth checking.

Generally speaking, ensuring that your codebase is layered as follows will help ensure the long-term viability of the technology:

• Presentation layer – that is, the look and feel, the user interface.
• Application Programming Interface (‘API’) – a layer through which all requests from the presentation layer (aka ‘frontend’) must pass. See below for more about APIs.
• Logic layer.
• Database layer.

The layering of the technology helps you to remove one component, and replace with something else, if that component is no longer providing you with the performance or functionality you need.  Connections between the layers assists with the implementation of security across the whole.

Particularly within the logic layer, there will a need to componentize your app features, again to support the easy maintenance of one component, without needing to touch (and therefore re-test) another.

The API layer is important to future proof your application.  Whilst you will most likely start with a private API which is only supporting requests from the one frontend (e.g. an application used within a web browser) in future when you need to add another frontend, such as a mobile app, then the API can be re-used for this frontend also.

In addition, initially your API will be private, in that it will not be available outside the frontend that you provide to your customers.  However, in future, you might want parts of the API to be made public, allowing other apps to integrate with it.  Having structured your application to make use of an API layer will pave the way for its expansion.

3. Existing Components.

Mentioned in both the discussions above about using the cloud, and technical design, the use of existing components can have huge implications for your app.

Before deciding whether to re-use an existing component, you will need to consider:

• Functionality. Does the component really have everything you want for your app?  The marketing literature may make it sound like it does, but that doesn’t always pan out to be the case.  Unless your developer has specifically worked with the selected component, to achieve the functionality you need for your app, then you won’t know 100% for sure that it will deliver.  For your MVP version, you may need to be a little flexible.
• Interoperability. Can you easily use the component you have identified, with the technology that you are building your app in?
• Availability. Cloud components aren’t always available for all hosting regions.  That isn’t necessarily a showstopper if you don’t mind your application to be spread across regions, but that may have implications on hosting costs and legal / data sovereignty issues.
• You need to check that the savings from using a pre-existing component are not outweighed by the ongoing cost of the component.
• Maintainability & Support. Is the selected component subject to regular maintenance, so that you can be sure security vulnerabilities are patched against in a timely manner?  Similarly, is there a large group of users / developers familiar with the component to ensure that any issues that crop up during development, or occur when other technology changes, can be quickly addressed.

If your app has been well structured, utilising a particular component for the MVP version might be expedient, in the knowledge that later down the track you will remove the component and replace it with your own codebase to achieve exactly the functionality you need.

If you would like to discuss these 3 topics with regard to your app idea, don’t hesitate to contact Heather Maloney, Web & App Strategist, at Contactpoint.

by