Working through a series by Lesser Dog Tutorials on how to make a LucasArts style point and click adventure in Blueprints, I have instead of using Blueprints I have been translating everything into C++, and it’s so much fun.

Totally a Thing is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Feels like doing a crossword and a half-dozen other fun puzzles besides. Today’s solution found was uncovering how Unreal dispatches Interfaces when they’re implemented in C++, and overridden in a Blueprint, but called by C++.

Turns out they have this — as far as I can tell, undocumented — feature where you call a static method on the interface implementing class that is generated by Unreal’s Header Tool (UHT) so:

HotSpot::Execute_LookAt(CurrentHotSpot)

That gets the job done, to have my little man read the poster response from the blue print via the Blueprint visually coded look at event.

Blueprints are amazing, and have their place, but complex logic in blueprints gets into a snarl of spaghetti so quickly.

Code is here:

* GitHub - Unreal Adventure Game

Don’t worry - I will get back to dishing on AI shills at some point in the near future.

I have been struggling to write this article, and figure out what to do with this cartoon / diagram I made about the alleged use of stolen books by AI companies for weeks now. The sheer scale and brazen bullying greed of these guys just astonishes me.

I believe startups and technology have the ability for great good. But it’s being used to enrich the most powerful at the expense of the little guy.

This diagram sums it up in one image. See my video for an explainer.

References

Articles I reference in the video:

* The Atlantic, The Unbelievable Scale of AI’s Pirated-Books Problem

* by Alex Reisner

* Authors outraged to discover Meta used their pirated work to train its AI systems

* by Nicola Heath

The analysis of how AI companies refuse to pay for data when they spend big on engineers and data centre costs was inspired by Ed Newton-Rex’s Ted Talk:

What can We Do?

The most important thing is we are not powerless. The number of daily users of the products these guys have is an instant stab of pain for them every time it dips.

* ChatGPT - you don’t need it, delete your account

* Facebook / Instagram - migrate to Bluesky, and Substack

Calling out everyone for using toxic AI products and just politely pointing out the harm — we could lose our book industry — is worth it.

See my article from last week about pushing for regulation on AI companies.

I’m loving the new campaign from Australian Society of Authors and other groups trying to throw light on these problems.

Vote for fair AI

This year is an election in Australia, and there’s a chance to push for policies that support books, readership and our local bookshops.

Don’t let them die. You’ll miss them when they are gone.

Thanks for listening.

Totally a Thing is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Engineers love to deal in absolutes. We are trained for it, when we study mathematics, electronics and disciplines like finite element analysis or software development at University. It seems to us like everything in the world can be reduced to ones-and-zeroes, true and false.

Business is not like that. You have to prioritise. It is a constant balancing act. Every time you choose to execute on an initiative, there is an opportunity cost. The time you spent on those cool infrastructure as code scripts is time you did not spend delivering the incremental login feature that your customers needed.

So how do you as a technical leader — say a CTO — explain or understand this balancing act, and make sure your startup or scale up survives? You can say:

Never let the perfect be the enemy of the good enough.

Or:

The practical solution that shipped is better than the ideal solution that didn’t.

The next level up the mastery tree is the deeper knowledge that these ideas are not about compromising. Those trite aphorisms leave engineers thinking they are being asked to lower quality to get a delivery out.

Great technical leadership understands that Worse is Better actually means a “worse” solution is often a superior option. That’s what I hope to show in this article. The “compromising on quality” argument is a complete red-herring because quality is orthogonal to this issue of what a “worse” solution really means.

Huh? Its not about quality? Well what does “worse” mean then?

Can’t we just leave our engineers to do the “right thing” when it comes to building the tech that our startup business needs?

In a business, especially a startup, if the time you are spending is gone in satisfying some engineering driven pursuit instead of a customer need you are soon dead in the water. Money burns away. It goes in no time flat when you’re paying engineers. At your startup do resource intensive technical tasks win out over business realities on a daily basis? There’s a risk that it becomes a culture and a glide path to failure.

Do resource intensive technical tasks in your startup win out over business realities on a daily basis?

Can a startup be fun for the makers? Sure. There’s exciting moments. Is it a chance to indulge technical ambitions? There’s chances for that. But I have run several startup businesses, and when you have staff that you have to pay it gets real. As a tech founder you write code during the week, and on the weekend you have to do payroll. People rely on their pay to make rent or mortgage payments, and to keep their kids in school.

