From 160 Hours to 10: A Tale of Agile Business Practices

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

, didn’t need to wire up real-time provisioning for new accounts, and didn’t even need a custom purchase page
Start Small, Get Big
Growth Secrets for Self-Funded Startups. It'll Change Your Life.
What you get for signing up:
  • A 170-page ebook collecting my best startup articles from the past 5 years
  • Previously unpublished startup-related screencasts
  • Exclusive revenue-growing techniques I don't publish on this blog
"The ideas and information Rob provides should be required reading for anyone that wants to create a successful business on the web." ~ Jeff Lewis
Startups for the Rest of Us...
If you're trying to grow your startup you've come to the right place. I'm a serial web entrepreneur here to share what I've learned in my 11 years as a self-funded startup founder. Luckily several thousand people have decided to stick around and join the conversation.

For more on why you should read this blog, go here.


#1 Darren on 04.07.10 at 8:11 am

I recall Joel Spolsky on one of the Stack Overflow podcasts saying how FogBugz is “single tenant” in that each customer has their own database.
He said something about it simplifying development and making it really easy when customers asked for an export of their data.
Makes a lot of sense, as you are seeing.

#2 Louis-Philippe Huberdeau on 04.07.10 at 11:07 am

Manual set-up does not always mean fully manual. It really only takes a few iterations for scripts to start appearing to do the bulk of the job. The only issue at that time is that you loose some value because people these days got used to having their accounts live from the moment they press submit. Having a human involved will add some delay. If it’s for a trial account, that might affect your conversion rate. However, if they gave the money, they will come back anyway.

Once you have the scripts in place, the final automation is not that much trouble.

#3 Stephen Harrison on 04.07.10 at 6:53 pm

How very true!

As a bootstrapper I’ve also found that not implementing a feature until it’s really needed is a great way to go, one in particular for me was subscription payments, I decided that if a few customers subscribed in one of my websites I would then worry about getting the payment processing done and giving those customers complimentary subscriptions until I had the code written, as it turns out that part of the site never took off so wasn’t needed, time saved, product launched earlier – result!

Following up on Darren’s point, I believe Joel also said that it helps maintain a secure separation of the customer data, which I would say is a really wise move for financial software like DotNetInvoice, it’s too easy to make a simple coding error (or leave a SQL Injection window) and expose another customers data, by having a separate database the footprint of the code that could allow that to happen is greatly reduced, so I’d suggest sticking with the single tenancy idea, and actually marketing how your product is better because of it.

I also agree with Louis-Philippe, in today’s world if I’m looking for an invoicing solution I’m going to have signed up with your competitor about 10 minutes after signing up with you if I cant get going, especially if I’ve left invoicing customers until the last moment, I don’t mind waiting 10 mins if you are creating databases and the like which provides a bit better security, but I don’t want to wait until your next work day, so whilst you may save a couple of hours writing and testing that bit of the code I’d suggest you are more likely to loose a few customers as well.

BTW – on a technical note, could you not just pick-up the host value from the server variables, tie that into a simple database connection string lookup so you could use a single IIS website configured for multiple (wildcard) hosts/subdomains? I’ve done something similar with my exchange rate websites where they are all in the same IIS website but based on the domain name you used to get there you get to see a different currency specific site – makes upgrading the code base so much easer than doing 23 sites – even with automation!

#4 Small Business News: Forecasting the Future | Small Business Trends on 04.07.10 at 7:23 pm

[…] Is your product good enough? Why new products don’t have to be perfect to propel your company into the future Software by Rob […]

#5 Rob on 04.07.10 at 7:24 pm

>> …could you not just pick-up the host value from the server variables, tie that into a simple database connection string lookup so you could use a single IIS website configured for multiple (wildcard) hosts/subdomains?

This is a good idea, and certainly possible. However, not given the current structure of DotNetInvoice. This may be something we look at down the line, but right now we have a static logo we would need to swap out, as well as a few other settings that pivot on web.config itself. But sounds like something we should look into for the future.

#6 Sean Tierney on 04.07.10 at 7:41 pm

on point as usual. We have a lot of edge case operational scenarios that we intentionally keep as a manual task rather than automating. It’s this way for 2 reasons: 1) the cost of automating doesn’t yet have the ROI to justify as you metion 2) also the requirements are so open and foggy, it’s premature to try and distill it to code. we learn every day by having to handle these custom scenarios manually- but the key is to document them.

If you subscribe to the Toyota / EMyth philosophy then you don’t just work _in_ the business and handle these incidents one-off as they occur. You create a _process_ for everything. I have a page on our wiki for codifying processes so for instance wiki/processes/billing/purchaseOrders/newQuote would have a recipe for what’s involved in handling the task of issuing a new quote to a customer that wants to pay via PO. I’ll write out the steps in shorthand english with if/else statements and eventually this collection of pages becomes the pseudo code for automating that task when it makes sense. Or, a step before that- it allows me to delegate it to an intern and have he/she flesh out the instructions, determine where the holes are and find all the edge cases before coding it.

Have you played with any of the BPM stuff like Intalio by chance? Curious if you like that more formal approach or if you’re a bigger fan of freeform text on a wiki…

Great piece of advice tho. Writing code should be viewed as an expense beyond the cost of the time it takes to write it.


#7 Rob on 04.08.10 at 12:13 pm

@Sean – Thanks for the feedback.

>> Have you played with any of the BPM stuff like Intalio by chance? Curious if you like that more formal approach or if you’re a bigger fan of freeform text on a wiki…

I haven’t played with Intalio (nor heard of them before now). For this particular process I use the Wiki built into FogBugz, but depending on the project and process I also use Google Docs quite a bit, screencasts hosted on my own server (if I’m trying to teach someone else to do a process), and text/Word docs checked into SVN.