At LogicalVue we do both consulting and product development. Our goal is to be a completely self-sufficient software product company, but it seems pretty common that software product companies start out doing a lot of consulting. After all, it is a lot easier to find consulting work that pays well than it is to think up a product idea, create it and then sell enough copies to make a living. But why would you do both? My reasons: Consulting pays the bills. Products pave the future. In our case, we do consulting to generate revenue and get exposed to potential product ideas.
Consulting Benefits
- Easier to get business
- Can quickly generate revenue
Consulting Cons
- Margin is lower; you’re selling your time and that has a fixed upper limit
- Clients change requirements during development
- Requires more staff to take on more work
Product Benefits
- After paying for development costs, all sales are pure profit, thus products scale very well
- Growing the company is more managable
Product Cons
- Could take a while before revenue is substantial
When starting out, it seems logical to combine the benefits of both consulting and products. For a single person company, it makes sense to do part-time consulting 50% of the time and product develoment the other 50%. At $100/hour, you could generate about $2000 per week if you work 20 hours on consulting. This is $104K in a year. Not bad for part-time work. Don’t realistically expect that much, though. You should account for time off due to vacations or gaps in consulting work. If you have more work than you can handle, you could always subcontract the work, but this has added management overhead that you may not want.
All this is fine, but you need to be careful not to get completely sucked into the consulting mentality or you will never achieve product nirvana.
Many times I’ve seen (and been a part of) companies that start off with a product that is very specialized and vertical and thus very expensive. Customers won’t buy expensive software unless it does exactly what they want for their business. So to get a sale, you agree to customize your product to do these new things that the customer wants. This is where you start to enter dangerous territory. How do you do this? You could add these new features to your product, but that will just needlessly complicate it with things that no other customer will likely want. You could fork the code and do a one-off version of your product for the customer. But then you’ll have no sustainable way to maintain it and customers will have no practical way to upgrade. I have a term for what happens when you start doing this. I call it consluting. For specialized, vertical, expensive software, I can think of a couple of ways to manage this:
1. Don’t do it
The most obvious is to not do the customization in the first place, but then you likely won’t get the sale. However, you should seriously consider this option. Not every sale is worth your time. Revenue does not always lead to profit. If you want to lose money, I can think of much easier ways to do it than to spend months working on a customization for one customer. For example, just send the money to me.
2. Build a customization mechanism
If you were smart enough to think of this problem before you built your product, then you could consider adding a way to allow your product to be extended, via plug-ins or some other mechanism. Since this is your design, you can be pretty flexible here, but the thing to consider is that you want to make it easy to add code to your system, without preventing the customer from upgrading to newer versions of your product.
3. Create fully configurable software
I’ve seen companies that thought they were smartly pre-empting this problem by allowing their software to be widely configurable. “The customer can configure it to do whatever they want without changing code” is the mantra. This is a snakepit. Doing this will greatly increase the complexity of your system. How will you test all the possible configuration permutations? You won’t be able to. This is a rat’s nest. Do not go anywhere near it.
So there you have it. Comments?
October 12th, 2006 at 4:24 am
Hey there dude,
Just a quick question, how does your company handle its contracting work? Does it contract only for projects (ie, design and build to order) or does it actually contract out programmers? Ie, flesh and blood bums on seats for clients who don’t want to employ themselves, but want a programmer on staff.
Just curious as to how things are done out there in the wider world.
October 12th, 2006 at 10:16 am
Hello,
We’re not a very big company so we only contract for specific projects. Contracting out programmers is a whole other area that I’d prefer not to be involved with.
– Paul
October 12th, 2006 at 6:22 pm
Speaking as a contracted-out programmer, I agree
Take care.
October 19th, 2006 at 10:22 am
[…] In a previous article, I mentioned that you should consider building a customization mechanism into your software if you think you’ll need to customize it in order to make a sale. This is frequently a requirement for large, expensive enterprise software. […]