For those in technical leadership right now who may be scoffing and thinking “well, if you’re out of money then all bets are off — this has nothing to do with me” have another look at what technical decisions are costing. As a technical leader what could you do to reduce waste?

As a startup your cash-burn rate, and ability to make payroll is what gives you a runway. That runway is a hard stop. If you are financially headed straight for the tarmac at a hundred-miles an hour it doesn’t help if your test code-coverage is 82%. Cash in the bank is hard number that you cannot argue with no matter how much you love functional programming or clean code.

Cash in the bank is hard number that you cannot argue with no matter how much you love functional programming or clean code.

So as technical leader how do you explain to your engineers this fact? The fact that when the bottom-of-the-barrel is reached they don’t get paid and the company has to shut its doors?

Unless they’ve been through the experience of a startup or of a too-big-to-fail company failure — like RIM or the one I experienced at Nokia — they struggle to wrap their brain around that idea. Surely if I keep showing up at work, the tables and chairs are here, the coffee machine still works, I still get paid. Right?

Strawmen of Worse is Better

Enter “Worse is Better”. Its a critical plank of Senior Engineering skill that you need to master in order to lead teams in a startup or innovative business. It can help explain to engineers how to get on board with balancing competing priorities.

But it does not mean compromising your ethical principles. It does not mean accepting inferior quality. Folks who do not have a growth mindset want to avoid change, and may make these straw men arguments.

Worse is better means: rejection of complexity, even when complexity is the more theoretically correct approach.

Worse is better means: rejection of complexity, even when complexity is the more theoretically correct approach.

But the moment my fellow engineers are asked to choose simplicity instead of some high-priest holy-notion of engineering they react as though it’s the end of the world.

Some are even ready to slap their resignation on the table and walk out. Here’s some ideas that engineers I’ve met are ready to die for:

* clean code

* secure code

* infrastructure as code

* open source

* test coverage

* functional programming

* css in code

* css outside of code

And when I say “ready to die for” I mean it. They’ll shout and threaten to resign when 80% of the code base is open-source/test-covered/functional/clean/inside/outside and they’re asked to make a change to their code base making it only 70% of the previous figure.

“It’s a slippery slope! I’ll resign!!” they say. Usually because whatever the issue is relates to some past war they fought, and they’re still nursing that pain from those days. When an idea that we hold dear is challenged and it’s shown there are cheaper, simpler ways that work just as well for customers it’s tough to deal with.

These principles above like clean code, are important, but they are not absolutes. They are principles that inform decisions. We don’t get to throw the baby out with the bathwater. We don’t get to storm off because a pet engineering hobby-horse is not pandered to. The hubris of engineers can drive a company into bankruptcy and we need to understand the cost of standing on gold-plated principles.

Survival Means Living to Make a Difference

There is a million ways to misinterpret and argue against “worse is better”. Most of the arguments against it that proliferate on the web mischaracterise what its framers intended. For the record the article by Jeff Attwood in his blog “Coding Horror” shows what I mean by the framers. Attwood along with Joel Spolsky founded Stack Overflow.

The thing is that even if their straw-men arguments were true, taking a general approach of balancing engineering high-priesthood demands with what customers will pay for is the only thing that will make your startup survive. Embracing worse is better doesn’t mean throwing out engineering principles, it means feeding them into decision making.

But by characterising it as a choice about quality, by creating a straw-man they can take their righteous indignation all the way to the tech graveyard. They get to die on their hill, and then once the business is shuttered they can go on to some new company. Attwood points to this quote: worse-is-better, even in its straw-man form, has better survivalcharacteristics than the-right-thing and it is spot on.

worse-is-better, even in its strawman form, has better survival characteristics than the-right-thing

See the post by Jeff Attwood blog post quoted above. I hope I don’t need to point out how good survival is.

Survival: that is the one where you don’t die. You make payroll and don’t have to close the company down, and tell everyone you employed that they are out of a job.

A Concrete but Ethereal Example

I’ve found through experience that once you try to get engineers to even question their cherished holy-notions long enough to notice that they’re driving the company into bankruptcy, you start an intellectual fight that is likely to lose people, without getting engineers to realise that even if they are technically right they’re in practical terms painfully wrong.

