1. Play-By-Play: Revenue Model

    May 22, 2010 by Craig

    As I mentioned in the last post, almost all of the competitors are one-time purchases. I however am leaning strongly towards a pay-as-you-go model, probably on a monthly basis. This has some major advantages for the customer and for the seller (me):

    • The customer can start using the software without a major outlay of cash. (A startup already has plenty of initial major outlays, especially in equipment-heavy industries like a bakery.) This in turn is good for the seller as it gets customers in the door earlier. The key is to engage the customer as early and as easily as possible.
    • There’s much less risk to the customer. If they do not want to use the software any more, they simply do not pay. All they’ve lost is their current fees, which are bound to be much less than a one-time purchase price. Less risk means easier engagement and more sales.
    • It’s easier for the seller to offer free trials when there’s a recurring fee — basically, the seller just has to “not recur” the fee for a period of time. Again, this reduces customer risk and thus increases sales.
    • Both the customer and the seller can easily distribute the cost/income over time. For the customer, that means matching the cost of the software directly against sales for the subscription period — making the cost/benefit that much easier to calculate. For the seller, it means easier/smoother projection of sales.

    On the other hand, my domain expert did say that it might be tough to sell a recurring-fee service to companies; she thought they’d prefer to buy it outright. It’s true that, over time, a single purchase could be cheaper than a monthly fee. Divide the purchase cost by the monthly fee and you have a “payoff period”, after which the one-time purchase price is cheaper. There’s several problems with this though:

    • The customer must remains in business for the entire payoff period for the one-time purchase to be cheaper. Depending on the pricing, that could be several years.
    • The customer must be getting benefit from the software for the entire payoff period. There’s no refunds if it stops working or gathers dust.
    • A lot of “one-time-purchase” software does, in fact, have ongoing charges. They usually take the form of “maintenance contracts”, support contracts, or additional fees for upgrades and bug fixes. The customer may be able to go without, but this often reduces the usability of the software.
    • The customer must factor in the opportunity cost of the money that they don’t spend up front.
    • The customer and/or their accountant must know how to properly amortize the price of the software for taxes. This isn’t terribly hard, but it is a bit esoteric, and it requires some planning for the future. I won’t go into details here (unless someone asks), but by and large it’s simpler and potentially more beneficial to write off a monthly fee rather than a one-time purchase.

    The revenue model has a fair amount of influence on the technical architecture, which is what I’ll discuss next.

  2. BlackBerry Apps: Looking for a Developer

    May 19, 2010 by Craig

    A potential client just approached me with an idea for a BlackBerry application. The application itself is pretty simple; the business logic is already vetted and the UI requirements aren’t complicated. However, I’m not familiar with J2ME and BlackBerry development (though I have been doing Java for years). That means my personal learning curve would put a relatively heavy burden on this project. Instead, I’d like to find someone already doing BB development and farm at least some of the work out to them.

    If you’re interested, please contact me and we’ll start talking about the details.

  3. Play-By-Play: Business Analysis Update

    May 18, 2010 by Craig

    I just got some responses to my market questions from my domain expert.

    I’m debating whether to post the raw numbers here. This sort of research is generally considered an important competitive advantage, and thus should be private. On the other hand… I didn’t really do much (besides ask a baker), and so anyone who wants to compete should be able to go out and find similar results. Furthermore: my competitive advantage will be on the implementation side, not the market analysis side.

    Still, it’s not terribly harmful to withhold publishing these numbers to the general Internet. The only thing I really lose is the credibility boost from showing my analysis process.

    So, for now, I’ll keep the numbers to myself… but if you’d like to see them and you can convince me that you’re not going to pull the rug out from under me, give me a shout and I’ll share the inside scoop with you.

    I will say this though: the numbers look far better than I was originally expecting. Even at the conservative end of my ranges, the expected value-to-customer (and thus sales price) is about 5 times what I had guessed.

    That makes me feel a lot better about taking on this project. It should be well worth the effort I’ll put in.

  4. Play-by-Play: Getting Customers

    May 16, 2010 by Craig

    This is a continuation of my previous post.

    Conversion Rate

    Here be dragons. I’ve yet to see anyone come up with reliable predictions or techniques to make a paying customer out of a potential one. In fact, a lot of what I’ve read suggests that you should not even try to estimate or manipulate this figure until you’re already in business and have some existing data to work from. Until you have real numbers, it’s all guesswork.

    The good news is that the number may be even better than you think. There have been lots of runaway successes in the Internet age. Also, this is where all of the upside comes from once you’ve built the business. Today’s battle plan is to launch the business and then use real-world experience to increase this number.

    I think that the best thing you can do at this stage in the came is to make a good, solid product that evolves to meet customer needs. The conversion rate will be evidence of that.

    Value to the Customer

    I don’t have numbers for this yet but I do know what information I want:

    • How many different products does a bakery make at a given time?
    • How many units of each product does a bakery produce in a given time period?
    • How many units does the bakery sell? The difference between this and the production number equals the waste.
    • How much on ingredients does the bakery spend? Multiply this by the waste percentage to find out the potential for waste reduction.
    • How much waste could be eliminated through better planning (via this software)? The goal is 100% but that’s probably unrealistic.

    These are the numbers to research.

    Multiply the waste reduction by the ingredient cost and you have the maximum value to the customer. Reduce that by some factor to account for inefficiency in the process. (For example: it will take some time to use the software, and that time amounts to a reduction the customer’s net value from the product).

    The price of the product must be below this number.


    A big factor in the conversion rate is the value of other players aiming for the same market. One of the reasons I was approached in the first place is that there wasn’t a lot of suitable existing products for my domain expert/first customer. The products that are out there are often:

    • Expensive. There’s one for about $250 (outright purchase), but the more common price points are $700, $1200, and $2500. That’s fairly daunting up-front cost for a small bakery who is not sure of the overall benefit.
    • Hard to use and learn. In my initial discussion, the phrase “something simple to use” came up more than once.
    • Desktop software, meaning that they need to be installed and maintained on-site. That’s not great for a business with small to none in-house expertise.
    • Have limited or no trial options before purchase. Even when there is a trial option, you have to download & install it: it’s not very smooth.
    • Ugly, both in the program itself and in the company website. Ugly suggests shoddy.

    These are all vectors that I can take advantage of.

    The whole point to getting customers, of course, is to get money from them, which will be my next post in this series.

  5. Play-By-Play: Business Analysis

    May 13, 2010 by Craig

    So, we have the problem defined and have estimated that the project is a good one to do — if its profitable. So how successful will it be as a business? Nobody can reliably predict the future, but we can take a shot at it and see what we learn along the way.

    The Fundamental Equations

    • Profit = Revenue (Income) – Expenses
    • Profit also = ( Margin * Number of Sales ) – Fixed Costs
    • Revenue = (generally) Number of Sales * Sales Price
    • Margin = Sales Price – Cost
    • Cost = What you make of it
    • Sales Price < Min( Value to the customer, Price of competitors with same value)
    • Number of Sales = Number of potential customers * Conversion Rate

    So let’s try to fill in some of these numbers.

    Number of Potential Customers

    The target audience for the immediate problem is bakeries that are having problems understanding and managing the costs of their ingredients. This suggests that they’re small bakeries with limited numbers of employees who would rather be baking than crunching numbers.

    In Canada (as of 2001) there were 1,779 bakery establishments. I have one source that says there were 24,189 bakeries in the U.S. Europe and Latin America are potentially two good areas to find customers, but for now I’m going to concentrate on North America.

    As of now, there are several unknowns that prevent me from calculating potential customer base:

    • How many bakeries have this particular problem of cost management? I’m assuming that large ones already have systems in place to do this, and so are not potential customers. However, my Domain Expert (the friend who wants this application) says that it’s a large number of the smaller bakeries. She’s been an instructor in the industry for quite a while so I’ll have to defer to her statement for now.
    • How many bakeries with this problem would be willing to use software (of any sort) to solve this problem? There’s some logistical problems here: namely that the people involved have to be willing and able to use a computer during their business operations. My Domain Expert says that this isn’t much of a problem; computers are integral for these types of business anyway.
    • How many bakeries willing to use software would be willing to pay for it, at any price? You’d think that this would be “all of then”, and it should be if the software solves their problem, but some people seem to resist any sort of cash outlay they consider “unnecessary.” Hopefully this is a small factor.

    It’s very easy to fall into the “All we need is X% of the total market to make $Y” trap. Usually this arises from someone coming up with a goal value for Y, deriving an X that amounts to a “small” value, and then assuming that X will be easy to achieve. But that’s not how business actually works: X is the independent variable here and it’s the one that you have to focus on; Y is a consequence of that.

    More To Come

    I want to keep these posts relatively short, so I’m cutting my analysis off here and saving the rest for another post.

    Update: Some Numbers

    I got some answers to my questions after I wrote this.

  6. Play-By-Play: Personal Cost/Benefit Analysis

    May 10, 2010 by Craig

    There is an infinite stream of problems to solve. However, finding one that’s worth working on is another matter entirely. Nothing comes for free, so we have to pick and choose what we focus on. Here’s some of the questions that I’ve asked during the course of my investigation.

    The Ultimate Question: Should I Build This?

    Q: Is this particular project worth my investment in time, effort, and money?

    “Ultimate” has two connotations: last and most important. This question fits both of those; not only does it override everything else, but it’s only answerable after you resolve all of the underlying questions. However, it’s easy to lose sight of goals, so it needs to be asked first. This is where we can apply a fringe benefit of being a programmer: we’ll push it onto the stack and come back with an answer later. Asking this first gets us started though: it forces us to ask “How do we answer this particular question?”.


    Q: What do I get by working on this project?

    Here’s my answers thusfar:

    • Potential for profit. At first glance, this product looks like it should be able to make some money. More investigation needed here.
    • Potential for huge profit. Actually, the chances of striking it rich selling to small bakeries seems pretty small. But stranger things have happened. This is a very minor (i.e.: unlikely) benefit but it’s nonzero.
    • Potential for profit without spending lots of ongoing time. Everyone is limited in the amount of time they can spend on any given task. When you are directly converting time into money (which I do as a consultant) there’s a hard upper limit to the amount of money you can earn; all of your growth must come from increasing your per-hour rate, and eventually that will max out. Selling a product like this can circumvent that limit; the amount of money earned relates to the number of people who buy your product. This is potentially a much deeper pool than time. (Fun facts: there’s roughly 94,000 working hours in a lifetime, but 7 billion people on the planet right now.) See also: revenue per employee.
    • Opportunity to learn new technologies. I can read all I want, but to actually know something I have to do something with it. Real-world projects give me the chance to solve real-world problems and get practical experience.
    • Practice at building a business. Same as above, but outside of the technical realm.
    • Helping a friend. Never a bad thing.
    • Exposure to a new industry. New stuff to learn. New people to meet. New opportunities. One more basket in which to put eggs.
    • Credibility and Reputation. I can say “I did this.” It’s action, and not just talk.
    • Exposure. It’s good stuff to write about, and may get some good attention.
    • Enjoyment. Building new stuff is fun. Having the results is fun. Making decisions is fun.


    Q: What do I give by working on this project?

    • Time. This will necessarily take away from other things I could be doing. Here’s a few: spending time with wife, family &amp friends, hobbies (photography, gaming, hiking), exercise.
    • Opportunity Cost. Pretty much the same as “time”, but with a money angle to it. The time I spend on this project means that I’m not working on other projects I have on the backburner. The question becomes: which project has more benefits/profit potential? I think that this one is reasonably good.
    • Ability to start a new project. Very similar to “opportunity cost” but specifically focused on an unknown future project that has a greater net reward. I don’t like starting projects that I don’t finish (though that happens far too often). This is more applicable to this project since it involves a friend.
    • Effort. Building stuff often drains my personal energy, leaving less for other stuff. (See “Time”; it’s very closely related.)
    • Money. This project should be pretty cheap in terms of actual cash outlay, but there may be some costs ahead of revenue. Right now I see graphic design and some hosting setup costs.
    • Credibility and Reputation. There’s a downside here too. I’m not too worried about the fallout from the business failing, but there is potential for bad decisions and actions to negatively impact me.


    A lot of this is incalculable, and thus hard to analyze. However, the costs seem to be quite manageable. Time is the biggest one, but it has to be spent somehow, and I think that investing it in something with a payout potential is worthwhile. There are some guaranteed intangible benefits.

    As usual, the deciding factor is profitability, which is the next thing I’ll look at.

  7. Play-By-Play: The Problem

    May 8, 2010 by Craig

    Pretty much all software is intended to solve a problem of some sort. The “problem” simply be “I want to be entertained”, but for “business” software it’s usually more specific. Ideally it’s tied to a profit-generating function. You’ll sometimes hear them referred to as “pain points”, “challenges”, “requirements”, or “opportunities”; they’re all really the same thing.

    A few weeks ago I was approached by one of my wife’s friends. She’s opening a bakery here in Calgary and asked if I would be interested in creating some software for her. We met, discussed her needs, and I got a bit of understanding about her industry. From this I derived the major problem that I’ll focus on for the first round of development:

    To be successful, low-volume / boutique bakers need to keep good control of their materials costs. However, it is difficult for them to do so, and so many do not.

    This manifests itself in two ways:

    1. Recipes are written to produce X number of finished units for Y ingredients. The bakery will require X*Z finished units per day, and so much put in Y*Z ingredients. However, if Z is not the values 2, 4, or 10, then calculating X*Z and Y*Z becomes relatively difficult and cumbersome. (The situation is made worse if you’re using non-metric units of measurement.) Instead, many bakers simply round up to the nearest easily-calculable value of Z, resulting in a lot of waste and expense.
    2. To determine the per-unit cost of a product, you need to take:

      • The price of one purchasable container of each of your ingredients,
      • Divide that by the number of measured units in the container
      • Multiply that by the amount of ingredient in the recipe
      • Adjust (add) for waste and other miscellaneous uses
      • Repeat the above for every ingredient in the recipe
      • Sum the results for each ingredient together
      • Divide by the number of units in the recipe

      Repeat this process for every product sold (or potentially sold) in the business. Again, all this hoop-jumping means that bakers tend to not do this, and thus do not understand the costs of their products. Without knowing costs, you can’t know margin, profitability, efficiency, value, and opportunity.

    Basically, the problem is one of mental math. Humans suck at it. Worse, they are often afraid of it, and so will go to lengths to avoid it. On the other hand, it’s basically the only thing that computers do, and they do it faster, cheaper, and more accurately than a human ever can.

    This problem is well-suited to a technical solution: not only does it bridge a gap in human capability, but it’s one that’s extremely easy to build. (I basically just outlined the algorithm above). That means that it can be done without too much up-front investment in time and money. That’s important for determining whether it will make a viable business.

  8. Play-By-Play: Building an Application

    May 6, 2010 by Craig

    In addition to my “day job” as a software development consultant, I’m also evolving into a software entrepreneur. I want to sell products and not just my time. Over the past few years I’ve seen a lot of people accomplish the same dream (most famously the inspiring guys at 37signals). I’m going to try my hand at the same.

    In concert with this, I’m going to document my development process, tasks, and ideas. I’m doing this for several reasons:

    • To potentially inspire and instruct others to do likewise.
    • To perhaps get some feedback from the development community.
    • To document my processes for my own reference, benefit, and reflection.
    • To build my cred by illustrating my thoughts and capabilities. (Better to show than simply to claim.)

    I hope to go into a fair amount of detail — hence the “Play-By-Play” tag and title I’ll be applying to each of my posts. Please comment freely and enjoy!

  9. What Makes a Successful IT Team Leader?

    November 10, 2009 by Craig

    I was just asked to give my top 5 qualities that I’d like to see in an IT Team Leader. Here’s what I came up with, in order of preference:

    1. Dedication to excellence in communication: honesty, clarity, transparency, approachability, willingness to listen to the people closest to the problem at hand.
    2. Ability to convince upper management of the realities on the current business & IT environment and the necessary steps for IT to help achieve business goals.
    3. Familiarity and/or experience with strategies that make a successful IT department.
      1. One of the ways to demonstrate this familiarity is to have read & be able to discuss some of the excellent and important books on the subject: Peopleware, The Mythical Man-Month, The Inmates are Running the Asylum, Facts and Fallacies of Software Engineering. There are many others. I expect an IT team leader to have read and understand at least two of them.
    4. Ability and drive to eliminate obstacles to the productivity of the IT team: a problem-solver.
    5. Practical experience with technology and/or software development.

  10. Wikipedia Tourism #23

    November 5, 2009 by Craig

    They also want to visit the UK, so they can both have a chance to use their opposite controls.

    From Abigail and Brittany Hensel, conjoined twins who together are able to drive.