Oops, sorry, wrong graphic. I meant this one:

Hmmm… not much difference really. As you can see I actually sold nothing on Sunday. Apparently everyone was interpreting “day of rest” as “don’t buy any iPhone apps today.”

This article is kind of a postmortem for the launch of Hearts Attack. I attempted a few different things in order to drum up sales. Some were more successful than others.

• One of the things I did before the launch was some search engine optimization on the Hearts Attack product page. Dan Wood of Karelia has some good resources on how to do SEO.

  I was fairly pleased with the results. The product page ended up on the first results page for a few of the keywords I was targeting. It could be better, but not bad for a PageRank amateur such as myself.

• On the day of launch, I issued a press release through prMac. I opted for their “extended press release” which sends the press release the same day and to more people. It’s only $20 so it’s low risk.

  I did see a couple of obvious benefits from this. The first benefit is “link juice” to the Hearts Attack product page and our company website in general. I had done some SEO earlier and discovered the biggest thing we were in need of was links. This helped immensely with that.

  Secondly, I mentioned in the press release that promotional codes were available upon request. Only three people ever asked for them, but I happily gave them away. I have not seen any reviews as a result, but hopefully at least I garnered some good will among reviewers.

  Speaking of reviewers, one thing I did not have ready at launch, that I should have, was a press kit. I kept mine simple in that it just contains screenshots and images of the app icon. I should have linked to it in the press release and product page, because it was something the reviewers immediately asked for.

  It terms of how many sales were made because of the press release, I don’t know. It did noticeably increase traffic to our site, but I didn’t have LinkShare hooked up at the time, so I don’t know how many of those visitors became customers.

• I wrote about Hearts Attack here and tweeted about it. I both published my own press release and then followed up with the story about Hearts Attack came about.

  This drove a decent amount of traffic to our website, and resulted in a few sales from my friends and other people who follow me on Twitter. Like the press release, it also helped with the “link juice” of our website.

• I asked my wife, Elaine, to write about it on Facebook since she has approximately 30 bazillion friends on there and I have none. Some say this is because I haven’t even created an account, but I think Facebook is just being stuck up.

  Anywho, this didn’t create much traffic, but it did create a couple of sales from friends who follow Elaine on Facebook, but not me on Twitter.

Of course the biggest driver of sales is being listed at the top in the App Store, which by default is sorted by the release date. Unfortunately being at the top is fated to be temporary, and I could easily tell when I fell down the list by looking at my sales.

In summary, I learned: I should have had LinkShare up and running to begin with so I could properly track conversions and know what approach is the most successful as far as sales. Second, I should have a press kit ready at launch and linked to it from the press release.

Way back in 2008 the original iPhone SDK came out, and I, like a lot of people, was excited about developing apps for the iPhone. My company is primarily a software development services company so I was mainly interested in learning the SDK so we could pick up iPhone contracts in addition to Mac ones. It also happens to be the case that my favorite card game is hearts, so I decided a good way to learn the iPhone SDK was to write my own hearts game.

After a couple of weeks I had the basic functionality implemented, and noticed I was playing it a lot. I realized then that I could probably make this into a product. Furthermore, releasing an iPhone app through the App Store seemed like a good way for us as a company to begin making the transition from a services based company to a product based one.

If I was going to release Hearts Attack as a published app, I knew the UI and presentation had to be greatly improved. I went through a lot of mockups for the main playing view, including one where everyone’s cards — all 52 of them — were always visible somewhere on the table (a truly horrible idea). Unfortunately I don’t seem to have most of the mockups around anymore, but I found a couple which you can see below. (See the product page for the end result.)

The biggest challenge I had was fitting everything on the screen and it still being legible and usable. By trial and error I figured out how small I could make the cards and still make them tappable, as well as their optimal position to make them accessible with one hand.

I began thinking about what would make Hearts Attack unique or different from its competitors. Back then there were literally just two iPhone hearts games in the App Store, and I felt pretty confident that what I had was already better than them, but I wanted to be sure. I decided on: oddball talking computer opponents, a tutorial that gave not only card suggestions but the rationale behind the choice (a pet peeve of mine), and multiple undo support for mis-taps and tactical errors.