So how do you get the message across? Let’s try technical examples.

Here is where engineers can start reading and see how many examples there are in technology of the “glue two phones together” approach succeeding.

Another example apart from the ones Attwood quotes, is Ethernet. Back in the day, LAN parties happened with blue cables you stretched from front to back in your share house. Before those blue cables — Ethernet — became so popular and empowering there was a thing called Token Ring.

Never heard of it? Its a bit like folks today have not heard of Blackberry. Because it died. Engineers could not believe that a phone without buttons was better.

Token Ring was technically better, as well. But Ethernet, which tolerates dropped frames, was “worse” and actually better.

A local area network, one connected by a cheap network hub, echoes out every frame that is dropped onto it to every network card that is plugged into it. That’s the problem that the CSMA/CD algorithm solves: the collisions that you get when you drop a lot of frames onto the shared-medium (the wires).

The algorithm CSMA/CD or Carrier-sense multiple access with collision detection handles the collisions. Basically it works like this: each network card can figure out from its segment that it collided, so it waits a random amount of time and tries again. The amount of time gets exponentially longer. That’s it in a nutshell.

But isn’t “wait a bit” kind of a crappy solution? Lost data? Dropped frames? The folks who built Token Ring probably thought so. By using shielded cables and more high-end equipment, each network point could wait for a “token” (a special pattern of bits) to arrive, and once they possessed the token, then they could transmit, knowing there’d be no collision. A purer, more perfect solution with no collisions!

But which one won?

Ethernet. In fact the same algorithm powers 802.11x — the wireless internet that we use for everything we do today.

There are countless examples of this kind of thing in engineering. But the ideas of purity, cleanliness and so on blind us to them.

Great, so “Worse is Better” — what now?

So you are a technical leader, maybe you write code and maybe you don’t, but you want to have your company survive. The key lesson is to listen for when an engineer driven work requirement is justified as a choice between two technical options, instead of a choice based on customer needs. Remember customers? Those are the folks who pay you.

Listen for when an engineer driven work requirement is justified on technical grounds instead of customer utility

An engineer driven requirement: this is one where folks are demanding something must be done because of an engineering reason, and there’s no projected customer benefit.

“We have to have 100% code coverage! Otherwise quality suffers!”. But in fact with very high levels of coverage so much test code, dependency injection and abstraction takes over the code base, that it may be a bloated, unreadable behemoth where feature requests take months to complete, and customers still experience bugs.

Is it because of security? Ok, what is the threat analysis? What is the attack vector? What is at stake? General principles are fine, but what are we actually gaining by encrypting the token for login to the loyalty database when its already in a secure app sandbox?

Is it because of clean code? Or functional programming? Or developer experience? Fine — show me. What is the tangible benefit today of refactoring our code base to use the interactor pattern, and have five-million tiny useless classes that need to be touched to implement a tiny change in functionality?

Other Tools in your Worse is Better Toolbelt

YAGNI — you ain’t gonna need it.

DTSTTCPW — do the simplest thing that could possibly work

These are other ways to avoid over-complicated solutions. But one of my absolute favourites is one attributed to Knuth.

Readability — write programs computing machines can perform quickly and human beings can understand clearly

Did you ever have someone triumphantly produce an unreadable, opaque screed of code and then says its a brilliant solution to a made-up problem?

I have to wonder if the problem really is that they want to make themselves indispensable.

Summary

Watch for requirements entering your backlog of engineering work that have no projected customer benefit. They can be justified, they can be needed, but they should be “salami sliced” into other work, and made to show tangible benefits.

Idealism — especially engineering perfectionism — is not a reason to spend resources in a startup.

Why?

In my previous talks on how to build an app I’ve discussed source control briefly. Github, owned by Microsoft, is probably the most popular cloud service for source control. OK, but how does that help me?

If your app based startup is going great, then your team will be implementing product features and code for that will be going into your source control system many times a day.

But what about if something is going wrong? How can you check up on that? Do you wait for your engineering team to tell you? I’ve talked about the problems a startup can have, especially in that first app building phase, and especially if there’s poor engagement between the founders and the team:

* My developer left me / Get the Code

* How Does my App Work as a Business / Code Repo: Core to Automation

* How to Build an App / Backlog, Doing Done 

