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