More than two years ago my business partner and I discussed launching a hosted version of my ASP.NET invoicing software, DotNetInvoice.
We developed the plan and a task list, and estimated the effort at around 160 hours including development time needed to make DotNetInvoice a multi-tenant application. But given the heavy competition in the hosted invoicing software market and the level of effort of the task, it was continually placed on the back burner.
Until we figured out how to get to the same endpoint with 10 hours of work.
The Shearing
After our initial 160 hour estimate, every six months or so for the past two years we’ve revisited the idea of a hosted version until one day in November of last year. On this day we came to the realization that we didn’t need to make DotNetInvoice multi-tenant in order to have a hosted version. The other invoicing players are multi-tenant because they coded their invoicing services from scratch, but it’s not the only way to do it.
The more we thought about it we realized the benefits to keeping it a single-tenant application: the ease of migrating from our hosted version to a downloaded version, and keeping each customer’s data separated in its own database to name two.
The interesting thing is that once that large task was removed from the list, other things to started to fall off, as well. At this point we begin looking at the launch of Hosted DotNetInvoice as a market test; to see if we could build enough of a customer base to warrant a major investment in the hosted invoicing market space. With that in mind, things started flying off our “must-have” list.
The next largest piece was automating sign-up and provisioning of a new hosted installation. In an ideal world, when a customer wants a new hosted account they would fill out a web form with all of their information and their new hosted version would be ready in 30 seconds. But that amount of automation – given the fact that we have to create a new sub-domain, a new database, and copy physical files – would take a substantial amount of time to develop and QA. So we tossed it.
The final thing we threw out was the need for a custom purchase page. A page where someone enters their details to make the purchase. In a desperate attempt to bring this entire project down to less than two days work we simply utilized PayPal subscriptions. Not the most professional approach, but it works very well for testing out the idea before we invest another day into this project.
Iteration vs. Automation
Now as a developer, the features I mentioned above seem like a necessity from day. Not automating this process creates the ongoing repetitive work that computers are designed to handle. Aaaaah, manual work…this is what computers are supposed to save us from!
In essence, this approach does not scale infinitely, which tends to be the kind of scaling that developers default to (this includes me).
But by getting over the need to automate everything to infinite scale and putting myself in charge of manually creating new hosted accounts, the time investment to get this feature launched dropped from 160 hours of work to about 10 hours.
I can hear the cries of developers around the world as I write this: “You can’t launch a half-baked solution! You’ll never go back and fix it!”
Most of us have worked in corporate environments where you’re never allowed to go back and refactor code. This burns into our psyche that you don’t want to launch a semi-functioning solution because you’ll never have time to go back and fix it.
But the benefits of being my own boss and being a tiny software company, are that I can come back to this anytime. In fact, the more times I do it manually (since I’m handling it myself), the more motivation I will have to automate it. Add to that, the more I develop and streamline my manual process, the easier it is to automate it later using code. Having more experience with the process will actually mean I can code it faster.
And ideally, by the time I code it up, we’ll have many customers using the platform which means I’ll be working on a product I know is viable, and that’s paying for the time I’m spending to automate it.
Agile Development, meet Agile Business.
Know Where it Ends
Through a bit of manual labor, or better yet some delegation and outsourcing, you can get to market with less up-front expense and in dramatically less time than if you try to automate everything.
But the number one question you need to think about when going after this Agile Business approach:
At what point is it worth spending the time to truly automate this?
In other words: how many sales do you need to make in order to justify the time and effort to write the code to automate this process?
Without a number in mind you run the risk of never wanting to invest the time to automate, and becoming hostage to a bunch of half-baked manual processes. At some point you have to automate the process or kill the feature…know that point before you start.
The Best Code I Ever Wrote
Had we chosen to automate everything, the worst outcome would have been investing 160 hours of time (as a Micropreneur that’s a huge amount of time), and then scrapping the whole thing. When you’re working on such a small scale you can’t afford to throw away that much time.
But whether you’re working as a corporate developer or a Micropreneur:
The best code you’ve ever written is the code you never had to write