The last step was to get professionals to do the sound and graphics. I ended up hiring a sound designer, a graphics designer, and a character illustrator. The sound design went smoothly, but getting the graphics done was a lot more involved than I anticipated, which is another story for another day. Jordan of OneToad Design created the app icon, playing backgrounds, and the special card backgrounds for the queen of spades and jack of diamonds. Lara Kehler did the character illustrations, which turned out great.

Unfortunately, Hearts Attack went on hiatus in early 2009. I was working full time on an iPhone contract, and simply didn’t have a lot of time to put into Hearts. Secondly, I had lost all desire in finishing it. It was becoming increasingly apparent that iPhone users didn’t want to pay more than $0.99 for anything, despite all the whining I did about it. I convinced myself it wasn’t worth releasing Hearts because it would never make back the money it cost us to make. Hearts stayed dormant for an entire year.

A couple of months ago, I decided to pick Hearts Attack back up again. I had the time and, as someone pointed out to me, it would never make money if I didn’t release it. I was tempted to update the app to the latest SDK (I started Hearts back before you could even use nibs on the iPhone) and add some features. I decided against this, because I really just wanted to ship it. I did have to update it to the 2.2.1 SDK because the current Xcode tools no longer ship with the 2.0 SDK.

Instead I focused on fixing the bugs and adding polish. Fortunately for me my wife happens to be a professional software tester with iPhone experience, so I got lots of good bugs to fix. I also prepared a press release, created a website, and otherwise got ready for the release. After I felt the app was stable enough, I submitted it to Apple on Friday. It was approved on Monday.

At this point, I’m still not convinced I’ll ever make back the money we spent on sound and graphic designers. A hearts card game simply is never going to be a big seller, and price point isn’t high enough to make up for that. Right now, I’m tending to think pessimistically about sales, but I’m going to do what I can to drum up sales and see how things go.

It’s a “wait and see” situation as to if we develop any more iPhone applications to sell ourselves. Of course, regardless of how well Hearts Attack does, we’d be happy to develop your iPhone app for you.

The player competes against three of seven possible colorful computer opponents, each of which has their own distinct looks and personality. The personalities range from a communist kitten trying to overthrow oppressive humans to a vegetarian vampire to a pacifist pirate who sells insurance. They always have something interesting to say about how they and their opponents are playing. The computer opponents can be configured to play at trivial, easy, normal, or hard difficulty levels.

Unique to Hearts Attack is its in-depth tutorial system. The tutorial begins by giving the player a brief introduction to the rules and strategies of hearts. Throughout the game it offers suggestions for which cards to pass or play, including the rationale for choosing those cards. The suggestions are useful to beginners learning how to play, and to more advanced players looking to improve their game. The suggestions can be used apart from the tutorial.

Since players always have their favorite way of playing hearts, Hearts Attack allows flexible configuration of the rules. Players can choose how cards are passed, which player leads and with what card, how penalty and bonus cards are scored, and what is required to shoot the moon or the sun.

Device Requirements

• iPhone or iPod touch
• Requires iPhone OS 2.2.1 or later
• 4.7 MB

Pricing and Availability

Hearts Attack 1.0 is $2.99 (USD) and available exclusively through the App Store in the Games category. Review copies are available upon request.

Links

• Order N Development, LLC
• Hearts Attack 1.0
• Purchase and Download

Company Information

Order N Development, LLC is a software engineering company providing contracting services for the Macintosh, iPhone, and iPad platforms. Order N Development was founded in 2002 in Dallas, TX by a small band of experienced Mac developers. Copyright 2002-2010 Order N Development, LLC. All Rights Reserved. Apple, and the Apple logo are registered trademarks of Apple Computer in the U.S. and/or other countries.

The old design simply wasn’t meeting our needs. Specifically:

• It didn’t communicate clearly what exactly we do here.
• It had a search box which, as far as I can tell, didn’t, and has never, worked.
• It had several pages describing services we don’t perform, at least not when a cop is around. Some of these pages just had boilerplate text in them. e.g. “Item 1″, “Item 2″, etc
• The visual design was really old and unprofessional. The new is at least not old.
• The old feedback form demanded a lot of extraneous information like title, company, telephone number, home address, when you shower, etc.
• It had a copyright date at the bottom of 2002, which caused people to ask: “Are you guys still in business?” This was apparently a barrier to them sending us money.

