Custom Development Costs Too High?

Small business has entirely different needs and expectations from technology than larger enterprise.  Okay, that is an obvious statement, right?  So then why are small businesses always so surprised to learn about the cost associated with custom projects?

 

 

First, a Little Background

There was a time 10 years ago, when the company I worked for would build websites for mid-size companies, and we could never quote less than $15-20k for a simple website.  In today’s world of WordPress and 1000s of templates to choose from at $30 a piece, that seems almost unbelievable but remember, frameworks like WordPress didn’t exist and neither did the templates, or even best practices for design in the early days.  As a result, you had to do pretty much everything by hand. You would write every function, connect it to the database, hand-code the HTML, and equally the designs were mostly original work that took time and research.  And so yeah, all-in, creating a WordPress equivalent website from scratch would have easily required 3-4 weeks of developer time, 40 hours from a designer, and another 40 hours for project management and requirements gathering.  All said, you’re talking about 6 weeks of work!

Fast forward 10 years and there are numerous companies offering to build a website for $500, or less!  By using an open source framework, free plugins, and by customizing an existing template for your design rather than starting from scratch, the website developer really only needs to snap peices together now – the pieces are built already, making it a relatively easy project to put together in days or even hours, rather than weeks.  No worries really about bugs either, since a lot of the logic is already written and revised from other projects.   Effectively, those problems have been solved now and we have commodity solutions to those problems.

Expectations Mismatch

The availability of lower-cost solutions is a great thing, but it creates a mindset of cost expectation that often isn’t realistic when you begin to look at custom coding work.  For example, even just adding a functional interface with JavaScript and AJAX to optimize user experience or validate a form, might not already exist and will require custom development.  On the surface this statement seems reasonable to a developer, but what if it is 8 hours of work and costs as much as the initial website itself? Will the client/customer still find this reasonable?

As businesses go deeper into custom work, there are fewer templates and fewer frameworks and technology stacks upon which they can stand to accomplish their task and as a result costs and time requirements will begin to scale exponentially. There is afterall, a reason why Amazon.com employs 1000s of people and yet you can have your own ecommerce site built in a day.  This dichotomy seems to always be an issue for the non-technical person to accept, not just at the small business level, but any time a businesses tries to go a layer deeper.  I’ve seen the same issue among mid-size businesses as well, when looking at going into deeper systems integration work.  One company in particular  I observed, went from using PHP/LAMP technology for their website in,  to deciding it was time to go deeper. They embraced an enterprise Java stack to begin developing the business logic and work on other systems integration work, and were stunned to realize their time estimates were less than a third of what was now required to do the work.

Development Value Pyramid

Lessons to be Learned

A lesson here, is both for developers to realize the paradigm that businesses are coming from when their expectations are challenged, and also for business owners to understand the reality behind why costs scale exponentially as we go deeper into systems.   When a business owner is use to $500 price points, a $5-20k price tag for the completely custom project they asked for is going to be scary and will invoke trust issues.  But that doesn’t mean the developer should work for less to appease a client, or that they’re necessarily wrong for proposing a higher cost for what the client asked for either.  The problem to be solved, is one of expectation management.

Advice For Developers

For developers, this is going to be a larger challenge the higher up on the pyramid you go, where the most commoditization has occurred.  If you’re trying to operate one layer below templated solutions, you’re going to have the biggest challenge convincing clients that you should be charging so much more, if they cannot see tangible value as a result, compared to just using a template.  In this case, you’d better align yourself with clients who have a lot of money to spend on branding design, rather than technology.  And if you’re offering customized app or interface development solutions a layer down, you’re going to see more and more frameworks trivialize what you do over time, and push you further toward commodization.

Indeed, it would seem a developer is better off specializing as low as possible on the pyramid, if they’re going to offer custom solutions.  Businesses however will continue to find opportunity to push value further up the pyramid and further commoditize and productize the solutions for the small business consumer.  This is why the SaaS business model is so poignant, since it promises to make available solutions that have real value for smaller businesses, who could never afford them before. So if there is any lesson to be learned here at the bottom line for developers, perhaps it is to be realistic in understanding who your audience is, and who is willing to pay for custom work versus a customized commodity. If you’re going to address the commodity audience, find a away to productize and scale it as a business.  But if you’re going to focus on skills and custom work, go as deep into the value pyramid as possible…and stay there!

Positioning a B2B Solutions Company

When you are building B2B solutions and services, you must consider the size of the companies you want to target; the needs are profoundly different from large to small and thus, your approach and even the way you would structure your company, is inherently different.

