From a reply I posted to Michael Tsai’s excellent blog, this time talking about pushback to Apple’s encouragement of SUBSCRIPTIONS FOR EVERYONE!!!!1!:

I have no problems paying a bit more for quality apps, but either it’s pay upfront, or it’s highly unlikely I’ll subscribe to an app. Sorry, devs.

I don't believe this or the two comments on this story for a second. You're telling me nobody would pay $1-$2 a year for an app that costs $5? If you don't use it often, it's cheaper to have a full year to try it out [before putting it down].

Many apps are charging too much for their subscriptions. It's the "Cup of Starbucks Pricing Metaphor Fallacy" reversed. "Netflix charges $10 a month. so my subscription price should be in the ballpark. $4 a month is a steal for a subscription!"

No. $4 a month is insane for your app. Price accordingly. Microsubscriptions are the proverbial future.

And for expensive apps, well, MS Office and Adobe Photoshop have already shown the market doesn't mind subscriptions. And businesses have been paying for yearly subscriptions for years.

Labels: app, app store, app store econ, business

I've spoken before that whatever it is that you chose to work on, you're going to be married to it in a way you can't possibly fully understand until you're knee-deep in some edge case a week or more past whatever internal deadline you've set for yourself.

For instance, I thought I'd write a quick app to manage creating podcast feeds. And owning your feed really is one of the most important things to do when you start a podcast. Writing a quick utility like that shouldn't take long, right? It's just XML with some madlib spots, essentially a long string.Format call, with one one-to-many relationship. I've done really quick and dirty apps like this before.

From rufwork.com (for heaven's sake, don't download these ancient VB6 apps):

FAQ Maker
A quick VB 6.0 app made to make making FAQs easier.  Add, edit, delete, change order of FAQ questions.  Links, anchors, links back to the question list, etc, all done for you.  CRAZY FAST.  Get source to FAQ html into clipboard with Ctrl-G.  It doesn't get any better. There's no installer.  If you have Win2k, XP, or have ever installed another VB 6 app it should "just work".  Use at your own risk.  FAQ Maker exe download
Stupid Pet Tricks This is an idiotic group of text manipulation functions that I use fairly often in lieu of learning regular expressions as well as I should. Does do some interesting stuff, like insert wildcards from seperate files into repeated chunks of code, format tab separated rows (say from a database) into easy to read columns, etc. Again, at your own risk, yo. This one's just a zipped exe to download.   Stupid Pet Tricks, aka "The Lazy Man's Regular Expressionless RegExp Tool"

Child's play, right?