Fortunately, we mainly rely on word of mouth to get clients, but a bad website certainly doesn’t help our business. We could be missing out on clients who find our website, but don’t contact us for any of the reasons listed above.

I’ve recently had some time between contracts, which I used to think about how a software contractor’s website should be structured and what kind of information it should present. Also, I slept in late a lot. I came to some conclusions:

• It should immediately obvious to a visitor what the company does, no matter what page they land on.
• It should have a portfolio so the visitor can see what kind of work we have done in the past, and see if that matches up with what they want done at the quality level they want.
• A brief description of services that we do provide, explained in layman’s terms.
• It should be obvious and easy to get in touch with us. The form for submitting a message should have as few requirements as possible.
• It should contain a brief overview of the company, and the people in it. It should put a human face to the company.
• Noon really is not a bad time to wake up.

I also decided to add a page for products, mainly for future use.

Overall the project was a fun — and hopefully financially rewarding — exercise. It was interesting to think about what would induce a visitor to stick around on our site, and then actually contact us. I’m not sure if I got it completely right, but it’s at least a step in the right direction.

My app is a game, so in addition to an application icon, I also need avatars for players and some game backgrounds (like wallpaper), among other things. Basically, I’m looking for recommendations here. Anyone have someone they’ve worked with and really liked?

I also need sound effects, which I’m pretty lost on. I mean, if I ever need a twoosh sound, I know who to go to, but for more complex sounds, I’m just don’t know. For those of you who have done games, who did your sound effects?

After I get some real artwork into the game, I’ll see about posting screenshots and whatnot.

This is Zits from 7/14/2007, in which Jeremy, the main character, learns a harsh reality about life.

I bring this up on my blog because I became more acutely aware of how much “that FICA dude” was getting when I became self employed. When you start writing the checks yourself, as opposed to your employer taking the money out before you even see it, there is an even more stark realization.

I should point out that the current logo was a gift from a client, who simply pitied us, and our non-graphic designing ways. Since we were doing engineering services for them, they didn’t want their clients to think they had partnered with a firm that consisted of four year olds with a bad case of the shakes, when they saw our logo. Anyway, not to look a gift horse in the mouth, but we felt it might be time to upgrade our logo to something more modern and less busy.

A sane person might have taken that as a cue to go hire someone qualified, but not me. Instead, I fired up my copy of Fireworks, the greatest web graphics program ever, and started working on my abomination before God… I mean… business card.

Here’s what I came up with:

Sorry. I probably shouldn’t have just flashed that up there without some sort of warning. Hopefully no one stabbed their eyes out with a rusty pair of scissors just to get the images out their head. As a community service I give design teachers permission to use these in their classes as what not to do. Just make sure you’ve hidden all the sharp objects and the students are wearing the appropriate eye protection (blindfolds) before exposing them to my designs.

Anywho, after my partners got done whining about their bleeding eyes, we decided we might should hire a professional. So we’re in the process of looking for logo designers, and pricing how much such a thing would cost us. Unfortunately, between the four of us we apparently only know one designer, which somewhat limits our options.

I have to admit, it was a lot of fun doing someone else’s job. I mean, graphic designers have it easy. They just need one of them graphics editor thingies and beret, and they’re all set. I think tomorrow I’ll do someone else’s job. Maybe a neurosurgeon’s. I hear that it’s all the wrists, and last I checked that’s what was connecting my arm to hand. Maybe I’ll get one of those cool bibs they put over their faces when cut open someone’s brains.

At this point, I think we’ve got enough ideas, and we just need to pick one and move forward with it. The question is: which one?

I wrote up a process document on how to pick any idea (which is below), but I’m wondering if its the right way to do things. So I have a question to those of you have built your own product(s) (or are in the process of doing so): How did you decide what to build?

Did you simply build what you wanted to? Did you do research and find a product gap and fill it? Did you try to find the idea that you thought would generate the most money or the most users? Did an idea just hit you one day and you decided you had to make it?

My “process” for creating and picking an idea follows:

The purpose of this document is the establish a simple, lightweight process for coming up with and evaluating product ideas. The process should result in at least one idea that we can turn into a viable (read: profitable) product. The process is flexible and can be changed as circumstances change or as better ideas are introduced. The process evaluates ideas based on business factors, not engineering factors.

1. The first step in the product idea process is generating ideas (i.e. brainstorming). At this point in the process the ideas are vague and not well defined. The purpose of this stage is to generate as many ideas as possible, without evaluating them. The hope is that enough ideas are generated that a few of them are viable both engineering and business-wise.

Ideally, at the end of this step, we should have at least a few hundred ideas to choose from.

2. Second, after generating all those ideas, the next step is to whittle them down to a manageable number so we can do research on them. This will probably be between 10 and 20 ideas. By applying some simple criteria, we should be able to arrive at the top ideas we might be able to pursue. Ideally these criteria do not require research, but can be answered easily and quickly.

Criteria:

- What user problem/pain does this solve? If it doesn’t solve a problem, no one will buy it.

- How is the user going to pay for it? Or how does the product generate money? If a cool idea can’t generate money, its not worth it. A lot of Web 2.0 apps fall into this (like digg, YouTube, etc). They solve problems, but they don’t make money.

- What is the potential customer base? i.e. Is it consumer, professional, or developer level product? This will help rate the ideas – a consumer product is usually more valuable than a developer product since there’s potentially a larger customer base.

- Without architecting or engineering the product, is the product even technically feasible? If we’re trying to make cold fusion work, we should probably pass on that for now.

These criteria probably will not eliminate all but 10 or 20 ideas, but they should help us rank them and pick out the best 10 or 20 ideas. Some ideas might have to be fleshed out a bit more, but hopefully even vague ideas can be evaluated at this step in the process.

3. Next we need to research the top 10 or 20 ideas. This means fleshing them out a bit more so we can make more critical decisions about them. The research is targeted at finding out how much money the product might bring in, how likely we are to attract customers, and what building the product might cost.

What we need to know:

- How big is the potential customer base? This is an extension of what kind of product is it: consumer, professional or developer. Do a lot of people have the problem this idea is trying to solve, or is it a niche problem?

- What can we charge for the product? What is the competition charging? Not trying to determine final pricing here, but what is the range we could expect.

- How will we sustain income with the product? Upgrades, subscriptions, ads?

- Is there any competition? If so, who is the leader? What makes the leader, the leader? Can another product be sustained in this environment?

- What are the core/basic features in the product? We don’t need or want a feature spec here, just a general idea of what we’re providing. This should help with cost of building as well as what we can charge.

- What will set us apart from the competition? i.e. Do we think we can actually capture part of the market?

- What are the engineering costs in regards to time? i.e. how many engineers for how long? We don’t need a real number, just general estimates so we can compare it against the other ideas.

- What is the required infrastructure to make this work? This would obviously be bigger for web apps which need a large number of servers. Don’t forget about add ins to do try-before-you-buy or other demo schemes.

- What kind of marketing might we need to make the product a success? Mainly we want to know how expensive it will be to market the product.

- Are there legal or other expenses (like facilities or sales people or development software) that are required?

4. Finally, we need to evaluate the product ideas based on our research. Knowing how big our customer base is and how much we can charge will give us a ballpark of how much money the product could potentially bring in. The competitive analysis and feature ideas will give us an idea of how much of that money we might be able to get. The engineering cost estimates and required infrastructure costs will give us an estimate of the total cost to build the product.

So the basic “value” of the product idea is:

(Potential money in the market) * (Part of the market we get) – (Total costs of building product) = Profit

That’s real scientific stuff. Please don’t take it too seriously.

We’re not going to get hard and fast numbers out of this step, but it should give us a vague idea which idea is more valuable, business-wise, than the others. At the end of this step we should have at least one (if not more) idea that we can then take on to the product development process.

Once again, this is a light weight process that can (and probably will) change as we learn things. If you have ideas, suggestions, or comments about how to make this better, please let me know.

As you can tell, my process focuses on what product will bring in the most money. While money is good, I don’t want to build a product that I won’t enjoy working on.

What are your thoughts?

8am – Wake up, scratch self, turn over, fall back to sleep. No respectable software engineer gets up this early.