I’ve done to death the “Why” of being a founder who understands how to find the code. In this session I am going to look at the “What” and then the “How”.

If my business was a sandwich bar or a t-shirt printer I could go down to the kitchen or down to the factory floor.

But if source control is a mystery you need to take some time out to decode that, because it's the one thing that keeps your business running. 

What

In the next 10 minutes I’m going to show you what source control might look like, and give you an idea of how it works. Finally I’ll wrap up with a short list of next steps to give you as an appreneur to get ongoing insight into your project so you can work with your team collaboratively.

As a bonus, if you’re an engineer you’ll see the way I work with Git on the command line and you will likely discover something new. 

For non-tech Appreneurs trying to get a handle on source control can be tricky. 

Think of the difference between a document on your local computer or phone, like say a PDF you downloaded; and an email. You know where that PDF is, it's in your Downloads folder. Now compare that with your emails that you read on your phone or computer. Where are those exactly?

A code repository is a bit more like that. In the cloud, synced locally. Kind of.

But another big difference, and it's what I’m focussing on in this session, is a code repository for your project is built in small steps. And source control is designed with that in mind.

Demo of Git

First we’re going to look at a couple of projects from the Engineer perspective and you’re going to see how I would explore code, download it, make changes to it and then update those changes to our cloud - to the Github repository.

Let’s look at a project I started some years ago. This is an app written in C++ that runs on Mac, Windows and Linux. 

It’s stored in a source control repository, and then pulled down locally. That project is private, and only accessible if logged on and allowed access.

Another project of mine is open source and is publicly available for view.

# Pull down the project from github

Signed Commits

* https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits

As an engineer I can sign my commits so that you know they are done by me. This is an added layer of security and it's worth doing to ensure that code is being modified by who you think it is.

What if you had a disgruntled employee – call them Joe – who left and decided to put a back door in your code? As long as Joe doesn’t have access to the local GPG keys that your existing engineers have on their computers you can see that all any changes are by legitimate folks with access to the code.

It’s possible to have Github reject unsigned changes but that’s not something I have seen on any repo, and I would not recommend it.

The Git Log

Git never forgets. At least you have to do a lot of work to make it forget, which for all practical purposes is the same. In this article I go through what is required to make Git forget and its a nuclear option - generally you never do this.

* Make Git Forget

The How

* Make sure you have your own account 

* on Github, Bitbucket or whatever system is being used for source control.

* NOT the user name and password of someone else's account or of a jointly used generic account.

* As founder and one of the owners of the company get admin rights to the repo

* You will use this access very wisely, very carefully

* It's generally not easy to inadvertently change anything on Github.

* If you need to appoint someone new to work on the repository you need to have the power to do that, if key personnel leave.

* This is really important: if you get some other account and have the password, it can easily be deleted by that other person who has access to it, or the admin rights revoked. Imagine - some people have left the company and you go to use the username and password to get your project back on the road again, only to find it was owned by someone else. And now it's gone.

* Regularly, ideally after a release or a sprint cycle.

* Log on to github and navigate to the list of commits. If your team is using PR’s then check those too.

* Look for the following:

* Commit messages - should be descriptive

* Commits / PR’s should be small

* Names of files that are edited

* Signed commits

* For extra credit:

* Documentation

* Function names

* Signs of 3rd party or cut-n-pasted code

* What dependencies are introduced?

* The goal is to better understand the pressures and work load of your engineering team. If you are an engineer yourself then reviewing the code others are writing is important.

* You don’t need to introduce PR’s and slow down development to have code review, just read code together

* Ask:

* From the commit messages and files touched is it clear what the change is doing? Is this change improving the product and moving forward the goals of the team and the product?

* Are there signs of technical debt being introduced - for example is code being commented out, instead of deleted? Is the word “temporary fix” and “hack” being over-used to apologise for code. You can ask the engineers to explain what they meant in a non-blaming way.

* Are there signs of churn or spats between developers being fought out in the code base - changes done and then undone.

Totally a Thing is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Google’s AI Preview is driving me insane!

I just want web pages!

Instead when I type a search, what happens? It thinks for a moment or two, then produces this bargain basement guess, summarised from whatever blended together soup of opinions it found on the web.

I don’t want that! I never asked for that!!

