iFinity Blogs 

You are going to use a CMS for that startup, aren't you?

by Bruce Chapman on Tuesday, April 17, 2012 8:55 PM

My blogging has been a bit patchy in this first quarter of 2012, as has my open-source output.  The reason for this is that I have been involved and working on a new startup project that should hopefully launch soon and prove to be a big success.

The investors behind the project hadn’t done a web startup before, so they obtained the advice of the first person they found. I don’t really know the history behind this choice, and it scarcely matters now anyway. By the time I arrived, technology choices were in granite and the runway end was fast approaching.

Upon arrival I was disappointed to find out that this was what I call a ‘scratch build’.  The first person on the project literally went into Visual Studio and said ‘New Project…’.

The first question I asked was ‘did the original person who chose this technology consider using a CMS of any type?’.  The answer was ‘Yes, but it was ruled out’. 

Again, there is little value in turning over old rocks when there is a project to finish and the answers make no difference to the outcome of that project.  So I have left it at that.

But I wanted to do a little analysis of this in case the topic ever comes up again with anyone else.

The true cost of scratch building

When you get to see the invoices for time that get paid to developers for building the different components of a fully functional subscription-based website, you get a good insight into how much ‘scratch building’ costs.

What I have done is go through and develop estimates of how much time has been spent developing different subsystems.  Note that none of these subsystems are the actual bulk of the work.  They are just the peripheral bits and pieces that go into the bulk of sites of this type.

As my personal CMS of choice is DotNetNuke, I’ll consider some of these features alongside their DotNetNuke equivalent:

Built Feature DotNetNuke Difference / Notes
Membership System*(login,register,forgotten email, etc)

Approx Time Taken:
60 hours of development time, email templates, custom mail sending code, skinning

Templated Emails.

Approx Time needed:
8 hours of installing and editing emails
Additionally, DotNetNuke has option of custom login modules.

52 hours longer
Probably still more bugs to find.  May yet require Facebook login integration or similar.
Scheduling System

Service to run scheduled tasks in the application.

Approx Time Taken:
15 hours of development for a Windows scheduled service, configuration to make scheduled payments, send emails, etc


Includes reporting and control.

Approx time needed:
0 hours
The DotNetNuke scheduler doesn’t require any extra software to be installed on the webserver.

15 hours longer
Event Log

Implementation of text-based server log using open-source component.

Approx Time Taken:
10 hours of implementation


Easily extended for custom applications through creating new event types.

Nothing to build, all exceptions captured and logged, custom logging done in one line.
The DotNetNuke event log includes the ability to view remotely through the admin pages of the site, and can be filtered for different types of events.

10 hours longer

Implementation of MasterPages design.  Conversion of designer-specified Html into .aspx pages.

Approx Time Taken
(excluding designer)
40 hours.

Install skin through menu and apply to pages as needed.  Completely separate from code.

Approx time needed
8 hours (to refine and apply to different pages)
DotNetNuke skins can be developed by a designer in Html and then converted by the platform itself into a DNN Specific skin.

32 hours longer.

Menu System

Design and implementation of a 4-level menu system and breadcrumbs for all pages.
Static and requires config changes to add/remove pages.

Approx Time Taken
40 hours

Built-in.  New choices in providers such as Mega-menu.

Approx time needed
1 hour
There are many different menu styles to choose from.  Menu designers can quickly and easily setup the styles.  From then on, you just choose which pages go into the menu, and where they go.

Easily adjusted by the owner of the site.

39 hours longer
Content Display

Creation of a way to allow authorised end users to edit site content.

Requires separate WYSIWYG Html editor and FTP program.

Approx Time Taken
(excluding authoring content)
35 hours

Built-in, including different content for different authentication levels.

Approx time needed:
0 hours
DotNetNuke Professional versions include a content staging solution for approving content for live sites.

35 hours longer

*note: the system is using the same asp.net Authentication provider that DotNetNuke uses.  This saves a significant amount of time, but there is still a lot of work in plugging all the ASP.NET components into an overall site, and refining the plainly-awful default ASP.NET designs.

There is more I could list.  Search engine sitemaps.  Analytics integration.  Caching for performance. Administrator control panels.  User administration – if you want it, it all has to be built while the CMS packages it all up for you, tested, debugged and ready to use.

To save you adding up, the calculated extra time taken is 183 hours.  Even to me, this sounds very conservative, as I’m just extracting the information in a rough manner from management reports.

But let’s turn that into dollars and time, the two singularly most crucial data points for any startup.   Let’s assume you can average a developer hour at $100/hr – that is an extra $18,300, and close enough to 5 weeks of extra time.

