Making it easy for people to try your software

October 15th, 2007

I suspect that a great deal of the success of web-based applications is that it’s easy to try them. All you have to do is go to the website; no installing things, no dependencies, no virus scanners, no saving files. There are very low barriers to entry; there’s very little friction.

Personally, I find most web-based applications to be absolutely awful to use. Every UI is different. There aren’t any keyboard shortcuts. I like to have control over my data, and I like to be able to work offline.

For most people, these aren’t major problems. Witness the almost complete domination of webmail over traditional desktop email programs. Given that an ‘ordinary user’ doesn’t have a very reliable computer or backups, keeping all of your email online overseas is probably not a big problem. They’re going online to read email anyway, so it might as well live online.

Imagine, for a moment, the last time you installed some software on your computer. The last installation I did on Windows was the Symbian SDK. I had to choose between a number of download options, download a few hundred megabytes of files, do the installation, consult Google to find out why it wouldn’t work after being installed, go and download some dependencies, install them, blah blah blah blee blee blah blah.

The last installation I did on Linux was FlightGear, a flight simulator. I fired up aptitude, selected the flightgear package and told it to install. There was still a long wait for the download (also a few hundred megabytes) but all of the dependencies and installation happened automatically. The actual time I spent performing the installation was quite small; I just went on with other tasks while it happened. This is a much better situation.

The next best thing for Windows is usually to download a zip file which uncompresses and runs from the folder - it doesn’t have an install program. These programs also run nicely off thumb drives if you’re into that. I like these as a developer - writing and testing install programs is a royal pain in the behind.

Better still would be to just download an executable and run that. Fog Creek Copilot does this for their user agent. It even deletes itself when it’s done, which is extremely considerate. If you’ve got a program with lots of files - like the Python apps I’m planning to distribute - you could have it extract to a temporary directory and execute from there.

Can a desktop app get any easier? An even easier situation might be to click a link on a website and have the program fire up on your desktop. Java Web Start has the right idea, but the implementation is sloppy. The idea is that you click the magic JWS button on a website and the program is downloaded without your knowledge and executed on your computer. Great. You do a caching scheme so you don’t have to download repeatedly; you can set up a Start/GNOME/K/whatever menu item so people can come back later.

Thinking about this last option against a web application, the web application still seems smoother. I think it’s the download time. There’s also the scary “do you want to download this executable” box which most people see but click through anyway. The webapp still feels like it has less friction. The desktop app has a large ’speed bump’ where you have to wait for a download, and during that you start thinking about other things or mentally task switch. You have to think about where you’re going to store the file and do I have to uncompress it and does it have any viruses and how am I going to arrange the windows. The web app is just another tab, and even if I task switch away, it’s just there waiting. Web apps are fairly predictable, even if they are a bit boring at times.

Experimenting with Symbian development

October 14th, 2007

I started playing with the Symbian SDK and Carbide (the IDE) today. Project Two is probably going to be a working time tracker for Symbian. Again, it’s something that I’d use a lot myself. I have a working time tracker already, but it’s very buggy and doesn’t have a lot in the way of features. I want things like automated reporting and multiple clients/projects.

Nokia have done a damn good job with their dev tools. They’re making them easy to get, they’re very well documented and there’s a lot of effort put towards creating a community of developers. Compare with Apple and the iPhone where they are actively discouraging third-party development and people are desperate to develop for the thing anyway. Nokia are doing a great job here and I have to applaud them for it.

I skimmed through one of the tutorials in the Carbide documentation; it’s a basic ‘Hello World’ application. The tutorial takes you through setting up the application, building, running in an emulator and running on the device. The emulator is superb; it looks and acts like an S60v3 phone. It hooks into the Windows TCP/IP stack so you can test networked applications. You can rotate and resize the screen to test the different combinations of physical displays. You can hook it up to a nice IDE-based debugger if you need to get down and dirty with the code. All great stuff.

Hello World on Symbian

You need to pay for the Developer edition of Carbide if you want to do on-device debugging. There’s a free trial. Carbide is Eclipse-based, but I didn’t even realise that I was using a Java application until I started digging around the libraries and discovered that there were Java-style namespaces. There’s an Express edition of Carbide, and it’s fine to use that for commercial development.