When I’m researching for my writing I need the actual facts. Many topics are highly dependent on the source.

Google, why do you grind off the serial numbers and sell me this crappy, high-school student answer?

Who ever asked for this?

Searching for a Fix

Well, I finally got annoyed enough to go looking for a fix. 

Seems like plenty of other folks are like me. Tom’s Hardware has an article about a Chrome Plugin called Bye, Bye Google AI. It also lists one called Hide Google AI Overview. 

That second one sounds more technically accurate, as far as the name goes - but I like Bye Bye Google AI better. 

But I’m not going to install either of them, because although I use Chrome for development - that is testing my code - I use Safari on my Mac when I’m researching. 

I use Safari a Lot

Safari blocks a lot of trackers and privacy invading cookies for me without having to install and keep up to date a bunch of plugins that might have security issues of their own.

I enjoy making web developers stop being lazy and actually build their products properly so that they work with Safari as well as Chrome. Another great benefit of using Safari.

Plus it’s also the same browser I have on my iPhone, and I like the synchronization.

So here’s how I fixed my Google AI Preview problem. I just pressed command-comma to open the settings panel, and then, changed the search engine to Duck-Duck-Go.

So I’m being tongue in cheek here. I fixed the problem by getting rid of Google.

But seriously - isn’t it time?

Totally a Thing is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

There’s some really great apps in the App Store and Google play store!

When I was consulting, building apps for people in business, they’d show me Augmented Reality apps like Pokemon Go, or the Uber app with its live location tracking and ask “Can I get an app like that for my business?”

Welcome to the second post in my series on team dynamics. Last time I talked about communication and how it’s the best bang for your buck when it comes to solving issues that crop up in your app based start up. 

I talked about how teams at any given time have a set level of competency which is not quickly changed. And I went on to cover how trying to motivate your team with pep talks, or worse brow beating doesn’t get to the root of actual problems.

In the previous lecture, I presented the triangle model showing that motivation and competence have a role to play in the throughput of the team, but it’s communication that is the base of that triangle, and it often winds up being the limiting factor.

So motivation and competence are important, when managed at the right time. It's just that when an issue arises is usually the wrong time.

An Anti-Pattern in Team Dynamics

In this session, I want to look at an anti-pattern. This is a tech team dynamics misstep that  nearly always will derail high-performance teams on a project.

When someone new has leadership responsibilities in an app start up team at the start they wind up flying by the seat of their pants. I don’t want to discount the importance of being authentic or of going with the gut.

But it’s good to train those instincts. Get ahead of the game by learning effective strategies for communication so that when the pressure is on, we find ourselves responding in a solution focused way.

The Flaming Limousine

Imagine you are riding down the highway in the back-seat of a luxury limousine. 

But it seems out of control, it’s slamming into the guard rails and flames are pouring out from under the hood. So you call out:

“Hey, it’s on fire!”

But instead of listening to what you’re saying, the driver says:“What’s your problem! You’re in a luxury limousine!”

You say “Watch out, we’re slamming into the guard rails!”

But the driver says: “Stop complaining and have another drink from the mini bar.”

As a team member, you know your team has become a flaming limousine when your accurate observations about actionable issues are written off by referring to company perks, or workplace culture. 

When is it a Flaming Limousine?

Remember the celebration we just had for the last milestone - I can’t believe you’re complaining already.

We are a huge supporter of that idea here at Company X - what’s your problem? 

In a flaming limousine team serious concerns are - by implication - dismissed as being self-serving complaints. 

Signals from the team about important information are missed, and the project is impacted by risks that could have been avoided.

For a new app startup, it's difficult to manage input from the team when it challenges traditional lines of communication. It's even more difficult for folks new to leadership, or at least new to app startup decision making, when problems are pointed out at a time the team is not ready or not resourced to deal with them.

What to do Instead?

So how do you manage this input effectively?

Do you treat the information as a brush fire that you need to hose down, or as a challenge to team structures that need to be realigned?

Those are flaming limousine responses.

Do you have more beer on Friday night, and buy your team a foosball table or basketball hoop?

Sure it's nice to do those things, but it’s not addressing the burning issue the team member is raising. Do those things to celebrate real fixes.

The most important skills to avoid becoming a flaming limousine are active listening, note taking, team dynamics and prioritisation.

Active Listening

