Harvest is an online time tracking and billing application. Seeing as I am looking at these things all the time, and am very picky, I thought I’d write a short review. More of a “shout out,” really.

Harvest Time Tracking Page

Harvest is designed on the keep-it-simple model: Have just the features you need, when you need them, and nothing else. It is designed for independent professionals, or teams, and is priced very reasonably.

For a single user—an independent consultant, say—it’s only $12 a month. You can add 2 additional users for $10 each per month (let’s say you wanted to have a couple of subcontractors helping you out.)

For a team of up to 5, it’s $40 a month.

Designing an application that is both simple, and does what you want it to, is no small task. Ask anyone who’s tried to design good software: It’s a lot easier to make something that you throw the kitchen sink into, than it is to make something that has just the functions you want, and nothing else. And yet, that is what makes an application the easiest to use. No extraneous details.

Harvest lets you track the time you have spent on any number of clients and projects. It lets you set project budgets by time, or money. This is one of my favorite features—because what this lets you do, is see how much time  you have used up on a project, in a little visual readout, like so:

Visual Project Readout

In the example above, I am over my project budget by over 3 and a half hours. Not good! But I love to be able to see this sort of thing, at a glance.

What is also wonderful about Harvest, is that it does invoicing. Its invoicing features are excellent: Simple, and natural. Just click a few buttons, and it sends out a very atrractive invoice. It will send an email to the client, help you keep track of who’s paid and who hasn’t, and also tell you which invoices are overdue.

It also does recurring invoicing—either automatically sending out a new invoice, or reminding you about it, so that you can send it out yourself.

Again, it does all this very intuitively and naturally, in my opinion—without a lot of extraneous bells and whistles, but doing everything you’d actually need it to do. And again, this is not an easy job!

Major kudos to Harvest for making a great app. In the past month and a half since I switched to it, I am just loving using it.

Note: For those not as familiar with irony, this series of posts is intented to use humor to illustrate important points about getting a website that works for them, and the potential pitfalls along the way. —ed.

One thing you figure out pretty early on in the web biz: You don’t really have to know how to code web pages all that well.

All those people who talk about web standards, CSS layout, and building sites for efficient updating, blah blah blah—that’s not stuff that’s going to get you a hundred dollars today, and it’s not stuff you should worry about. Your mechanic doesn’t tell you what’s going on under the hood, and your small business client’s not going to ask you what’s going on underneath the hood of their website either.

Believe me: The vast majority of small biz clients who want a website, just want it now, and the last thing they want you to worry about is learning about “best practices,” “usability”, stuff like that. Just get in, get out, and get on to your next website. Duh!

What I’m trying to say here, is, most small businesses know next to nothing about what it really takes to build a good website—one that will last over time, give them what they truly need, and match their real business objectives.

And that’s where you come in: Since they know so little, your not knowing a lot, or keeping up with standards in the industry, that’s really not that big a deal.

Sure, over time, the next web designer that works on your code might be a little frustrated because you laid the entire site out using tables (the web wunderkind of design for 1999).

Sure, it might take them three times as long to make a change to your HTML. But what I’m saying here, is: Your client is never going to figure this out, so you may as well do it the old fashioned way, and save all that precious learning time, which you could more profitably spend… churning out some more websites!

Sure, outputting your client’s 20-page site as a series of static HTML files might not seem very efficient to the effete “web professional” who has to make a tiny change in all 20 of those files later on. I can just see the poor sap whining to the client—“but the reason this is taking so long is because the code wasn’t architected well.” (They love using big words like “architected!”) Wah, wah, wah.

Meanwhile, you’ll be on to someone else’s site, and they’ll be toiling away. What’s it to them, anyway? They can just charge the client more to make the changes, because it’ll take so much longer! It’s a win win for everybody! Well… almost everybody!

*

Last year, my wife and I had a contractor come out to our house and add an extra room. He seemed like a nice guy, and since I know nothing about building stuff, I just pretty much trusted him. He worked and worked, and said, “that’ll be $xx,xxx.00″. Fine, and we paid him. I found him through a friend of a friend of my wife’s uncle, and we went with him because he offered us the cheapest price by far!

And what’s wrong with that!?

I am wondering what the strange smell coming from our new room is, and if you look at it from a certain angle, I bet you’ll notice that it doesn’t quite “line up” with the rest of the house.

But … so what?

• The Business Value of Web Standards (Adaptive Path)
• The Business Case for Web Standards-Based Development (Navigation Arts)
• Why Tables for Layout is Stupid (Seybold, 2003)