Some people in large organisations might laugh at that- $18k is probably their stationery bill – but in a scrappy small startup watching the pennies it is an enormous amount.  More crucially, every week the product isn’t launched is every week revenue doesn’t come in, and gets closer to the time when the runway end appears and the investors get nervous.

Where does the platform really end?

When building a project like this, it’s amazing how cheaply a site like this can be put together.  A similar startup ten years ago would have needed a 7 figure bankroll to get the same amount of functionality in the same amount of time.  Open source libraries, Microsoft helper code – it all helps to put something together quickly.  We’ve leveraged jQuery and jQuery UI, used Knockout.js to give great UI interactions, leveraged email and payment provider libraries to speed up things immeasurably. 

The point here is that when you’re already using open-source libraries to speed up development and improve quality, then it’s bizarre to draw the line at the actual project itself.  Everything on the web runs on a huge stack of layers, so, in my view, it isn’t productive to dip down and build one more layer when a suitable candidate is there.  Nobody actually contemplates writing their own version of jQuery now, so why the actual Web Application?

But - It’s more than the cost

At this point, someone who was sceptical of implementing a CMS as a base for a startup might reasonably come back with ‘yes, but how much time would adapting the design to the CMS have cost’.  This is a fair point and one that needs expanding.  If you start with CMS-inexperienced developers, you may find that this time difference is soaked up in the developers trying to get their head around building an application on top of a CMS, instead of just creating a new codefile every time they need a new feature.

It doesn’t need to be like that, though.  The pool of developers skilled in a platform like DotNetNuke is pretty vast, and pretty deep.  And even if you’re a bit green, there are endless online forums, Q&A and other resources to tap into.   Code is code, no matter where it is written, so adapting to a different way of display is very low cost.

My hypothetical sceptic might come back and say ‘but yes, now you’re tied into the project’.  This is true.  Your future and that of your donor CMS are now one and the same.  But that is why you would choose and open source solution like DotNetNuke.  Even if the entire project disappeared off the face of the Earth tomorrow, you’d still have all of the source code, all of the things required to build it, and you could continue to move forwards.   But I’ll throw it back the other way, without a major platform, you don’t get any new features for free.  You don’t get lots of people finding security problems and patching them for you.  You don’t get a vibrant developer community trying to push things forwards continually.

A scratch-built solution has a talent-pool of a handful of developers deep.  When one of them walks out the door and onto other pastures, a ton of knowledge leaves with them.  This type of hidden reef is impossible to calculate in terms of cost, but it can be quite significant.

It’s also about the future

Already, the project is thinking about the future past launch day.  If all goes well, there will be plenty of site members and plenty of activity.  It’s about then that new ideas for site features will start popping up.   What about a company blog?  How about some social features to let users of the system compare notes, talk to each other, build a community?    With a scratch-built site, it’s back to square one.  With the authentication system built in, trying to tie in a stand-alone forum system would come across as clunky and poor.   Creating single-sign-on between different codebases is difficult.  Harmonising design is troublesome. 

And that’s when a CMS like DotNetNuke really pulls out into clean air.  In the next couple of months, the platform will release the long-awaited Social Features and a new Services layer.   There is no way an individual team can possibly compete with a team of fulltime developers working on a single feature like this alone.  The startup site could really use some of those social features like the new Journal module.  But there is no way it is ever going to happen, save maybe for a buyout by Facebook like some others.

A Virtual Comparison

Perhaps the best way I can put it is this: if two teams funded by two different investors worked on this same project, and one decided to use DotNetNuke as the base, and the other decided upon a scratch build, the one based on DotNetNuke would be to market by now, with more features and less bugs.  And they’d have extra cash saved over for promotion.  They’d even have a ready-built community to show their new site off to for feedback and perhaps the first customers!

It’s pretty obvious to me which one would be the eventual winner.  The ‘Not Invented Here’ syndrome is a costly one to acquire.

So I’ll ask the question again, in case you’re just starting out and chewing over this question : You are going to use a CMS for that startup, aren’t you!

Blogs Parent Separator Crafty Code
Bruce Chapman

The craft of writing code. The outcomes from being crafty with code. Crafty Code is tales from the coding bench.

Bruce Chapman
Hi, I'm Bruce Chapman, and this is my blog. You'll find lots of information here - my thoughts about business and the internet, technical information, things I'm working on and the odd strange post or two.
Connect with Bruce Chapman on Google+

Share this page
Get more!
Subscribe to the Mailing List
Email Address:
First Name:
Last Name:
You will be sent a confirmation upon subscription

Follow me on Twitter
Stack Exchange
profile for Bruce Chapman at Stack Overflow, Q&A for professional and enthusiast programmers
Klout Profile