Consider that if your goal is to create a productized solution out of commodity technology, and put it in “the cloud”, you’re most likely talking about small to mid-size businesses. SaaS almost by definition is about the democratization of sophisticated technology that only large enterprises had access to before.  Part of this however, is making it affordable.  The smaller businesses benefit significantly from the lower price points that fit their budgets and so they (should be) willing to accept the product as it is, without needing customizations.

The large enterprise company meanwhile has very complex regulations and workflow considerations.  I’ve personally seen a large company spend $2 million just to license a piece of software and another $1 million to hire company consultants to spend the next year configuring it for them.  For enterprise, what they need is assistance with streamlining their process, and cost is not as significant.

So when you set out, your first question should be ‘who is my customer?’, and respond with appropriate offerings.  If you’re leaning to small business, think in terms of how to develop a productized and highly efficient solution that can tough many small businesses.  If you’re looking at enterprise, you’re better off focusing on leveraging well-known platforms rather than creating any products or platforms.  Mid-size businesses seem to benefit most from offering customized off-the-shelf solutions, such as an ecommerce solution, with an extra layer built to provide additional reporting and legacy integration.

Another interesting consideration I realized while thinking this through, is the balance between selling and performing your craft.  If you are a productized business, 90% of your team may be sales and marketing professionals as you scale, whereas only 10% would still be focused on technology and product. The exact opposite is true for a large enterprise focus, where custom solutions lead to very long contracts and require less customer acquisition as a focus.

Business Scale

Here are a few other comparisons I have observed when comparing small, mid-size, and enterprise clients.   Small businesses are most similar to B2C clients where pricing and simple/seamless solutions drive decision making.  As you each enterprise it is much more important to use high-end technology and focus on quality craftsmenship and understanding their specific needs.

Small Business Mid-Size Business Enterprise
Level Turnkey Customized Turnkey Custom Services
Verticals Local / Real Estate eCommerce/Fulfillment System Integration
Technology PHP .Net Custom Java Solutions
Platforms WordPress Magento / Force.com Spring MVC
Sales:Services Ratio 90% 30% 10%
Number of Clients 100 10 1
Cost Per Project $1,000 $10,000 $100,000

 

Java vs Ruby on Rails vs PHP

I’ve been reading a bit lately about how developers feel about Ruby on Rails compared to Java and PHP.  I found a couple of interesting posts and wanted to share. One clever article I came across was at PardonTheInformation, where the author compared his experience with Java and Ruby on Rails (ROR) and tried to determine which is a better choice for entrepreneurial projects.  He ultimately concluded they were an overall dead-heat and the decision depends upon what you want to use it for.  The second was an article from CMSWire in which they compare the three on a little different metrics.

I am fairly biased against using Java for entrepreneurial projects.  I feel it is way too heavy and all of the structured code and factored frameworks are great for having flexibility in an enterprise, but it is overhead that you pay for in terms of complexity and time-to-code, and is completely useless for developing a minimally viable product (MVP).  You’re much better off focusing on hacking together those early iterations in an easier language and then moving to a more structured language and framework when you are past all the ‘pivoting’.   Now, whether that means you hack together the first iterations in PHP and then move to Java later when you’re ready to scale, or just take a more middle-of-the-road approach such as RoR or .net from the beginning, is a judgement call, for each organization.    I must admit however that I do like a lot of things about Ruby on Rails and that it has become the lingua franca of the startup world.   Anyway, here is what a few others had to say about them:

I. Entrepreneurial Report Card

From PardonTheInformation

Ruby vs Java Scorecard

 

II. Comparing Intrisics

From CMSWire

PHP Vs Ruby Vs Java

Indecently, I was surprised to see CMSWire call out that PHP scales better than Java.  I must say though that I agree!  It is counter-intuitive at first, but if you’re scaling by adding autonomous new server instances to your cluster in which each is a mirror of the first, rather than a structured pyramid cluster as is often used with Java apps, it can actually scale quite nicely.

Critical Lessons Learned In Entrepreneurship

I have gone through the entrepreneurial route twice now, and both times I was able to build a product and sell it in the end.  My first attempt I was fairly successful in driving traffic and sales but second attempt however was more of a challenge.  In that second venture, I invested quite a bit of myself into it and I just couldn’t break through.  At some point I realized that I was a technologist principally and just not sophisticated enough as a marketer or entrepreneur to break through.

I decided to take a break after that and not try building another business until I was clear on what I did wrong and what I would do differently next time.  For many months afterward, I really did believe I had done a great job and I did nothing wrong.  It is true that I worked extremely hard and invested significantly into the project, and I still believe I built a truly World-class product.  So why did it not gain the momentum I had expected?  This began a few years of obsessive study of entrepreneurship which is why I decided to start this blog actually.  In any case,  I’ve had enough time to reflect now and I think I realize a few things I was wrong, at a more fundamental strategy level. For the sake of my own documentation and hopefully for the benefit of other entrepreneurs out there, I want to share my list:

1. Respect Timing – I was naive and didn’t realize the vertical space I chose was already in the early stages of consolidation and commoditization when I entered it.  Thus, brands were already entrenched and beginning to spend heavily to reinforce their brand.  It was going to be nearly impossible for me to get any traction without having a substantial amount of capital to spend on marketing.  This was not the right entry point for an individual entrepreneur working from a personal budget.  This was perhaps more important than any of my other mistakes and I’ve spent a lot of time pondering the issue of timing.

2. Avoid Network Effects – What further complicated adoption of my product was something Robert Metcalfe would call a network effect, whereby the value of the site was only as valuable as the nodes (or people in this case) of participating.  As the number of people multiplies, the value becomes exponentially more valuable.  In otherwords, think of a night club. The one with a line out the door will automatically attract others whereas the empty one will stay empty.  It is a dilemma that plagues most in the web 2.0 and social spaces and a real multiplier effect upon the issue of timing. You’d need either serious money for promotion or a massively disruptive innovation to break through these challenges.

3. Be Demand Focused – Another naivety on my part was thinking like an artist.  I truly fell in love with my creation and it became my work of art. As such, I was building what I want to see after a while, not what people really wanted.  Had I come from a more demand-driven perspective, perhaps I would have seen more clearly that the market was already in a mature phase and another entrant to the marketplace was not warranted.  Instead, I was focused on building a better mousetrap and just out-performing the competition.  At some level, I still believe I built a good enough product to have competed with the million-dollar companies around me, but my marketing was completely non-existent and I really under-estimated how important that was. Typical artisan mistake.

4. Lead With Marketing – I really should have focused my budget and effort on marketing, not the product.  I was firmly convinced that if I built something great, they rest would become easy. I should have been spending more time smoke testing before building the product and later, testing user interest and ROI etc, instead of spending all my time and money on product development.  That was a major strategic mistake. Had I done this correctly, I would have much more quickly realized the market conditions were not favorable.

5. Smaller Pilot Market – Back to the network effects, I think I could have stood a better chance breaking through a single geographic market instead of trying to break into the national market.  I should have proven the market and built up the network effects in one market at a time, and I think had I done that, my conversion rates would have started to spike upward and I would have achieved buzz and that feedback look would have started working in my favor. That too would have helped me to gain some traction.

5. Avoid High Sunk Cost – As an independent entrepreneur with limited personal funds, I should have been much more realistic about what business models match the funds I was working with.  Granted, I put up a sizable mount of money at a personal level to make that project fly, but it is trivial compared to the massive companies I was competing with. But equally important, that’s a lot of risk to take on up-front before the cash starts to flow in.  For this reason, I believe services-based businesses are a much better match for independent entrepreneurs, not product-based businesses.  Services require a lot less up-front risk and provide cashflow from day-one.

6.  A Great Hook Is Helpful – Just like a song, it can be wonderfully produced with amazing aural textures and harmonies, but at the end of the day, if it does have an addictive, melodic, easy-to-remember hook, its not going to take off.  This ties back into my need for more marketing focus, but is something else I should have considered.  I was trying to build a solid end-to-end product.  Instead, I would have been better off focusing my efforts around one powerful and disruptive hook, and then building around that.  I approached it backwards.

7. Avoid Java (Keep it simple) – This last one is more tactical but I must say it was a huge mistake for me to use the Java technology stack for this project.   I was a Java developer for a number of years leading up to the project and I saw this project as an opportunity to take my skills to another level with the new MVC and ORM frameworks and thought I was accomplishing two things simultaneously my doing this.  But anyone who was developed Java and PHP apps in the past, realizes the massive overhead that comes with Java and the related frameworks.  This probably slowed development to half or less of what I could have accomplished with PHP. Moreover, because of the thoroughly-composed Java architectures, it actually made “pivoting” more costly and more challenging; ugly PHP code would have trivialized this because that structure wouldn’t have gotten in the way.  Ironic that my high quality and highly maintainable cost based actually was causing such issues.  It really highlighted for me however, that there is a right time and place for every tool in the toolbox, and Java is appropriate for that second generation application once scale is necessary and the rules are well defined… NOT for early stage pivot-probably entrepreneurial efforts.

In retrospect there are a few things I did well too of course.  I feel that I built a great brand and a quality product,and really built a few truly great features that would benefit the users and create a compelling community.  But they were all product focused and supply driven. I needed to pay much more attention to market demand and should have let the demand lead product design, development, and promotion.  I would implore any young entrepreneur (particularly the engineering types) to become a student of Lean methodology, as it is a powerful study in this idea of demand-driven development.