First employ active listening to make sure you reflect back to the team members with the information what you are hearing. Always do this, even if you feel it risks derailing the current team ritual, meeting or cadence.

When listening, make sure that everyone in the team who wants to speak is heard without anyone interrupting. That includes you.

However they must be succinct. And once someone has spoken, the chance to speak moves on. When employing active listening to reflect back what you have heard, as a leader, summarise fairly, get in their shoes, and try to understand what they are saying the stakes are. Why is it important? What is the priority?

Note-taking

All this can be done quickly. It does not need to derail the current meeting. Use your notetaking to ensure you capture what you understand. 

If this current meeting or ritual is the correct place for the issue to be resolved, then do that right away. Otherwise, you can ask the person who bought the issue up to create a meeting at the earliest opportunity that matches the priority. The person should also check in with the participants in a written form, prior to the new meeting with a 1-pager on the background.

Team Dynamics

Sometimes drawing up the 1-pager helps resolve the issue before the meeting takes place. In fact a useful approach here is to have the person calendarise the meeting, but if the matter can be resolved before then, the meeting can be called off. 

However the meeting date serves as a forcing factor to ensure it's dealt with - and your team will build trust that you’re actioning the issue.

If the team members respect each other’s contribution that approach should avoid the issue derailing the current meeting. In a later session I plan to cover respecting team members' knowledge.

But if it's necessary - maybe canceling the current meeting and dealing with the issue straight away is the right thing to do.

Prioritisation 

A very useful document to deal with the kinds of issues I’m talking about here is RAIDS - the risks, assumptions, issues and dependencies log. This is usually a wiki page for the project, where emerging problems can be tracked, and all the team members can see what resolutions were. Each line item should show a short normative name, description, date, who it was raised by, and what the final resolution was. 

If a line item in the RAIDS document is too complex to be properly described, create a Solutions Options document, or a High Level Design document, and link to it from the RAIDS line item.

Whatever is actually done with issues raised by the team members, the vital first step is listening in the appropriate way, and capturing enough information to determine the priority. Then you can take steps to make the right forum, and right time to handle it correctly. 

Sometimes listening and recording is enough. Especially when you have the trust of the team.

TLDR

But whatever you do, avoid falling into the trap of thinking team members' concerns are just a complaint to be dismissed. 

Company culture or office perks are not a replacement for ethical behaviour, and sound team dynamics.

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

Imagine the throughput of your team is defined by this triangle - in this model the sides remain in constant proportion.

Once you have hired someone competence is fixed. Lets assume you have a team and you want to make the best of them.

Motivation - the mistake some leaders make is thinking what they have to do to get their team producing output is to crank up the motivation. Introduce crunch time, do pep talks.

But in my experience its the communication which winds up being the restricting factor MOST often. If you improve communication then you will begin to reach the potential of the motivated competent team.

The job of a leader is to:

* filter outside impacts that can derail the team,

* simplify the view they have of the overall product and

* provide a compass set on true north.

* Provide a consistent drum-beat that gives the project a cadence.

Technical projects have failures most often from a lack of shared understanding. The best bang for your buck as a project lead, for improving team performance, is time spent on communication.

If there is an issue, seek information, understand why things went wrong, and open up communication lines with your team. Hiring 10 x engineers does not work. Pep-talks and brow-beating doesn’t get to the root of the problem.

In this model, the throughput — the performance — of the team is limited by the smallest of the three sides, so communication more often than not is the low hanging fruit. Try that first because a fix to a hiring problem could be a long way off. Issues with motivation — if real — aren’t going to get fixed with fire-and-brimstone speeches.

Ask open ended questions, and guide your team to the solutions & work with them so you can discover the facts, and the actions that led to the issue.

Look at onboarding procedures, how work is managed and how UX specifications are updated over time. Hunt down the miscommunication bug-bears and work with the team to slay them.

Improving communication will provide a team with good motivation and competent members with the best chance of performing well.

In this episode the rubber hits the road and our app is being put to the test. Will it succeed or fail? To get to this point an appreneur — either an app-based startup, or an existing business creating an app — should already have things sorted, as laid out in previous episodes:

* Business plan with fixed and growing costs, unique value and revenue

* Product tested by selling value via a duct-taped together MVP

* A basic understanding of what apps are, the risks and how to avoid them

