My Developer Left me High and Dry
5 Ways to Avoid App Disasters as you Work with Coders
--
“Wow” I thought to myself — feeling a bit guilty as I eavesdropped on the call.
I couldn’t help overhearing the tale of woe, as the woman entrepreneur bemoaned her situation loudly over the phone. She was talking as she sat in the hot-desk area of our co-work space.
“Where’s everything we paid for!” she cried, her hands waving in the air as she howled in to her phone.
Where’s everything we paid for?
She’s been abandoned by someone she trusted to build her app? As an app developer myself I instantly felt bad for her — what a stain on my profession.
“Now we can’t meet our marketing deadlines!” she went on.
Ugh. That’s terrible. The developer promised to meet a date and failed?
I resolved that I would try to meet up with her and see if there was anything I could do to help.
As it turned out: a lot.
Carol (not her real name) had a great business plan, and good ideas but was sailing in uncharted waters when it came to getting an app developed.
She was great at working with people like print shops and social media influencers; but did not understand code, or how apps got shipped into the app stores.
What I am sharing here is what evolved with my talks with Carol, but also with other folks in that co-working space; and my other interactions with the startup community.
Way #1: Understand and anticipate the risks
Don’t go into app development thinking it’s as simple as those little round cornered icons on your phone.
Getting an app built is a project. What’s more its a Software Project — and I hate to say it but just statistically software projects fail at an alarming rate. It’s about half of projects that fail. That means its a coin-toss whether you even get the app you want delivered!
Its a coin-toss whether you get the app you want delivered!
Whaaat! That can’t be right! I see apps all the time! How can there be failures!
That’s the reaction of most folks in audiences in my public talks where I share that statistic. Check these sources. In my experience that figure is accurate.
- 1975: Mythical Man Month by Fred Books
- 1994: The Chaos Report by The Standish Group
- 2003: Death March by Ed Yourdon
The failure rates are 1/3 to 2/3 of projects late, way over budget or not working as expected.
I have some good news for you though: it’s easy to be in the success group if you plan ahead & don’t go in blindfold. Technical projects fail for people-related reasons: those are reasons we can do something about.
App project risks are not mysterious unfathomable icebergs that lurk ready to sink you: they just need to be dealt with, and not papered over. What are those risks then?
I’ll point to them in the next 4 “ways” below, but understand what is at stake: ignore these things and your app will go the way that Carol’s did most likely. Plan ahead and you be sure you’re doing everything to make sure your app is one of the successes.
Way #2: Get the Code
Unpack that tip in as many layers of meaning as you can. “Get the code” as in make sure you get your hands on it; but also as in understand what it means for your project. It’s the goose that lays the Golden Eggs.
You don’t have to transform yourself into a developer, but it’s critical to understand what role the code plays, and what artefacts make up the things needed to create new builds of your app.
I’ve written several extensive guides on this subject, so you can start there to build understanding. The takeaway is that you need what I call “the keys to the kingdom” — the repository access. If you’ve ever heard of GitHub or BitBucket that’s what I’m talking about.
You don’t need to use it — though you can if you’re excited about code. But you do need admin access to your repo, so that if things sour with your developer you can set up shop with a new developer and provide them access to pick up where the previous developer left off.
If you’re keen to rush ahead with a minimal understanding try this analogy: like the way a Photoshop PSD file can produce a JPG or PNG image; your code files can produce an app, but the process cannot be reversed! You can’t take an app and get back the code!
You can’t typically take the app and get back the code used to create it. You need admin access to your repo.
Note: I know some folks might be saying Well that’s wrong you can reverse engineer the app, and while that is technically true its not helpful because you’re going to need a lot more technical help to do that than it would have taken to just have a copy of the repo around in the first place.
Way #3: Move Ahead in Small Steps
Software is typically developed via iterations. What does that mean?
It means your idea of what the app is will change. Drastically. You will need to work cyclically with your app developer team or costs will blow out very quickly as changing software once its coded is very expensive.
A quick primer on app teams: they are made up of a Product Owner, UX designers; a Project Manager and Developers. They work in iterations, producing work to a cadence. It might be fortnightly, for example — with the team committing to a slate of work at the beginning and delivering as much as they can of that work at the end of the fortnight.
The developers are managed by the technical Project Manager. They produce builds of the app and demonstrates them to the business-focussed Product Owner and UX designers for acceptance. Product owners select and choose the priority of features for the next iteration.
The Product Owner is thus the one who ensures the app fits with its intended market— and its a role which can be filled by you yourself if you’re super pro-active — and want to learn via that great courseware by Jez Humble. I’ve written a much shorter guide for app-entrepreneurs on how to be a Product Owner.
If even that sounds too complicated, just replace your idea of getting an estimate of “when it will be done” with “watching it grow” as you take part in the process of building the app. The great benefit of working with the app development team like this is not only do you get to shape the app, instead of relying on a big design up-front; but also you’ll know very well when the features you need for launch are ready.
If working closely with the app developer team is just not possible, your other option is to decouple your apps development progress from your big splash “go live” dates by using a soft launch.
App development is not a thing where you “wait months & months” for a big handover, like when you take ownership of a house or office building and have a ribbon-cutting ceremony to get the front door key.
Be an active Product Owner, and demand working software through the life-cycle of app development.
In my experience the most certain way to join “Carol” and be among the software projects and app developer horror stories is to ask for estimated delivery dates and then be absent from the developer process until then but expect everything to be wonderful on launch day.
Sadly I have seen this happen so many times, and in some cases been called in to try to fix things up once it has already gone wrong.
It’s a very common practice in companies that outsource their development to overseas developers, especially if they’re not upfront about this. They find it difficult to provide working software via beta-test builds because they’re only getting them from their overseas outsourcers themselves. You should not be making any progress payments without being able to try out for yourself actual working software.
Appster was one of the big horror stories in app development but I can tell you there are still companies in Australia today who are failing their customers in similar ways. Over-promising and under-delivering is still happening in app development.
And it’s not all the fault of the software companies: shady operators succeed because clients too often have a focus on “shopping for quotes” and don’t know what to look for in an app development process.
Way #4: Learn how to Prototype
For Carol, app-entrepreneurship was only a small part of her in-real-life business and she saw getting an app as just another tick-box in the list of digital presence compliance points. She already had a website, which she was not happy with, but it was a work in progress and was already getting her customers. She figured she’d just put that on an app.
But a mobile app is not a website. Even a “responsive” website, designed to fit on a mobile phone screen doesn’t come close. These days so many blurred lines exist with progressive web-apps, hybrid apps and React Native app development.
The big problem is when app owners want to cram everything that is on their website onto the screen of an app — responsive or not. They first have a huge blowout in cost for coding up all of those website features, a ton of usability problems that translate into cost as well; but worse if they manage to ship at all its so confusing to the customers that the app winds up being a waste of money.
Apps work best when you leverage the power and ubiquity of the mobile platform, to put simple task based user-experience into the hands of your customers. I could talk about this until the cows come home but the only way to get this right is to see it for yourself: and that means prototyping.
If you get a UX designer to do this it completely defeats the purpose because they’re producing production ready UX artwork when you’re only at the concept stage.
Instead of thinking of exposing what you have on your website. Start with your customer: what is the number one high-value interaction they make with your business? Put just that into your app — and start by prototyping it as though it was the only thing in the app.
Way #5: Understand App Business
Whatever your business was before you launch an app, afterwards its a digital business. That means understanding ways of doing business that might be out of your comfort zone.
When I talked to Carol about her app it was pretty clear she saw it as an extension of her website. When I asked her about mobile notifications, churn rate and cost-per-install I got a lot of blank looks.
If things go wrong with an app build process, often you can fix it, especially if you manage to build a relationship with a new developer and avoid the previous mistakes. To do that, you can start with analytics — as you make changes to your app that’s already in production, being used by customers, who are feeding back real life data. This is true even if it’s not performing due to bugs & problems.
Being able to try out changes using A/B testing in live builds is great for iterating toward that perfect app, even if it was a bit lack lustre on launch.
The key to understanding app business is to think about your customer first — you are using a space that is very personal to them, the screen of their mobile device, to carry out business. Make it simple, direct, and know what it is you are doing for them.
Via user-journey mapping, careful understanding of your marketing, or other forces that resulted in them being in the app today, you can plan what you expect them to do, and use your analytics to follow them on that journey.
So make sure your app build is up to it. I have a guide on my site that covers many aspects of app business. I talk about analytics and notifications there, along with a few other topics.
Appily Ever After?
What happened to Carol? I don’t know — I had a couple of conversations with her but she wound up moving her business out of the co-working space. Last I heard of her was when she was arguing with a new developer, on her phone and wanting to know why they hadn’t delivered what she asked for by the date they’d estimated.
I didn’t think it would be long before that developer left her “high and dry” as well. When Carol and I talked she had a lot of disbelief about ideas like working iteratively: she was far too busy she said to be involved with the app; she just wanted them to let her know when it was done.
Meanwhile apps are just as popular as ever. Building one yourself? Feel free to fire your questions at me, leave a comment or head to Smithsoft and contact me there.
Good luck!
