App Failure, What Next? – Part 4

This is the final part in a series, in which I’m reviewing the approach we’ve taken in the development of our first 3 apps. Apps that have failed.

In Part 3 I mentioned that I’m feeling positive about taking one of our existing apps and trying to ‘market’ it. Well, that’s what I’ve decided to do. And the app that I’ve chosen is Wafflr.

Before I get started on this project I want to acknowledge something that’s been missing from the previous three aricles.

So far I’ve focussed on the apps that we’ve already made, and the choice between giving them up or trying to work out if the ideas are potentially, good. All after the fact.

I deliberately started at the end – at the point where failure is acknowledged. Why? Because I think it’s only when an app fails that many developers start to ask questions.

That’s what we’ve done.

In the final part of App Failure, What Next?, I want to consider the questions that, were we starting on something new, we should ask before we begin…

Do We Have a Good Idea?

With three apps and no success it’s worth asking if the ideas were flawed from the start. Considering this, I’ve partitioned my thoughts into three areas:

1. Actually, People Won’t Want That

To date, the apps we’ve created have each had a niche element to them; a specific workflow or a ‘clever idea’.

We know that many people have made successful apps that were simply released into the store. Consider a recent example from Stuart Hall, described in his article: An App Store Experiment.

“I wondered what would happen if you made an app in a few hours, stuck it in the App Store and didn’t bother telling anyone? So I tried it out…”

It’s an interesting article, and experiment, and it shows that in some cases a well-timed idea can be successful.

Whilst none of our apps have been ‘topical’, I have thought that they had broad-ish appeal. I’m aware that optimistic people can fall into the trap of convincing themselves that something is good. Perhaps the truth is, we don’t have a needle for good ideas.

In which case, going for an un-founded idea isn’t a good choice for us.

2. Go With Something Proven?

In my article about the Minimum Viable Product I linked to PandoDaily’s article detailing Three reasons not to build a Minimum Viable Product.

That article considers the case where the viability of an idea/product has already been proven. It’s not necessarily this straight forward, but there are examples within the App Store of viable apps. Ideas that have been proven to be popular.

One approach would be to pick a genre of app and then try to do it better. Focus on the implementation and the delivery. Exploit a gap that other apps of the same kind aren’t doing so well.

Although there was an element of this with our choice to write Memed – I don’t think what we were aiming for with that app was necessarily viable. We just, wanted to write it.

If we intended to jump into another app development without up-front research, picking something proven and focussing on a strong implementation would probably be an improvement on our approach to date.

What’s more, in the spirit of this series we could build marketing in from the start, before launch, rather than when it’s (potentially) too late.

3. Do Some Market Research

Earlier in this series I outlined this scenario:

  1. Indy developer has an idea
  2. Developer puts in a bunch of work in to make the app
  3. The app flops – it’s not making any money
  4. What now? How does the developer respond to this?

Well, there’s a huge “would anyone else want this app?” missing between points 1 and 2. As that article from PandoDaily points out, there’s a big difference between what you really know and what you think you know.

For example, I’ve been mulling over an idea for the last year or so; a product for students. We’ve discussed possible approaches, looked at sketches – and iterated on some of those early design concepts. It’s remained at the top of the list while other notions have come and gone. It still seems like it could be turned into a good product. To me.

But I don’t exactly have a strong track record when it comes to bringing something new to iOS! Before working on an idea like this I think it would be wise to add a validation step and test the water, first.

Are We Aiming High Enough with the Implementation?

I haven’t really touched on this – but the quality of an app is obviously a critical component of it’s success/failure. We know that ideas are worth nothing – it’s the implementation that counts.

How well are our apps made? Are they worthy?

In our case, as spare-time developers, time has factored into many decisions. It has affected the scope of the apps we’ve written; the last two in particular are ‘little’ apps. It can influence how long we spend polishing and refining. And, though it’s not the only reason for a lack of marketing, there’s no doubt, marketing requires a bunch of time.

Of course, the ‘time’ problem isn’t unique to people writing apps at home. It’s a balance for all development projects, large or small. The key point is, we’ve felt it influence our development choices. Or perhaps it’s more meaningful to say, we’ve let it influence our development choices.

On the flip side, our time constraints have been entirely self-imposed. We have the freedom to simply, take longer. We should question what factors make us want to release sooner and compare that with the quality that we’re putting out there, the whole spectrum of our output. If we think we need to do better, we should allow things to take longer…

Is This Product Sustainable?

If I’m honest, the last two apps we’ve written have had pretty short term goals in mind. Or at least, short development horizons.

How about something more sustainable? I’ve been looking at this from the angle of wanting to produce something more substantial. Something that would warrant a presence outside of the store. An app, or apps, that solve a more-involved problem…

The App Store market gets much debate and this topic is ‘current’ right now. I’ve done a lot of listening as other developers and app producers, people who’ve had more success that we have, give their view on how developers can continue to survive in the store. I found the following, recent examples, particularly interesting:

Lattice Labs wrote about Premium, Fremium and Subscription pricing strategies.

Joe Cieplinski suggested that paid-up-front apps can be viable in certain markets.

In his article Yep, pair apps are dead, Jeremy Olson considered thinking bigger – “we need to stop making apps and start making businesses”.

There isn’t a single, right approach. That’s for sure. But the landscape has changed. Looking forward, my thoughts are on something that’s sustainable.

Next: Marketing Wafflr

As the next step, rather than starting on something new, I’ve chosen to market Wafflr.

Where I want to be is working on something with a bit of substance, a bit of longevity. Serving a user base. Wafflr isn’t there now, but maybe it could be. Maybe there’s a niche that will respond to a premium, paid-up-front app.

The plan is to promote, not develop. But if the app gains some traction we have ideas in the backlog that can take it closer to being a ‘featured’ app for public speakers.

Independent of Wafflr’s success/failure, I’m hoping to learn something about producing more than just an app-hoping-for-a-hit.

Advertisements