Money is one measure of success. Think about what success means for you. I’ll assume at least you want folks using the app, right?

Let’s jump right in.

Start with your customers. What do they want to do?

Working with your UX designer, and your product owner, answer this question: what are my customers trying to achieve?

How your app succeeds starts with Jobs to be Done:

Jay, an office worker, wants to eat healthier & searches for meal plans

Here wants to eat healthier might be unrelated to your business about recipe sharing with online ordering, but let’s say your app can help Jay search for meal plans and has filtering for healthy options.

The search is a task in your app, that helps toward a goal.

I saw founders struggling with apps because they have a lot of functionality that they want to put in — especially if they have a website full of stuff — once they start building an app the first thing they want to do is cram all of that in. Shoehorn their website into the mobile user experience. Successful apps are the ones that work for what customers want to do.

Successful apps are the ones that work for what customers want to do.

They don’t want AI, they don’t want 256bit encryption, they don’t want a laundry list of obscure features. They want easy meals they can eat. They want to find a nanny they can trust.

The Jobs to be Done framework and also Persona creation will help a Product Owner home in on this.

Monetisation in Apps

In the initial App Store gold rush in 2010 onward, we got what I’m going to call “Classic Apps”, like Instagram & the app then known as Twitter. Instagram happened because we all have a camera in our pocket now. Twitter was invented because we were OK with texting on our phone. They’re known as phone apps, but have web presences as well.

Note: when I say “inside the app” or “on the phone” remember apps these days are part of the fabric of the internet. I mean the whole app platform.

We are also familiar with mobile games like Candy Crush, or apps such as Duolingo that teaches you languages. Here the value that lures the folks to the platform is some in-app offering — like learning a language, or playing a game.

Often these kinds of apps have known, logged in users who see advertisements that the platform shows to them. These users are valuable to advertisers.

Free to Play Apps

What’s common to these apps is they make money because the actual app itself has some value that it delivers to its users — learn a language, share a photo.

Free apps generate revenue from the app directly. They survive by acquiring a wide funnel of incoming users, retaining and monetising them.

The critical strategy for this kind of free app — and I include freemium here — is to have a wide funnel of incoming users, who go through the classic cycle of acquisition, retention and monetisation.

It’s very common to have the customers pay for that value by ingesting advertisements. Other possibilities are subscriptions with a free month, which have become hugely popular, and in-app economies, like Trello Gold or Gems.

Premium Apps

In some classic apps customers can upgrade from the free to the premium version by completing an in-app purchase, or by buying the premium app in the App Store.

The reality is that app pricing is a race to the bottom, with everyone searching for “free” solutions for almost every niche. That free-to-play funnel keeps gobbling up all the customers and making it hard to break in with a premium app.

It is possible with an excellent app, to win via App Store listings and positive reviews. Procreate — an app for digital art with the Apple Pencil — is a good example of a premium app that is successful.

Monetisation outside of Apps

Apps also can make money indirectly, by speeding up, enabling and making more ubiquitous the every day actions involved in business. Apps like Uber, AirBnb and Airtasker enable us to pay for services like transport or a home handyman. We think of AirBnb as an app but these are business transactions using an app as a channel.

The local government, the tax office, post office and big corporations like Facebook and Google often have apps to help folks engage with various parts of the business.

Smaller businesses often use web apps to manage restaurant menus, online stores and appointment bookings. What all these apps have in common, where the folks interact directly or indirectly with the business, is that tasks are at the core of success for these apps.

Success flows if Tasks are Completed

Let’s imagine your business has a special promotion for summer or winter or some new seasonal holiday, and you send out promo codes to your customers to take advantage of the offer. A task would be for a customer to take that code, shop on your app, and apply the code to their account.

The most important thing with tasks is that even if a customer can get almost all the way through the task, if they can’t complete it then you don’t make that sale. It might not be a literal sale, but it’s some interaction where the customer receives value, and engages with your business.

During the app development process, each iteration, the product owner is checking tasks can be completed inside of the app. If a feature is built by the engineers, that is verified by trying it out in the app.

Rule Number One for App Monetisation

So here is the first rule for making money from your app: identify the top 3 tasks that you want customers to engage with through your app; then absolutely nail the user experience for those tasks. Ensure that throughout the life of the app those tasks are constantly tested end to end to make sure they work.