There are a few little problems. Something in the build configuration doesn’t handle spaces in paths, so you have to create your project out of the usual Documents and Settings hierarchy. The Symbian and Carbide files are swimming with case-sensitivity issues, but that’s not a problem if you’re on NTFS. Linux support does seem to be fairly good, though.

When it comes time to generate an SIS file so you can install on the phone, the build fails (missing HelloWorld_reg.rsc, but I can see it just fine). I fixed this by creating a new build configuration that duplicated the default Debug settings. I’m not sure why this made a difference.

Modelling projected income, part two

October 11th, 2007

Things change dramatically once you retire. First, your net worth on a salary:

Then, when you own a royalty-generating business:

In reality the scale is everything, but the point remains. With the business, you keep earning money even in retirement. On the salary, you’ve just jumped out of the plane - you need to have enough cash to support yourself until you die.

If you’re thinking about this, I strongly recommend making a spreadsheet so that you can stick in your own figures (expected investment return, salary growth, retirement year, etc) and see just how your financial situation will look in various points of your life. You’ll make horrible assumptions, but you’ll learn a lot.

Click here to download the spreadsheet I used. It’s set up to make the graphs look pretty rather than realistic, but the basic idea is sound. Put your own numbers in and see what happens.

Modelling projected income

October 11th, 2007

In deciding whether to concentrate on full-time work or business-building, I think a lot about the different characteristics of the income received.

Full-time work is typically a constant $N/year. You (hopefully) receive a payrise each year. I’m going to assume 5%/year is a sustainable increase over the course of a lifetime. You put the difference between your income and expenses into investments (equity), which I’m going to assume earn 7%/year. Your net worth over time will look something like this:

Modelled salary net worth

Business-building - specifically, software, music, writing or other royalty-based media production - has different characteristics. In year 1, you are going to have fairly low income. You’ll do some piece of work and it will earn income on its own. This is passive income at this point - you don’t need to do any additional work to maintain that income. Then, in year 2, you’re free to do another piece of work - adding to your passive income. Lather, rinse, repeat. Your net worth will look more like this:

Modelled business net worth

The question for any rational person is over the course of my lifetime, which is going to give me a higher net worth? And that’s a difficult question to answer early on. You’ve got steady but rapid growth versus exponential growth - but that growth factor is unpredictable.

This is the sort of bank balance that a startup company might see as well. There are two critical measures to take off this graph: how far into the red does the company go, and is that growth rate sufficient to make it a worthwhile investment? Many startups never even hit positive growth and will just run out of cash. Someone said that starting a startup was like jumping out of a plane; the ground seems like a long way off, but you’re falling very fast as well, and the question is whether or not you can pull out of the fall in time.

In the same way, my savings are my investment. If I run out of cash, I have to stop. I need to build income before I run out of savings. I don’t particularly want to risk all of my savings on this one venture, which is why I’ve set a one year time limit. If I’m still plummetting towards bankruptcy at the end of the year, I need to reconsider what I’m doing and if it’ll be effective. (Realistically, I’ll be watching this all of the time. One year is the big yay-or-nay decision, though).

If you need to borrow to get capital investment, this is going to make your profitability a whole lot tougher. You need to match your loan rate just to break even, as I found while playing with the spreadsheet model I used for the above graphs. Just as compounding looks like a lovely exponential growth curve, it can drag you into a horrible pit of debt very quickly.

Individual preferences are obviously going to play a big part in this decision as well. If you like to live close to your means and enjoy your money, you’re going to want the ongoing income. If you have dependents or medical bills, you need the constant income. I’m have no dependents and am happy to live a fairly lean existence, so I can choose to take this risk.

An interesting point that I read about today was that most micro-ISVs can’t keep building income forever. The income is not truly passive. Support is a big time sink, and the amount of support increases with the number of users. If you’re earning enough you can hire more people to take over this load - but this is the sort of problem that I’d like to have. If I get there, I won’t be complaining.

Playing with the spreadsheet model is highly educational: using the assumption that salary grows at 5% means that your income under a business also has to grow at at least 5% for it to be worthwhile. If you’re increasing your income by a constant amount each year, this is going to be easy to beat in the beginning and rapidly become impossible.

But, wait - there’s more! Part Two will discuss the two strategies once you retire.

More on paid work versus building a business

October 11th, 2007

In the short term, paid work is vastly more profitable. Even though I work as a contractor, not a salaried employee, paid work is far more predictable, reliable and profitable in the short term.

