Product updates, news & miscellanea from your fellow Apollo developers.
This blog has moved! Head to the Building Apollo blog »
Hello friends! It's now possible, in Apollo, to place a project "on hold". A project on hold is still accessible to your users. However, the project's feed will not be updated; plus, upcoming tasks and milestones will not show up in the overview, in the "my tasks" area and in the calendar. Basically, the project will stay "silent".
Keep in mind that a project "on hold" is still considered active.
Hello friends!
With Apollo, you can attach files to messages and comments. This is a much needed feature: web designers often use messages and comments to show drafts; business people might share a contract draft or a business proposal; and so on.
After six months of being public (and six months of frenetic development, may I say), I think it's about time to talk about Apollo, its development, and how it's coming along.
It's very strange for me to think about the way Apollo was six months ago: we have been adding countless important features since we went live (cases & deals, group emails, etc.), and continue developing more and more important parts today.
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.
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.
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?