Payments inside your app require ensuring trust. Customers will be looking for the hallmarks that let them know their money is safe, and what they are paying for will be received.

To ensure that tasks are working, conduct acceptance testing prior to your release where each step of the end to end task is tested on a phone.

In the case of in-app purchases (IAP’S) the Apple App Store has its own APIs for these which can make these transactions very secure. Likewise Google has its own commerce APIs. Both of these require custom native programming in the app to work.

Apple in particular is a stickler for getting these right. If a customer buys something in your app which they get to keep — for example upgrading to a premium version in the app, then you must provide for restoring that purchase if the app is reinstalled.

Both Google & Apple take a proportion of proceeds, but in return will handle a lot of customer issues such as chargebacks and paying in different currencies. Otherwise you can use a payments provider API.

Retention Rules

The second rule for making money with your app is stickiness. You need to keep your customers in your app. You need to think from their point of view.

On your app website you should have carefully crafted open in app linkage so that customers can continue their transactions from the website into the app. Folks who have downloaded your app should feel like they are special, and that they have special insight, or privileged access to your business. If your business has Street premises, then there should be prominent signage asking folks who have the app installed to use it to get special discounts, jump queues or gain other benefits.

Marketing promotions that utilise email should open automatically in the app if possible and include special promotional incentives to get app owners users to click through.

Careful use of mobile notifications is a great way to have users return to the app. You need to make sure that the notifications have been asked for specifically by the user, for example “notify me when an out of stock item comes back into stock”. When a user gets a notification it should be seamless for them to click through into the app and continue their task as cued by the message.

Growth can mean more Service Staff located where Customers Are

Boots on the ground is when people have to be in the same location as the customer to assist them in getting the value from the business.

Uber has to employ people to on-board new drivers, handle online complaints, and deal with logistical issues. Those people have to at least be in the same time zone and very often in the same geographical location. For AirBnb it’s the same. There is very often a need for support folks who speak the same language as the users involved in any complaint or issue.

A Real-life Story of App Entrepreneurs

One group of entrepreneurs I worked with during my start-up years came up with an app that involved trades people taking photographs.

The idea was that this would help the trades people show work had been completed in a trustworthy & high-quality way. The app was successfully built, but my entrepreneur friends found that the trades people did not want to start working with the it. They had several trades people download the app, but they had to go and visit them and show them how to use the app.

My entrepreneur friends underestimated how much cost in boots on the ground was required to get the app working.

They may need to be tutorials online, support staff, or people working with them in person to get started with the app. An app that’s been in the store for 18 months plus, all the kinks have been worked out and it has a user base. People know how to use the app because their friends use it.

The Gold Rush is Over

These days there are thousands and thousands of apps being submitted every single day to the app stores. This can work to your advantage as it allows a “soft launch”. This is a small launch to a niche set of customers. You can manually approach your customers and place the app in their hands, just like my entrepreneur friends had to with their trades persons. Or use pull up banners in a local city and hand out cards.

The soft launch process will allow your customers to experience your app, and you can witness that happen firsthand, recording any fixes that you immediately realise you need to make. Remember: simple apps with well chosen feature sets are the most successful money making apps.

Totally a Thing is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

TL;DR

* There are a couple of different kinds of apps:

* ones that direct make money inside the app

* through in-app purchases, adverts, subscriptions or

* up-front “premium” in the App Store or Google play store;

* and commerce apps that help customers engage with a business.

* There are a few different models for monetization:

* Apps that directly make money include free apps; which rely on a funnel and a conversion process.

* Premium apps (pay once up front) are still a thing, but hard to make bank.

* Apps that engage with an existing organisation or business at least have a pre-existing customer relationship to leverage.

* App Economics

* Premium, Free-to-play

* Acquisition, Retention, Monetisation

* To make money from your app

* Trust must increase

* Ensure that customers can complete the tasks in the app

* Have your product owner and UX designer working

* to nail these task based designs.

* Avoid dumping a ton of features from your website.

* Choose 3 tasks, nail them

* Do acceptance testing on an actual phone

* check that your customers will be able to achieve those tasks.

Understand boots on the ground.

* Know how you will support your app when you release it.

* Release via a soft launch to a curated group of customers

* Get rid of friction points that block customer interaction