This raises the question: if my goal is to earn passive income, I have two major options. I could work and earn $N/year plus 0.07 x $N/year in passive income after that (ignoring compounding and expenses). Or I could build this business and start from zero income and slowly build it up - but it’s all ‘passive’ income.

There are almost no sources of income that are truly passive. Even leaving cash in a bank account requires some paperwork and monitoring. It’s a very small amount of work, but it is finite. Another way to look at this might be to compare hourly rates. Increasing the hourly rate is obviously good - you earn more money for the same work, or earn the same money for less work. So ‘passive income’ streams are essentially trying to build income streams that require very little work for a large income - they have a very good $/hour rate. A ten-year property or index fund investment might be worth tens of thousands of dollars per hour. This ignores the fact that you’re very limited in the number of hours that you can do, but it doesn’t matter so much - even if the number of hours is limited, it’s still worthwhile to take them and spend the rest of your time on the most profitable work available.

So by starting this company, I’m acknowledging that my initial per-hour rate is going to be terrible. I’ll be losing small amounts of cash in the beginning, in fact - as cheap as it is to start a software company right now, I’ve spent about USD$20 on this domain name and that puts me into the red. The idea is that over a longer time period I won’t have to put in so much effort to maintain the same income level, and so my effective per-hour rate will rise above that which I could get by working a standard job.

Product One: A software developer’s task planner

October 11th, 2007

Product One is a hierarchical todo list. I can say this with confidence now because it’s almost ready for an initial release without starting ‘the year’. I needed a task tracker that would run on Linux. I was using AbstractSpoon’s ToDoList for years, but it’s a Windows application and runs poorly on Linux.

I can hear it already: “but how are you going to make money off a Linux application?” Popularity is the goal, not profits. Build something that people want, and the money will follow. This is also great for cutting down the project risk: if it turns out that no-one else is interested, fine, I won’t spend a lot of time developing it. If people do like it, then they can tell me what they want to see and I can come up with a monetization plan from there.

Besides, it’s cross-platform, not just Linux. wxWidgets on Python. sqlite backend. One of the quickest things I’ve ever developed to a usable state, if I do say so myself.

There’s a lot of todo lists out there, so future development will be more focused. I’m calling this a software developer’s task planner for a few reasons. One is that a hierarchy and project management system is too complicated for most people. They don’t have that many things to track and will do just fine with Outlook’s task manager or Post-It notes on their monitor.

That won’t do it for me. The difficulty for me is stemming the tide of tasks that need to be done. I notice a bug: I write it down and continue doing what I was doing. I have an idea in the shower: I write it down. Someone makes a suggestion: I write it down. I get stuck on a task: I divide it up and write it down. Some of my lists have thousands of entries. Outlook isn’t going to cut it.

By concentrating on software developers, I gain in a few ways. I’m a developer myself, so what’s useful to me is likely to be useful to others. I can introduce more complicated concepts like hierarchies without overcomplicating the product. I can focus my marketing efforts. I can specialize the product towards the target audience. This is basic Crossing The Chasm: you pick a niche and push hard until you completely own it. ‘Software Developers’ is a pretty wide niche, admittedly, but I can always revise that.

Marketing

October 11th, 2007

Marketing is simultaneously my weakest point and one of the most important things for me to get right.

No-one is going to pay for anything if they don’t know it’s there. You could have a cure for cancer, but if no-one knew it existed, it wouldn’t mean anything. (Obviously, once the first person found out they’d likely tell others, but this is an extreme case of ‘product good but marketing bad’).

Conversely, you can have an average or even mediocre product with strong marketing and end up doing very well. Apple zealots get ready: I believe that a lot of Apple’s products fit into this category. They spend great amounts of money and have very effective marketing, but I must say: I find their products lacking. There are always better alternatives. The problem is finding them. And given that people are likely to go with social proof (see Influence by Cialdini) and the fact that Apple’s products are quite good, Apple do very well overall. But there are better products out there.

I’m a software engineer, not a marketeer (Musketeer? What do you call a ‘marketing person’?) I’m going to need to learn some marketing. My first little blog - mouldy.org - taught me an awful lot about online marketing, what works and what doesn’t. But this is going to need a long-term, concerted effort, not just spreading a few links around.

Outcomes

October 11th, 2007

