"I decided to roll my own in this case because I was interested in learning about email handling after watching this great railscast from Ryan Bates. And because paying $9 per month per user for something I could probably write myself in a couple of hours seemed silly."
I find myself having to fight against this instinct almost every day. There are a couple of problems with hacking for a couple of hours to save a few bucks a month.
Firstly, you now have an additional piece of software to maintain - you're committing yourself to an unknown quantity of future work.
Secondly, your software won't get any better without you actively improving it. The nice thing about software you pay someone else for is that it gets better over time.
It's a tough instinct to fight though. Building things is Fun. It's just that there are probably other things you should be building that are more important to your company.
I know what you mean, and I'm torn. This project was built in about 4-5 hours on a Saturday, mainly as a chance to learn about mail handling. It's ugly as hell and there are no tests (!), so I don't know how well it will hold up as a long-term solution - I guess we'll see.
I just find the $9/month per employee a bit repugnant - if we grow to 10 people, we'll be paying over $1000 a year for a piece of software that parses subjects out of emails and stores attachments. Doesn't seem like a good deal.
As a rough guide, you might factor in another 8-10 hours, because, according to Fred Brooks, a proper programming "product" takes about x3 as long as a "program".
Taking a wider view, there's an appeal to "cloud components", where all components are rented - including ones as simple/trivial as this. For this to work, it has to be cheap enough to be a no-brainer (esp for projects made of such components). Say, 1/100 - pennies - e.g. 9 cents /m/e. In the long-term, you'll see free open source alternatives, and maybe even free hosting (cloud providers supply it free, to support their hosting of your actual app)... and maintained.
I will give you the answer now -- it won't hold up :). Parsing and handling email is notoriously finicky, and every app I've written or maintained to do it has a constant stream of little bugs and edge cases that must be tested and handled that grow over time.
Would be interested to see a followup in 6-12 months.
Instead of simply looking at the absolute value of the cost per employee, compare it to the time lost to the current method of accounting. Do you lose $9/month in work per employee on expense processing?
If it takes employees an average of 5 minutes per month, you don't have a problem. If it takes them 2 hours per month, investing $9/employee/month is a net win.
Hosting your own on Heroku isn't cheap either. Not to mention even more time savings when you go the paid route (interfaces into accounting software and what not).
As engineers, our instinct is to build things. Business discipline requires focusing on profitable uses of time.
It's highly unlikely that building expense tracking software was the best use of time for the original author. He writes that thinking about the POTENTIAL future costs of expense tracking software ($1000/year) upset him.
If one realistically considers the costs to "roll your own" in terms of time, maintenance overhead, hosting & administrative cost, and opportunity cost the obvious conclusion is that this is not a good use of time and energy.
If Tom had instead spent that time fixing a bug, doing hard sales/marketing work it would have been worth much more to him.
No for us, engineers, doing hard, repetitive work is the real discipline. Automating things and finding systems that can be made more efficient is the easy work. Picking up a phone and making a sales call, trying to improve ad words advertising....these are things that are likely more valuable than rolling your own expenses email system.
Except, by rolling our own systems and automating things we want to, we expand our potential and learn new things, which gives us somewhat difficult to quantify value for the future. One can't become an engineer without solving nontrivial (for one's own skills) problems.
"Software you solely maintain" and "software you pay someone else for" are not the only two options. You may have heard of something called "open-source software", which is a way that the load of maintaining a program can be spread around the community of its users — like paying a vendor to maintain it, but you pay in code instead of money, and you still get to use it even if you don't pay. Ruby, for example, the language he wrote this in, is open-source software. Much of the internet is built with it.
There are probably other companies in England that also need to report expenses to accounting.
It's also worth noting that for the specific problem he mentions, texthog is free for individuals and expensify is free for individuals and small groups.
I find myself having to fight against this instinct almost every day. There are a couple of problems with hacking for a couple of hours to save a few bucks a month.
Firstly, you now have an additional piece of software to maintain - you're committing yourself to an unknown quantity of future work.
Secondly, your software won't get any better without you actively improving it. The nice thing about software you pay someone else for is that it gets better over time.
It's a tough instinct to fight though. Building things is Fun. It's just that there are probably other things you should be building that are more important to your company.