Sheesh, no. Once you start programming for others (which even the wack apps really aren't), you've got loads of overhead you'd never expected.

Here's an example. For podcasts, you need to add a duration. Instead of asking users to slap in durations in a specific format, I split hour, minute, and second into separate textboxes.

Simple, right? Well, sorta. What's wrong with this code?

this.CurrentEpisode.Duration = this.txtEpDurationHours.Text
    + ":" + this.txtEpDurationMins.Text
    + ":" + this.txtEpDurationSecs.Text;

Well, duh. What happens when any of the textboxes aren't filled in? How about if one is? What if they aren't numbers?

And I thought I was saving myself validation work...

This is a very simple thing to fix (first cut is below), but the point is that small decisions like this add up.

// This is in a static class of extension methods.
public static string ToDurationString(this string str, bool maxOf60)
{
    string ret = "00";
    int intRun;
    if (int.TryParse(str, out intRun))
    {
        ret = maxOf60
            ? Math.Min(intRun, 60).ToString()
            : intRun.ToString();

        if (maxOf60 && ret.Length < 2)
        {
            ret = "0" + ret;
        }
    }

    return ret;     // though note that I now probably have to check 
                    // for all zeroes when serializing to RSS.
}

I mean, how about this one, where I insert a subtitle for your new episodes based on the date, just as a default:

Great if you keep the current time, not so great if you edit that time to something different. Then my attempt at giving you a "shortcut" doesn't work at all. In the above screenshot, we have a publication date of the 30th, but the subtitle still says the 27th.

So what to do? Do you look for dates in that format and automatically update them if the pub date is changed? Yes, you do, but what a pain... I don't want to have settings in an application this simplistic, but that also means you have to make sure all the "features" aren't ever annoyingly in the way.

See? You can't just skip stuff and expect users to figure out what actions bring down the app and what don't, like some unpatched, extremely rushed Playstation game. You have to mind the p's and q's and actually finish your work.

And that means you'll be doing whatever app work you decide to do for a heck of a lot longer than you ever expected. It also means, luckily, that you'll be a lot prouder of what you've made once it's finally out of the door...

This is the life of an indie.

Labels: app, business, indie, overhead, planning, podcasters' feed generator

Today's words to the wise: When you pick your indie app project, no matter what it is, choose wisely. No matter what project you choose, you're going to be living with it a lot longer than you expect. No, double that estimate too.

I've wanted to write a high-quality mail client forever. Well, for twenty years. I figured I'd give it a real go (again -- I actually wrote a shareware mail handler that specialized in parsing mail list digests years ago), and what's step one?

For me, step one to writing a great mail handler is to write a great mail composer. And for that, I figured I'd want a Markdown editor. To make my work produce a product more quickly, I decided to pack up the Markdown editor as its own application. ^1

Fast forward a few months, and I'm still working on the danged thing between contract work. I had something I could use, and, what's more, did use, myself to edit Markdown in a week or two. That is, my own app was my favorite Markdown editor after a couple weeks of coding.

But man, there are lots of i's and t's before you can let it into the wild, which isn't as forgiving as I am.

• Beta testing the heck out of things
  • Learning to immediately fix usability rather than avoid what causes the issues until they "really" bug me.
• Ensuring you have a full feature set.
  • Anything I need to complete a quality Markdown file, like the one I'm writing now for this post.
    • Uploading images to imgur
    • Smart tab management (much bigger headache than I'd expected)
    • Careful image management (centered? Max size?)
    • Smart shortcuts to gracefully enter text with a minimum of keystrokes
    • Intelligent handling of clipboard contents
      • Like auto-pasting a link when you've highlighted words and hit "insert link".
  • Normal app expectations
    • Handles multiple files fairly reasonably.
    • Save as, export, etc.
    • Performance is good (still working there)
    • No files lost.
  • Things I don't think I'd have to have, but any reasonable app would have
    • File backups
    • Graceful save on close (UWP apps don't also understand user interactions on close)
    • Pretty CSS for the Markdown preview.
    • Recognizable icons for each toolbar command.
    • Toolbar commands for each (well, most) keyboard shortcut.
    • Search.
    • Search and replace. ;^)
    • The ability to communicate bugs! (Something I get "for free" ;^D)
    • The ability to change my favorite settings, for example...
      • Not having images centered, max width of 580px. ;^)
      • Change the default CSS
      • Not exporting the CSS when writing to a file.
      • Exporting the CSS when rendering HTML to the clipboard.
      • This my scratch my itch, but it can't stay that specific, even with that guiding goal.
  • Anything else a new user needs
    • First, and most important for users that aren't me, onboarding!
      • Painfully, this includes a full intro and training session ("stolen" from Commonmark for; I just send the user there from within the app if they're online)
    • Full docs
• Marketing website
  • Man, this is days of work. Some will be reused in docs, but this is days and days of work, even when using a template. Sheesh.

Consumer app vs. Experts' utility

I think you get the point. You're making a consumer application, not an experts' utility. Take this little SQL Profiler Query Cleaner I stole from Matthew Groves, and then contributed a quick pull to do a little more of what I needed.

There's no way this is a consumer app. Not even if you're a SQL master. Here's what it does...

...[F]ire up this program, paste the SQL Profiler output into the top text box, click the "Clean" button, and the bottom text box will have a more SQL Studio friendly query...

That's honestly it. Paste text, click (or hit Alt-C), and cleaned SQL ready to run yourself is in your clipboard.

Though don't get crazy

At the same time that you can't release a crappy utility and call it a finished app, there really are projects that are useful -- and sellable -- with just as simple an interface (or close) as the 'Cleaner. If you pick one, SUPER. SO MUCH SMARTER than what I've done. You can probably throw out seven in the same amount of time it's taken me to hack mine.

But those crazy tasks are still there. You need to make sure you're catching exceptions so nothing ever completely blows. You need to have some marketing. You need to onboard new users during their first run of the app, which, with simple apps, might take longer than writing them.

But -- as a final word to the wise -- at some point, stop. There are ugly forms in my app that are going to make it out in v1.x. They are. I've come to peace with this fact. For instance, this is fugly...

I'm keeping that for now. Crazy, I know. But it only comes up when you're uploading an image to imgur, and isn't there long. It's just to say that something's happening, and the app hasn't frozen, along with a chance to quit.

I'm not excited about it, but it's good enough for now. I'll tweak the message it's showing, above, a little (it says that cancelling might still upload a file, and you haven't even chosen one at this exact point), but at some point, the best advice is still to Just Freakin' Ship.

So, eg, things I'm not including:

• Post to Blogger from my app.
• Post via ftp.
• Wordpress integrations.
• Edit files [not] uploaded by the app.

You get the point.

Lessons from tiling

A lesson I'll talk about more later -- I tiled my kitchen. It was a pain, but it was doable. After I was done, I was a little upset with myself. Lots of little issues. Tiles not quite lined up, some cuts around posts not absolutely perfect.

But guess what I started noticing now that I was looking more closely at others' kitchens? The "pros" didn't do much better. They just shipped. And you wouldn't know it unless you were making your own sausage (or whatever mixed metaphor I should've used. Tiling, shipping, sausaging... They're similar, right?)

^1 Okay, okay, step one was actually to write an rdbms from scratch in C# so I could embed it easily. That took 60-80 hours of "free" time. Step two was to start writing what amounted to view models and middleware for the MailKit library. Step three was figuring out I was going to need a great editor.

Labels: app, business, indie, jfs, markupdown, overhead

Let's take a quick aside from yesterday's post where Adamson says Overcast "is only barely viable". Really?

Wow. 855 * $2 (after Apple) = $1710 a quarter = $6,840 a year.

That's iff those were the only patrons Overcast got all quarter. That seems a higher number than I usually see (On Aug 22, it was 481, and around 480-500 the next week), but let's start playing with 200 a week, and oversimplify to 800 a month.

If we say that they only pay the lowest amount once -- $2.99 for three months -- that's 800 x $2 after Apple's cut = $1600 a month. That's $19,200 a year. Not much, but if you can sustain that without huge programming costs, not bad.

But let's pretend that the patrons pick 12 months instead of three, and pay $11.99. That's essentially $8 after Apple's cut per patron, or four times as much as our first number. $76,800 a year. Again, well below market rate for an 8-to-5, but nobody's working 8-to-5 today on Overcast. (All that previous work is a sunk cost at this point.)

For 400 patrons a week, we double those revenue numbers. Now we're talking.

Here's what it looks like:

At today's rate of 855 (though remember, there's no way that's what it's averaging), assuming no attrition/full years from each, it's $328,320, if my quick calc is right. Not bad for a single app that's not without its bugs.

Let's ballpark a middle ground at $80,000 (maybe close to 400 a week averaging a little over $5.75 each before Apple's cut) for this year. Plus 2014's $164k. Plus whatever happened last year. For a single app plus updates. That's a good investment.

Labels: app, app store econ, business, indie