Product updates, news & miscellanea from your fellow Apollo developers.
This blog has moved! Head to the Building Apollo blog »
As many of our customers know, we are getting ready to release our "paid plans". While this is exciting, as we will finally earn money with Apollo, there is always the other side of the coin: organising a good, reliable, convenient merchant account. This involves, amongst other things, to fill out a staggering number of forms.
At the beginning, it was project management: it was basically a science, with its own specialised vocabulary and wide range of software options to actually apply that science. This science included contracts, budgeting, very refined task, sub task, sub-sub task breakdown, dependencies, complex graphs, time estimates, etc. A few people, the "project managers", were masters at finding their way in this little jungle of terms, rules, and methods.
Get some scales. Now, measure how much 700 sheets of paper weigh. That's quite a bit. Now put a lighter next to them. Let the flame touch the paper. Once the fire brigades are finished with your house, come back here and read the rest of this long chapter. Get some scales. Now, measure how much 500Mb weigh. That's hardly anything, especially if they are on a USB key. Now, put a lighter next to those 500Mb. It probably won't catch fire. The good news is that your house is safe.
If you like Zen meditation, manual invoicing is for you. You need to first write an invoice manually. That's by pen, or with Microsoft Word -- whatever. Well, three copies of it: one for the customer, one for yourself (to be stacked in the "unpaid invoices" folder), and one for the archive. Then you need to do your double-entry bookkeeping of this invoice, in the receivable account. Every day, you can go even deeper into your meditation while to go through the stack of unpaid invoices, and call customers to remind them.
This is possibly the most important rule for a reason: break it, and you will fail. A 50% partner will give you a 98.8% failure rate. Having two bosses running a company together is like having two heterosexual pilots in one Formula 1 racing car: at the beginning they might enjoy the mad ride, but eventually they will hate each other's smell, sweat and breath. There is a reason why big companies, when the current CEO resigns, hire one new CEO and not two. There is a reason why there is one commander in an army.
Imagine that you sell product X. X here could be anything: to me, right now, X is Apollo, a piece of project management software that allows you to manage and organise your working and personal life. But that's just an example -- you could be selling cakes. After a while, and a lot of hard work, you become popular: people buy your cakes (and my software), and things are cruising along nicely. As you become more and more renowned, your customers start coming up with more specific requests.
We woke up this morning in a bit of a situation. We opened up our company inbox, and discovered some 140 emails waiting to be answered: they were invite requests.
We decided to start as "invite only" mainly because we wanted to establish a 1:1 connection with our users. That's also why we asked you to actually send us an email, rather than filling in a form with your email address: we wanted to see how you would ask for an invite, have a look at your company's website and blog, and possibly start a conversation with you.
Some people just seem to get a lot done: some of them might works two jobs, and yet has time for his family and -- yes -- for a social life -- never looking stressed in the meantime. Are they super-humans? No, they are simply people who know that it's not how much you work that counts, but how you do it.
The basic rules are very simple and yet seem so hard to apply:
The title of this blog entry is obviously sarcastic: we released Apollo at the end of July, and enjoyed talking to our early users. Since launching Apollo, we have received a lot of positive feedback, and... no negative comments. People told us about missing features they were missing, but that's been it: nobody ever said that Apollo was bad in any way. In fact, nobody said anything bad about it!
Then we decided that it was time to enter some software awards.
Imagine for a second that you just developed a piece of software that works online. Let's pick a random category: project management. In 2009-2010, you probably spent countless hours creating something very dynamic, with some 45000 lines of snappy Javascript. You then decide to make your application available to mobile devices. The question is: do you develop N native applications for N mobile platforms? Or do you develop one online application that works everywhere?