8:15am – MacBook Pro’s dancing in my head. Unless you’re my girlfriend, in which case, I only dream about you baby.

9am – Wake up and realize I do not own a MacBook Pro. My dreams crushed, I see no reason to remain conscious, so I scratch myself, turn over, and fall back to sleep.

9:30am – Apartment maintenance personnel decide that I have slept long enough and begin pile-driving two feet outside my bedroom window, where in the alley they have apparently decided to construct a large shopping center.

9:31am – Contemplate the needed trajectory of a rock that would injure, but not kill, said maintenance person. I might need my ice maker fixed at some point.

9:35am – Give up on plan to maim maintenance personnel because it would involve moving a part of my body, and, let’s me honest, who doesn’t want an large 24-hour supermarket directly outside their window?

10am – Unsure if I am yet awake, maintenance personnel begin mowing what’s left of the grass outside my bedroom with a bush-hog machine.

10:01am – Stagger the 10 feet from my bedroom to my “office.” Manage to stub my toe on no fewer than seven objects. As required by law, at least three are more dense than depleted Uranium.

10:02am – My now semi-awake brain discovers that the computer/printer combo doesn’t not provide this “food” that the Wizard needs, badly.

10:03am – Stagger over to the refrigerator. My agile feet know the path well, and manage to run into the same seven objects.

10:05am – Think about how good a breakfast with scrambled eggs, bacon, and blueberry pancakes would taste. Unfortunately, I am a bachelor so anything that cannot be made from hot-dogs and month old bread is out of the question.

10:06am – With hot-dog flavored “PopTart” in hand, return to the computer.

10:07am – Digg and Slashdot.

11:03am – Decide to actually “work.”

11:04am – Start pulling down code to work on with Perforce, the Fast Software Configuration Management System. The file set consists of three small text files, one resource file, and a large image file describing how the software system works, assuming they had actually built it that way.

12pm – Lunch, which is a hot dog, stale bread, or some combination thereof.

1pm – Perforce, the Fast Software Configuration Management System, actually completes the synchronize operation, leaving me with three small text files, twenty corrupted resource files, and someone’s half eaten pimento cheese sandwich.

1:01pm – Consult Digg and Slashdot, while contemplating why anyone uses Perforce.

2:00pm – Remember that people use Perforce because the alternatives are worse. For example, Visual SourceSafe is a service by Microsoft in which they send a salesman to your place of business to kick you in the seat of your pants repeatedly. In the Professional version of SourceSafe, the salesman also steals your credit card and purchases a site license for Microsoft Money.

2:01pm – Attempt to log into the client’s bug database, so I know what to work on. Discover that I do not have access to bugbase, which is on the internal network, because I did not file a business case for why I need it, three years in advance.

2:05pm – Call the client’s IT department, explain that I need network access from my Mac. To avoid getting the wrong software, keep mentioning that I am using a Mac during any awkward silences and anyplace in the conversation a normal person might say something like “hello.” Sensing my urgency, IT promptly sends me five copies of the Windows software.

2:10pm – Call IT department back to explain that need Mac software, to which I am promptly told “We do not support Windows 98.”

2:15pm – Finally reach the one Mac IT person, whom they apparently keep locked in a cage in the basement, and feed old PowerTalk documentation. He cannot send the software via email because of the 32 byte email attachment limit, but he is able to smuggle out a CD of the software, on the back of one of the many fruit bats in his cage.

2:30pm – Discover that VPN software does not reliably connect to client’s network, but does, in fact, waste a large amount of space on my hard drive and not uninstall.

2:31pm – Call IT department again to explain VPN software does not work. IT carefully explains that I must either rewire my apartment, reconfigure my router so that it is solely and permanently connected to their network, or move to California and/or India for VPN to ever work. They are not sure which. Smoke signals are suggested in the interim.

2:45pm – Randomly change settings in the VPN configuration until I can actually connect to the internal network. Discover that although I can connect, I have no security access to any servers on their network, including the bug database. Furthermore, IT has decided that, for reasons of productivity, anyone connected through VPN should not be able to access anything outside their network, such as, for example, the computer sitting right in front of me.

