This is the fifth post in my series how to build an app. We’ve already covered how to get your team together, shape up a product and build an app. But when that app and our team is working together as a business what does it look like?

Milestone Release. Are We Done?

When the team has been pushing for a milestone, and it comes to release, there's pressure to ramp up marketing and cut development costs.

In an app startup development costs, engineering costs in particular are one of the biggest. But the capability of the engineering operation is the thing that lets the business move forward.

The business cannot operate, make any changes to the product without engineers. So what is it that the engineering team does?

When developers write their code, as I mentioned in earlier posts they work to create an app package which can be installed on the device — the iPhone or android phone. That package can also be uploaded to the App Store or Google play store.

Code Repo: Core to Automation

In reality the process is a little bit different from that. Yes, developers can write code locally, and then push it straight to the stores.

For a release however, usually the cloud store where the code is placed — that’s our repo — is configured to automatically generate the package. It can be even configured to automatically push the package into the App Store and Google Play store.

Actually its more accurate to say its a special cloud-based app, called a Continuous Integration system (CI system)that automatically tests the code, then generates the app from the repo. But it is the repo typically that holds all the code for the build, contains the versioning details, and nowadays even holds the scripts for the CI system.

So to keep it simple think of your repo as not just a store for you apps code, but also the core of your app building process cycle.

Like a Version?

What’s even more interesting about the repo is that it’s not just a collection of all of the code that your developers have written for you. The repo is versioned. I alluded to this already in the previous section. Its these new version numbers that play a critical role in making frequent app releases.

What this versioning means is that if something breaks in your app the repo can be cranked back to a previous version. One that we know worked okay.

Repository Data lives in the Cloud

If you hear names like “GitHub” and “BitBucket”, that is your repo they’re talking about. You want to make sure you have the passwords or keys to access it & administer it.

Second we have the App Store & Google play store where packages are pushed to. And that’s in the cloud too. You need passwords to access those too.

Repository: Holds code, versions it, secures it, and drives releasing an app to the stores. Make sure you have passwords to it.

What you can take from this is the general idea that several cloud-based systems are all working together, like a well-oiled machine, to process the the code and other outputs from the people in your app development team.

That system culminates in the App Store and Google Play store, but it starts with your cloud based code repo.

So when you think about what you get if someone builds you an app, it’s the keys to that repo that you want. It’s the goose that lays the golden eggs. Or at least lays the new updated versions of your app that you’re going to want down the track.

What Happens with Updates?

Now, once your customers download a new version of your app, they can open it up and the app and connect to cloud services to access additional functionality. We discussed this briefly in the previous posts on How Apps Work.

Let’s have a really good think about app updates (made by your development team); and about updates to the items that appear in your app (like services or menu items, or clothes for sale).

A customer may access a product for sale inside of your app, and complete a transaction to order that product to be delivered.

For this to work the app will probably need to contact a store API to check that there is sufficient inventory of the product to fulfil the order, collect the customers details, and then connect the customer to a banking API provided by your e-commerce solution.

So that is in a for-instance internet store app:

* Your online storefront (a web-app)

* Product fulfilment (drop-shipping or inventory)

* Banking or e-commerce (PayPal or Stripe)

* CRM system for customers details (Zoho or Hubspot)

What if one of these four change? You release a new app version right?

But unlike the web, your apps update when a new version is released to the App Store and installed by your customers. So you need for the old and the new version to work with all of the above services.

You’ll have customers out there with the old version of the app. Maybe for quite some time. They may just choose not to update. You at least need to not crash the app, and display some useful message like “Please update”.

Cloud or In-App?

Let’s say you manage digital for a small food chain. You have maybe a dozen restaurants in the country. And let’s say you update your menu.

You as a business app product owner may access your web-app, and update your restaurant menu in response to recent changes. Then submit those changes so the new menu goes live.

So where does the menu live? Cloud, or in-app?

If its in the cloud only — say via a hybrid app web-view, then customers who don’t have internet at the time they check your app cannot see the menu.

But if its on the phone only it makes your app downloads bigger, and you need to make an app update, just to change your menu.

In reality a good design might be to have it in the cloud, with a local cache, and a default that is installed with the app. So it’s in both places.

Stock in Trade

In your business what is providing value might be physical things you’re selling as items. Or it might be posts and reviews to your pet-minding or childcare app. Whatever they are, these items are your business to care about, if your customer is to succeed and lead to your app success.

What does all this mean from the point of view of your business?

It means that you really need to think about items that are going to appear in your app. Think about those items as part of a task it’s going to be completed by your customer — like viewing a menu, or a review.

And when you think about it, decide which details of the items have to be in the code and be shipped as part of the app. That details will be shipped to every single phone that has the app installed.

Also think which other parts will need to be live in the cloud and will need to be connected to and updated when the app is actually used.

Often the best way to visualise this is with detailed User Experience flows.

Alternatively there might be best practice for the stores or back-end API’s that you are using. So you might use a dedicated review site API. Either way you’ll need to think about where the information about those items is stored.

Viewing and Updating: Two Different Customer Tasks

Think about a case of products that are ordered in an app. In this example case only the cloud that the phone app connected to knew about the details of the products. But the app needs to know how to display them once it gets from the cloud the list of products that were available.

One pattern I have implemented for an app with In-App Purchases is to have 7 items that comprise the purchasable products. These 7 items are coded into the app, along with a name, description, category, price and photo. The app knows how to display all of these things in either a detail view for the item, or in a list of all items.

Let’s imagine one item is not available.

The picture changes if the app allows updates — that is the customer could review or purchase an item. Here we need to be careful.

To check that we’re OK to display an item, our app can connect to the fulfilment centre and update the inventory amount, find that the item is out of stock, or off the menu, and update the view, so only 6 items appear in the store view.

This way you have a double-entry approach to the items in the app. The app knows about base items, and how to display them.

But that model is updated from the cloud, when the customer interacts with the app.

Summary

* Understand the role code plays in building your app.

* Apps can be updated automatically from the repo

* The repo is part of the capability of your team

* Make sure all code goes in the repo every day

* especially if there's any remote teams

* Design and plan which data

* are coded into the app, and

* which are dynamically fetched from cloud Apis.

* some data can be both

* Complex use-cases like user roles need design & testing

* Map out complexity and make it part of acceptance tests

* Complex and risky items should be done as early as possible

* Test no-network and other edge cases

This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit totallyathing.substack.com/subscribe