To connect, automate, and simplify the billing process
If we were to boil everything about CompassBill down to the simplest possible unit, this is what it should look like. This idea defines what we do here. Anything that doesn't fulfill this vision, even if it may be arguably useful, just isn't true to our application.
Version 1.3 of CompassBill continues is finely tuned to this vision, particularly simplification and automation. Continuing what we started by leaving out late fees*, we have removed statements as well. In addition, we've simplified our menu, making it quicker to get to the most important sections of CompassBill. Even our newest features, our automated invoice generation and reminders, were kept simple.
Speaking of automation, this release marks our next big step towards satisfying the second part of our vision. What started with recurring charges has been expanded to automatically generating invoices and emailing reminders to customers.With this powerful, yet simple, features added to CompassBill, you can generate invoices and improve your accounts receivable turnaround while sound asleep, giving you more time to build and expand your business.
We invite you to login to CompassBill and try out these powerful new features. Automated invoice generation, recurring charges, and automated reminders are accessed from the new Automation tab on the menu. As always we welcome any feedback. Here at CompassBill, you are rest assured that whether you wish to compliment or complain about us, you'll be talking to a developer.
Oh, and about the first part of our vision? Stay tuned.
* Yes, we're aware that post has a somewhat different "one point vision". Our new one is a clearer distillation of our vision, and we reserve the right to refactor our vision, as we do to refactor our code. So there.
Showing posts with label philosophy of CompassBill. Show all posts
Showing posts with label philosophy of CompassBill. Show all posts
Thursday, October 7, 2010
Tuesday, March 30, 2010
What's (Not) Inside CompassBill
Do it simple, do it quick, and do it well
This is the core philosophy for our apps here at CompassWare. We develop tools to make the small business owner's day easier, because we are small business owners. We have enough to worry about without a clunky and complicated application preventing us from conducting business.
Because of this, our applications may not have every feature a business owner could want at any time in their businesses development. For example, CompassBill is centered around our needs for an invoicing system, not the hypothetical needs we (or a customer) might have at some point in the future. The features that are there are there because we needed them, so we are sure how they should work.
Even if a feature is useful, that doesn't mean it should be in the application. The feature may be way too complicated, canceling out whatever benefit it may have. In the worst case, it may even completely mess us the ease of use of the entire app.
An example of this were late fees. A feature for handling late fees was useful, and was something at one point we intended to include in CompassBill. However, once we got into it, we realized implementing the feature as good as we would want it would add additional complication, with only marginal benefit. In addition, we were fast approaching our go live date, and were left with a bad choice. Either finish the late fees and sacrifice other areas (such as PDF invoice generation), or delay the launch to implement a complicated and shaky feature.
Instead of taking either of those bad paths, we decided upon a third route. We decided to completely leave late fees out entirely. It wasn't a core feature of our application (unlike PDF invoice generation), and delaying our launch was unacceptable. It wasn't the easiest decision to make, but it was the best, and we have no regrets doing this.
Might late fees someday be part of CompassBill? It's possible, especially if our own needs make it a necessity. But if we do decide to implement late fees, it won't be done without keeping to our standards of usability and quality. That's just the way we do it here at CompassWare.
This is the core philosophy for our apps here at CompassWare. We develop tools to make the small business owner's day easier, because we are small business owners. We have enough to worry about without a clunky and complicated application preventing us from conducting business.
Because of this, our applications may not have every feature a business owner could want at any time in their businesses development. For example, CompassBill is centered around our needs for an invoicing system, not the hypothetical needs we (or a customer) might have at some point in the future. The features that are there are there because we needed them, so we are sure how they should work.
Even if a feature is useful, that doesn't mean it should be in the application. The feature may be way too complicated, canceling out whatever benefit it may have. In the worst case, it may even completely mess us the ease of use of the entire app.
An example of this were late fees. A feature for handling late fees was useful, and was something at one point we intended to include in CompassBill. However, once we got into it, we realized implementing the feature as good as we would want it would add additional complication, with only marginal benefit. In addition, we were fast approaching our go live date, and were left with a bad choice. Either finish the late fees and sacrifice other areas (such as PDF invoice generation), or delay the launch to implement a complicated and shaky feature.
Instead of taking either of those bad paths, we decided upon a third route. We decided to completely leave late fees out entirely. It wasn't a core feature of our application (unlike PDF invoice generation), and delaying our launch was unacceptable. It wasn't the easiest decision to make, but it was the best, and we have no regrets doing this.
Might late fees someday be part of CompassBill? It's possible, especially if our own needs make it a necessity. But if we do decide to implement late fees, it won't be done without keeping to our standards of usability and quality. That's just the way we do it here at CompassWare.
Friday, March 26, 2010
Don't Be A Tom Sawyer Developer
From the title of this post, you might think I am referring to the famous whitewashing incident in The Adventures of Tom Sawyer. While that story certainly could apply to a developer, I am referring to the end of The Adventures of Huckleberry Finn.
For those who aren't familiar with the story, I am referring to Tom and Huck's plan to break runaway slave Jim out of captivity. All things considered, a very simple and easy plan could have been executed to get Jim out. Instead, the plan becomes needlessly complicated, involves an amazing amount of additional work, and almost results in getting Tom killed.
Why did they go to so much trouble when a simpler plan would have worked? Because Tom felt the simple way wasn't an honorable way to spring a prisoner. According to his understanding of the process from reading books such as The Man in the Iron Mask and other classics, a breakout had to be complicated and harrowing. Thus instead of a one night job, it became a mess full of "pet" spiders and snakes, cobbled together shovels and knifes, and a rope ladder baked into a pie.
As a developer, I must admit that far too often I've fallen into the trap of "complicated = better". Like other people, overcoming complicated situations make me feel good, even if some of those complications could have been avoided. Sometimes these complications come about because of a desire to do it right, to follow what a book or what conventional wisdom says is the right way. Often times this takes longer than a simpler, if inelegant, solution was taken, and is rarely ever better than the simple solution.
The ideal application gets from point A to point B in a straight line. While this may be an unrealistic level of simplicity to always reach, it is certainly a wise goal. It is the driving principle behind CompassBill, and the cornerstone tenet of CompassWare. So with all due respect to Mr. Sawyer, we feel the simple way is plenty honorable.
For those who aren't familiar with the story, I am referring to Tom and Huck's plan to break runaway slave Jim out of captivity. All things considered, a very simple and easy plan could have been executed to get Jim out. Instead, the plan becomes needlessly complicated, involves an amazing amount of additional work, and almost results in getting Tom killed.
Why did they go to so much trouble when a simpler plan would have worked? Because Tom felt the simple way wasn't an honorable way to spring a prisoner. According to his understanding of the process from reading books such as The Man in the Iron Mask and other classics, a breakout had to be complicated and harrowing. Thus instead of a one night job, it became a mess full of "pet" spiders and snakes, cobbled together shovels and knifes, and a rope ladder baked into a pie.
As a developer, I must admit that far too often I've fallen into the trap of "complicated = better". Like other people, overcoming complicated situations make me feel good, even if some of those complications could have been avoided. Sometimes these complications come about because of a desire to do it right, to follow what a book or what conventional wisdom says is the right way. Often times this takes longer than a simpler, if inelegant, solution was taken, and is rarely ever better than the simple solution.
The ideal application gets from point A to point B in a straight line. While this may be an unrealistic level of simplicity to always reach, it is certainly a wise goal. It is the driving principle behind CompassBill, and the cornerstone tenet of CompassWare. So with all due respect to Mr. Sawyer, we feel the simple way is plenty honorable.
Subscribe to:
Posts (Atom)