2:56pm – Call IT department to be granted access to the bug database. The IT person that I reach calmly explains that, yes, he can grant me those privileges, but won’t, because he strongly suspects that will allow me to do actual work.

3:03pm – Have my contact within the client company call IT and explain that its OK for me to do work because I do not work in IT.

3:30pm – Feel smug about getting to bill client for all the time IT wasted.

3:31pm – To celebrate victory over IT, Digg and Slashdot.

3:52pm – Examine the first bug I am supposed to fix, which is marked as “severe” and a “crasher.” It states: “When I press Command-Q, the application quits.” I spend the next hour on the phone explain why that is expected behavior. The phone call ends with the quote “Well, that’s stupid and Apple should change it.”

4:52pm – Digg and Slashdot.

5:23pm – Examine the next bug I am supposed to fix. Although it is simply a misspelled word that has been in the software for seven years, it has now become “urgent,” “must fix,” and, “severe.” Oddly enough, the bug was entered by a technical writer.

5:33pm – Open up Xcode, Apple’s integrated development environment, specially designed for the Mac user who has lost the will to live.

5:38pm – Change the resource string to fix the misspelling, which the previous engineer was unable to do, because, apparently, he could not locate the second button on his Macintosh mouse.

5:50pm – UI designer notices that I fixed the misspelling, and suggests other improvements to the wording, such as rewriting the host operating system from scratch to use more color gradients.

6:04pm – While muttering under my breath about out of control UI designers, Digg and Slashdot.

6:45pm – Examine the next bug, which is from a customer, requesting that we add support for XML file formats and the ability to shave an enraged badger. After serious consideration, I decide to defer the bug for next time.

7:02pm – Receive call from marketing demanding to know why XML files/badger-shaving feature was deferred. They cite numerous customer anecdotes in which they needed the portability of an XML file combined with the ability to shave an angry badger. Most cases involve alcohol, in which the badger had consumed prodigious amounts.

7:30pm – Look at code for the first time today.

7:47pm – Marketing calls back saying what the customer probably, really, honestly, truly needed was a way sober up the badger. They swear the badger is a nice guy, but only acts that way when he’s drunk. Plus he has a bad 5 o’clock shadow.

8pm – Receive call from potential client, asking if we could port his Word processor for Windows to the Mac for twenty nine cents and a large portion on his company’s stock, currently held in a gum-ball machine.

8:28pm – Starving, I crawl to the refrigerator, where I discover a veritable treasure trove of food, in the form of Cheerios, underneath the fridge.

9:02pm – Realizing I am spending too much time reading Digg and Slashdot, I go read Dilbert, Get Fuzzy, and Pearls before Swine.

9:18pm – Return to code and marvel at the fact the compiler has not openly mocked the code in iambic pentameter or simply refused to compile it out of principle.

10:07pm – Digg and Slashdot.

10:41pm – iChat with business parter in which we ridicule Xcode’s speed, code quality, and inability to shave an enraged badger who’s had a few too many drinks.

11:11pm – Notice that the auto-complete in Xcode is actually recommending other, more reputable companies I could be working for.

11:38pm – Digg.

12:06pm – Slashdot.

12:49am – Change egregious code “if ( foo ) doFoo();” to the much more sane “if ( foo ) { doFoo(); }”, on the initial thought that I get paid by the character.

1:22am – Discover the entire Xcode help file is one page that recommends using a better IDE, such as MPW.

1:30am – Change the completely erroneous “if ( foo ) { doFoo(); }” to the actually readable “if (foo) {doFoo();}”. Note the bytes saved by the removed whitespace on my accomplishments.

1:40am – In an attempt to find a snippet of code in my project, Xcode inadvertently finds life on Mars. Still unable to search an arbitrary directory in less than ten steps.

1:44am – Change “if (foo) {doFoo();}” to “if ( foo ) doFoo();”, and wonder what fool added the unnecessary braces and removed the spaces.

1:54am – Against doctor’s orders, read old copies of Inside Macintosh, Volume 1 until I fall asleep. He recommended a large mallet to the head, for the reason that it is less likely to cause severe brain trauma.

As you can see, the life of an independent software engineer is not for the faint of heart. No doubt you have more respect for me now than you have ever had before.