I can imagine a few different outcomes at the end of the year.

  • I build some products, but they don’t get any interest or traffic. I’ll have to get a job and will be out a year’s earnings plus the money I spend along the way. This is the worst-case scenario, but I don’t think it’s terribly likely.
  • I build some products and they get a little interest, but not enough to build up enough income to live off. This is OK with me, oddly enough. Any income is a sign that I’m doing something right. I’d still have to get a job, but I will have learnt a lot and have some passive income going. So this isn’t a bad outcome.
  • I build some products and I earn enough to sustain myself. This is fine. It’s not spectacular. A few years from now, I’d like to be earning a whole lot more than I am now - but I don’t have huge expectations in that respect. More important is that I can choose where and when and how I work, even if it means I don’t earn so much. If I do need extra income, I can always get a job.
  • One or more of my products is a massive hit and I become rich. Woohoo! Not terribly likely, but I’m not going to complain.
  • I have poor results after the first few months, get discouraged and quit. Since the alternative is that I get a job, I don’t consider that too likely. But it is possible. Maybe a job will seem appealing after that long without income or human contact.

So I guess, the worst thing that can happen is that I lose some cash and have to get a job. I don’t particularly like jobs, but it’s not the end of the world.

Chances are, I’ll still have some part-time work while I’m building these products anyway. Even right now - before I officially start - I’m dividing my time between a (nominally) full-time job and some product development. At the moment it’s about four days/week on the ‘day job’ and one or two days on product development. And that’s OK. I see regular progress, and that’s encouraging. I’d like to be making faster progress, but anything is OK.

Six products? In a year?

October 11th, 2007

Yup. Aggressive schedule. More importantly, I won’t be taking on huge projects and then finding that there’s no demand. What I want to build is strongly influenced by what I will use and what I like, and there’s not always going to be a correlation between that and what other people will use and pay for. The idea is to build some things and find out what other people like, then concentrate my efforts on the most popular (and subsequently profitable) projects.

I use the word ‘product’ to mean more than just a piece of software. It’s the software and the documentation and the FAQs and the marketing collateral and the monetization. Which, when you think about it, doesn’t leave a lot of time to write software. Y Combinator gets three months, there are four of them, and they’re sprinting. I’m one man with two months and I don’t know much about marketing.

Nevertheless, I remain confident that this is a sustainable schedule - at least for the first few products. If one of my early products becomes popular, it’ll probably delay the later ones. Which isn’t a bad thing - one of my products will be popular!

The idea is that when something is popular, I spend more time on it. Popularity is easy to translate to money - pay-per-click advertising is the most obvious way. There’s also paid services, consulting, customization, support, feature development and good old-fashioned networking. Getting attention is the trick. There are billions of other web pages out there, and I need to attract attention to mine. I’ll be thinking about marketing a great deal.

There’s also a discrepancy between working time and wall-clock time. While I really, really want that ‘one year’ to be real (wall-clock) time - it’s not going to work out that way. I’m full-time employed right now and don’t know when I’ll be leaving that. I’ve got two holidays and an interstate move planned. The year will have some major disruptions to it. I also plan to keep working for other people a little during the year.

Still, I think one year real time is the best way to measure this, if only because it’ll cut down on me slacking off because “that day I spent watching TV, it didn’t count anyway”. The days all count. Some of them are going to be disrupted.

When ‘the year’ begins is still uncertain. Most likely it’ll be when I reduce my work commitments to two days/week or less. This still leaves me a pretty reasonable yearly income and is comfortably above my expenses.

Why software?

October 11th, 2007

Because software is what I know

I’ve been writing software since I was five years old. Not to a particularly high standard back then, of course, but I’ve more or less devoted all of my study and work efforts to it.

Because I enjoy writing software

I don’t consider it a wage-slave job. It’s something that I can apply passion to. I don’t just do my eight hours and go home; I think about it a lot and wake up in the middle of the night when I have a great idea. It’s more than just a job.

Because I have significant competitive advantages in the software world

I’m 25 years old. I have no major ties in any particular place; no children or dependents; no requirement for a steady income. I can spend long hours at this, and I have the energy and naiivety to this it’s a good idea. I’m not completely burned on the idea of writing software for a living.

Because the barriers to entry to start a software company are almost nil

I have a computer, a high-speed Internet connection and a brain. Mix them together, bake at 300 degrees for a few months, and a software company will drop out.