We are starting a new series called Drupal hacks and solutions. This is going to be a useful collection of how-to’s and code examples, based on our experiences.

I am sure every Drupal developer out there has his own ways of styling Drupal (which as http://bomshteyn.com/2010/01/03/should-you-use-wordpress-or-drupal/ discussed is not always an easy task), we are just going to write up the cases that we encountered and solutions we used.

As always there is an easy way to do something and a proper Drupal way of doing the exact same thing. Whenever possible we try to do it the Drupal way, and would advise you to do the same, but i have to admit thats not always the case, and i would sometimes insert a SQL query into a template instead of properly using a drupal function of some sort.

It’s almost a year now since I started working on our first Drupal site; over time I have learned, and continue to learn, new “proper” ways of programming in Drupal and working “with it” versus “around it”.

As you work on a project you have a problem and find a solution, but by the time you get around to the next project and encounter a similar or even same problem (the latest project we were working on was approximately 400 of programming hours) you no longer remember how you solved it last time. In theory you could just open the last project’s code and find the solution, but sometimes its easier said then done, first you have to remember in which project you had this issue and second since an issue in Drupal could be fixed on so many levels (core, theme, modules….), where to look becomes an issue by-itself.

So here we are faced with a case of our own that needs a solution.

Our first urge was to create an internal wiki where we would write down this type of stuff for future use – knowing first hand how hard it is to find an up-to-date solution to some very common problems in theming Drupal. Plus the fact that we always wanted to give back to the open source community of Drupal. We decided to do it as a blog category on our site so that it would be searchable – not just internally but by the whole ever growing Drupal community. As a starting point we will give you an example post, so that you know what to expect.

How to add a custom login box into your Drupal theme

You will probably want to show this only for non logged in users so here is an example of the code you would use:

<?php
if($logged_in){?>
// put some code here
<?php } else {?>
<?php  global $user; ?>
<form action=”<?php print $front_page.’user/login/?’.drupal_get_destination();?>” method=”post” id=”user-login”>
<label for=”edit-name”>username</label>
<input type=”text” name=”name” id=”edit-name” value=”" tabindex=”1″/>
<label for=”edit-pass”>password</label>
<input type=”password” name=”pass” id=”edit-pass” tabindex=”2″/>
<input type=”hidden” name=”form_id” id=”edit-user-login” value=”user_login” />
<input type=”submit” name=”op” id=”edit-submit” tabindex=”3″ value=”Submit” alt=”Submit” />
<p>Forgot <a href=”/user/password”>password</a>? &nbsp; Or <a href=”/user/register”>Create New Account</a></p>
</form>
<?php }?>

3. Manage Scalability

Like all rapidly growing applications, Farmville has scalability issues – as of this writing, they are working on a serious issue pertaining to how the application loads.

Any rapidly growing application has a tendency to run up against physical limits to both the design of the application and also the underlying hardware on which it is running. The result is that at each order of magnitude of growth in traffic, significant work may be required in order to redesign the application. In the meantime, it isn’t uncommon for these kinds of apps to have outages, extreme slowness, or bizarre and unscripted behaviour.

What Zynga has done is to appropriately deal with user expectations: firstly be explaining what the situation is, and secondly by compensating users (in this case via free game items) for the irritation. It is surprising how many companies will try to either hide or deny outages due to scalability issues.

4. Make Money

Making money out of a busy website or application is harder than it may seem.

The “throw something up on the web and put ads on it” model hasn’t worked well in a number of years (yes, I also know a few people still successfully doing this – just try duplicating it from scratch now).

This means that a company that is successfully making money online is worth analyzing in more detail. I don’t know how much Zynga is making (they’re a private company), but from what I’ve read they’re profitable.

Say what you want about the morality of selling virtual items via micropayments, the model appears to work well – at least for the most addictive of online games.

Farmville has two types of internal “currency” for purchasing items in the game:

One type of currency is easily earned within the game, and can be used to purchase the most common items.

The “premium” currency – which is usually obtained through a micropayment (although small quantities of it now circulate within the game as well) – can be used to purchase a variety of premium items that either make game play easier, or convey some form of status.

This model allows people to play the game without having to buy anything, while allowing the most enthusiastic players to essentially subsidize everyone else.

This “freemium” business model works at a similar psychological level to the old “shareware” software licenses – people can use it for free, but also feel like there is some level of obligation to pay, based on their own perceived value of the app.

5. Multiply

On a fickle internet, success may be fleeting.

If a website attracts significant traffic – and money – they need to immediately start planning the next step.

It appears that Zynga realizes that there may be inherent limits to how big a specific web game can get, and that their approach also includes the notion of continually duplicating their success with new games – particularly using cross-pollination approaches such as using familiar characters.

Duplicating a successful methodology over and over can be a useful means of sustaining viral success – particularly if one is skilled at redirecting existing “customers” to the next big thing. By building all of their games around a standard platform – in this case Facebook – the development time to create new apps is reduced. There is also a consistant user interface between the apps, allowing for faster user adoption.

If you play Farmville, you will quickly notice that Zynga has posted advertising at the top of each page for their other games. The objective is to “cross-pollinate” the user list from their various games (my understanding is that they are now running a large number of games on Facebook and other platforms).

One trick – which they don’t seem to be using right now – would be to allow users to utilize the same game currency across all of the games on their platform. I’ve seen this used in practice elsewhere.

Two last things that they appear to be doing well: a)  Zynga developed certain iconic characters for Farmville (i.e. the cartoon animals), and they have used these animals (and similar characters) in other apps that are directly marketed to the users of Farmville. In addition, b) they rapidly create competing products whenever another development team builds a game that could move into their marketspace – and they make an effort to improve on the original. The second company into a market can do very nicely indeed – just think of the Beta vs VHS wars.

In the final part of this article, I will wrap things up and provide some other examples from other businesses. To be continued…

2. Let Everybody Know

If you’re on Facebook, you are familiar with the extent to which Farmville pesters people who aren’t already playing it. I had actually blocked the application at one point, and only logged in after reading about how it had attracted 70 million users on a mainstream press website – which actually proves the idea that in advertising, repeating your message ad nauseum actually does pay off. Eventually.

What Zynga have done with Farmville is create a system that provides an immense number of opportunities for people who are already using the game to gain by telling other people about it. In addition to bugging people who aren’t already playing, it also provides – as mentioned above – innumerable ways of reminding people who are already playing it about its existence. This can be irritating, but it is clearly an exceedingly effective methodology for growing traffic.

A small number of the methods that they use to spread the news include:

• Constantly requesting users to post announcements to their “streams” – every time a user achieves a milestone in the game – no matter how small – Farmville asks the user if they want to place a post on their stream (the list of updates shared between “friends” on Facebook). These announcements are essentially sales referrals – if somebody not playing the game sees hundreds of such announcements from their friends, possibly it may pique their interest.
• Many posts from Farmville contain image “snapshots” of what a user’s farm looks like. These follow the notion of “show me, don’t tell me” – a picture is worth a whole lot of verbiage.

3. Build a Community

As mentioned briefly in Part 1, the notion of a community is very powerful in social networking applications. If the people that you are friendly with are all involved in a particular community, not only are you more likely to join, but you’re also much less likely to leave. Real world examples include religious institutions, multi-level marketing organizations, social clubs, charities etc etc. Many such organizations fulfill a social role in addition to any other role they may play, and for their participants this can be a powerful motivator.

The vast majority of online social applications pay lip service to the communal role – but in actuality they provide little incentive (or supportive functionality for that matter) for people to actually interact with each other.

One of the key reasons why Farmville has been so successful is that the communal aspect has been so well thought out – not only are there endless ways for people to interact in the game – it is difficult to progress without doing so. A few examples (and there are probably dozens of others) follow:

• Neighbours – the game plays up the folksy notion of farmers chatting over a picket fence. Members can add other players as virtual neighbours in the game, and thereafter the game visually renders the neighbouring farms next to the player’s farm. Players are encouraged to visit their neighbour’s farms, and to participate in building up those farms via simple tasks (fertilizing their crops), for which they score points.
• Many items in the game cannot be purchased from the “market” directly – they can only be given as gifts. Players are encouraged to give such gifts to their neighbours, and the receipt of such items triggers a polite request to send something back.
• An interesting recent feature – barn raising. A player wishing to build a “barn” with which to store items can pay for the barn directly – or get it for free if ten of their neighbours are willing to help them. The process involves a large amount of voluntary messaging being posted to streams – and people’s in-boxes.

[To be continued in Part 3...]

I’m not generally recommending that you drop everything and play Farmville, but there are some interesting business lessons to be learned from the game. Possibly this blog entry will save you massive amounts of time – i.e. you can simply read on, rather than playing.

If you’re on Facebook, you’ve probably already been pestered by notifications from a game called Farmville, created by a company called Zynga. Possibly you’re already playing the game yourself. Over the past few months, the number of people playing the game has exceeded 70 million – for comparison’s sake, this is roughly the same as the total number of people using Twitter. Clearly they’re doing something interesting.

Generally speaking, Farmville falls under the category of “viral applications”. A viral app is one that seems to spread uncontrollably – just like a cold or flu bug does.

The key to “virality” has been documented elsewhere to great effect (just visit your local library or favourite guerrilla  marketing blog):

• create something that is going to keep people interested (what’s usually called “stickiness”).
• make sure that using it will work even better if the user tells their friends about it.
• seed the application, website, or whatever with an initial set of users – probably friends of the owner.
• watch it grow.
• deal with scalability issues
• figure out how to make money (!)
• reproduce / duplicate the effect elsewhere

Very few applications make it to the final step, and there is definitely at least some element of luck involved – I’ve seen some great ideas fall flat for no apparent reason.

What Zynga has done though is a very interesting example of a successful viral application, and there are a number of attributes that can be used elsewhere – not necessarily for games either.

1. Keep People Interested

The notion of keeping people constantly interested in an application is very helpful in building a virally marketed website or game. The longer a person’s attention is on something, the more opportunities the makers have to get them to tell other people about it, as well as there being more likelihood of selling the user something. Keeping people interested is not conceptually hard, but can be difficult to implement in practice; I’m seen a great many websites fall short in this regard. “Viral” without “sticky” often equals “flop”.

Zynga have done a few interesting things with regards to holding people’s attention. Some of them are general rules from the game builder’s playbook, and thus aren’t transferable to all products or services.

Some of the tactics include constantly changing items, seasonally based differences in the appearance of the game, new functionality as a user progresses in level, randomization (things like animals moving around on their own) – these are all things common to many successful online games. Maintaining a stream of new activity is actually quite difficult to carry out – as I’ve discovered in the past while working on other games. There’s a certain level of perseverance involved, along with rallying the developers – most of whom are probably feeling burned out at this point (again, past experience) and keeping the creative juices flowing.

Other interest-enhancing features include their gift exchange system – I’ll talk more about this in Part 2 – which a) ensures that certain things can only be accomplished with the help of friends, and b) provides a stream of requests to players inboxes to entice them to come back repeatedly.

Two last things of note:

By building a community, where players cooperate in longer term development with each other, Farmville makes it less likely that somebody will drop out. Community formation is a powerful tool to keep people coming back over and over.

Farmville also relies on people’s nostalgia for “the simple life” – not that farming is particularly simple in actuality.  The nostalgia factor can be a powerful tool for marketing to particular market segments.

[To Be Continued...]

We’ve recently had to convert data from an old custom-built shopping cart, to a new website based on Drupal and Ubercart. The old website had approximately 5000 products, with a data structure that was completely unlike the one used by Drupal to store data. We initially tried using the Drupal data loader module, but as other people have discovered, it isn’t necessarily a good fit for loading Ubercart product data, particularly when the products have images, or – and this is especially the case – custom data fields.

You can download a copy of our script here.

In the end, we put together a custom php script to pull data directly from one database to another. The script is fairly crude, but it may be useful to somebody trying to import data into Ubercart from another non-standard system.

As a result, I will link a copy of the script below. Please bear in mind that a) we accept no responsibility  whatsoever for its use (i.e. back up your databases first!!!), and b) while we have documented our assumptions, this is a crude script that is specifically designed for our particular needs. Be that as it may, you may be able to find a use for this.

Additionally, it was a pain just getting a list of the Drupal and Ubertcart tables that needed to be looked at in order to do the data conversion. The list below may be useful to you as well.

How it works:

The old shopping cart had two relevant tables: a category listing (hierarchical), and a products table, which included some customer specific fields, as well as a single url to a product photo.

Drupal/Ubercart, on the other hand, uses a large number of tables to represent the same data. This is because products use the same node-based system as the rest of Drupal, in addition to a number of product specific tables.

In addition, product images are dealt with using Drupal’s file cacheing system, which is relatively complex in nature. All in all, our data goes from two tables to approximately nine (depending on your specific needs) in Drupal.

The script has some handling – very buggy still – in place for keeping track of the current position in the old database. This means that you can run the data conversion in small chunks, checking at each point to see how well it is doing. You can also set how many records to convert each time. In order for this to work, a very simple table to track the record pointer needs to be added into the old database.

We did not cover the conversion of product categories, since typically there are a much smaller number of categories than products, and in addition, the Drupal data loader does a reasonably good job of loading them.

List of tables involved:

• node – in Drupal, everything is a node, including products. Each new product record will need a corresponding node of the correct type.
• node_revisions – this table contains much of the actual textual data (i.e. product description text) involved in displaying the node.
• content_type_product – if you need to create custom fields for your Ubercart products, the data will go here. Our code in this section will probably not map directly to what you’re working on.
• uc_product – where the product records “live”. There will be one record here for each of the product nodes.
• uc_product_stock – contains stock-related data (i.e. how many of the product you have on hand etc) for products.
• files – each product image needs to have a record in this table, which stores the file names and locations – but does not map these images directly to the product records (you need another table for that!).
• content_field_image_cache – this is the mechanism that ties a product image to the underlying product. We didn’t really try to work with Drupal’s actual cache mechanism, so after you have loaded the products, you may want to clear the cache.
• term_data – this is where product category information resides, based on Drupal’s vocabulary / hierarchy system. We hacked the solution in a fairly inelegant way – by doing a category name lookup to retrieve the term id.
• term_node – a connection table between a term (i.e. a product category) and a node (in this case the products).

Base assumptions:

• We assumed that the old and new websites both have mysql databases.
• Both databases will probably have to be on the same server (or at least one of them needs to be externally accessible if that isn’t the case)
• The script should be uploaded and run from the new website’s location.
• We assumed that there is only one product image per product – although this would be fairly easy to modify.
• We manually added our categories to the new website
• We manually moved product images across – there are comments in the script where you could automate this though.
• Error checking is extremely rudimentary; if this scripts hits a problem it just stops.
• If you hit data conv snags, the fastest way to proceed is to restore your backup database, reset the pointer record, and start over.

In Part 2, we covered some of the stages during development and just after the launch of a website.

8. Operations

I’ve frequently seen websites launch successfully, only to lose steam rapidly, once the obvious difficulties in actually running a web-business come into play.

Operating a successful web-based business can be a lot of work, no matter how much effort is placed on automation.

A website that sells a product can have a major time committment required in order to fulfill orders (i.e. package them up and mail them), or to answer queries.

Content-based sites can be even harder to maintain, particularly when the general public has the ability to participate in the content creation process – large social media sites often have a significant number of staff dedicated to removing content that contravenes the terms of service.

I’ve recently worked with several customers who have partnered with fulfillment centers in order to offload a portion of the order fulfillment process onto specialists. The websites have been designed to integrate with the fulfillment center’s systems in order to keep the order statuses current. I’ll eventually post an update here when I’ve seen how well this works in practice.

Creating a plan – possibly even as early as the business plan stage – for how operations will work, the amount of time needed to keep a website running, and whether any staff are required for this purpose (and particularly how much that would cost), is an effective way of making sure that the resources will be in place to run things after launch. It also gears owners of web businesses up for the long, ongoing task of running an online business.

9. Maintenance Cycle

Image by akseabird via Flickr

Most web developers approach the ongoing maintenance of a customer’s site as a form of additional revenue after a project has completed.

Few owners of websites appear to budget for ongoing maintenance related issues – which could include bug fixing or building additional functionality – before or during development.

For developers, there’s a risk associated with the maintenance cycle, given that an ongoing series of invoices (unless well justified) could result in the customer leaving for another development company.

Ensuring that new owners of web businesses understand what is involved (particularly with regards to costing) in maintaining a website over time will go a long way towards forging a better partnership between developer and customer.

10. Creative Destruction – When to Scrap It and Start Over

I’ve worked on a number of websites where the site had some initial success, which dropped off over time. Unfortunately some products are faddish in nature, which means that there is a very well defined life cycle for the product.

The products or services sold by a website may not be the only things subject to this inherent life cycle.

A website built today may not work as well in the future. Technologies change, people’s design taste changes, and websites do become outdated over time.

As some point in time, a decision may need to be made to scrap a site and start over.

This often seems to happen on an ad-hoc basis, where a customer becomes infuriated with a developer and leaves for another web development company; the new company will typically try to sell a complete start-over, as opposed to modifying somebody else’s work.

By ensuring from the start that customers understand that there are inherent lifespans involved in a web business (just like any other), developers can potentially develop a longer term relationship with their customers that lasts beyond a single project.

Conclusions

There are a few quick conclusions that can be drawn from all of this:

• A web business involves a lot more than just throwing together a website and putting it up on the internet. If you ignore the fact that its a business like any other, you may be setting yourself up for failure.
• Web development companies are only part of the “supply chain” involved in building a successful web business. Other companies that are often involved include: business consultants, accountants, lawyers, loan companies or investors, PR people, SEO/SEM companies, supply chain management or fulfillment centres, phone support companies and many more. It makes a lot of sense for web developers to cultivate relationships with each of these kinds of companies, in order to be able to provide a full “package” to their customers.
• It takes time and extended effort to build a successful web business. Both you and your vendors need to have tenacity, because a lack of staying power won’t cut it. Despite anything you’ve seen in the news, most successful online businesses are the result of many, many years of hard work.

In Part 1, we discussed that websites need to be viewed from the perspective of the business cycle, rather than as a simple project.

4. Design / Implementation

There isn’t all that much I can add regarding the design and implementation phases of a web project. This is the technical portion of the project, and the business-owner is somewhat at the mercy of the skills of the people that have been hired to build the site.

Web developers can use this phase as an opportunity to obtain feedback from customers early and often, which may reduce the amount of time involved in the testing and “Beta” shakedown period after launch.

5. Testing

Image via Wikipedia

I know of few web development companies that have a formal testing process in place.

Part of the problem is that testing is labour intensive, and requires a particular nitpicky mindset that developers seldom choose to acquire.

If web projects properly budget for the testing phase (including adequately estimating the amount of time involved), then more options become available, including hiring staff specifically for this purpose, or utilizing a third-party testing company.

This avoids the prevalent (I’m guilty of this too sometimes) practice of pushing a large chunk of the testing process onto the customer.

6. Launch

Typically the launch of a website tends to be greeted with a lot of fanfare.

If the owner has engaged a PR company, there can be a significant buzz attached to the initial launch.

The critical things to bear in mind are that a) the buzz may not correspond to a significant number of sales, and b) there needs to be a committment to work at building the business after the initial buzz wears off (which it usually will).

I’ve seen a lot of sites launch well, only to founder later on.

Its critical not to confuse the big launch with the lengthy hard work of building an online clientelle, which may take years (just like with a regular “real world” business).

Tenacity pays off! Do not be discouraged if things don’t immediately work on launch!

7. Building Traffic – PR, SEO, Organic Growth and Networking

Image via Wikipedia

There are quite a few factors involved in building traffic to a website over time.

A quick point before discussing this important issue: the “conversion” or “closing” ratio of your website – it isn’t any good to obtain a large amount of traffic on your website if you aren’t turning that traffic into sales (or some kind of revenue anyhow).

Keep a close eye on the closing ratio (i.e. percentage of visitors that result in revenue) over time, and don’t be afraid to change aspects of your website if things aren’t working.

I find that tools like the “Funnels” system built into Google Analytics do a great job of showing where a website is losing people.

I’ve seen a decidedly mixed bag of results in the past from both PR companies and SEO (search engine optimization) people. I’ve written a bit in the past on both topics, so I won’t go into a lot of detail here.

Generally the process of building a significant amount of traffic on a website boils down to continually promoting the site over a long period of time; this is particularly the case where a business is looking for so-called “organic growth”, which basically means people just finding the website randomly, due to it being frequently referenced elsewhere.

The process of building organic growth often is a result of “networking” with the owners of other websites. This takes both hard work and a willingness to give and take. Note: I’m not talking about lame “link exchanges”, but rather the more “blog oriented” approach where people discuss each other on their sites. An example would be somebody discussing how much a like a particular site, or how an interaction with somebody at a web-based company went. You can’t beat that kind of press.

As mentioned above, I’ve worked on a number of projects over the years where various PR companies were engaged in order to promote projects.

My experience has been that PR companies tend to have specific areas where they shine, and promoting websites isn’t something that all of them do well. Partially this is because PR is oriented towards short term promotion of products, or finding ways to plug something newsworthy (and hence time-limited).

If you can find a PR person who has staying power, and can keep doggedly plugging away at something long after it becomes boring – stick with them, as they are rare.

Its also been somewhat evident that there are many PR people out there who are primarily good at promoting themselves. I don’t have much ability personally to see through “BS” of this nature; my recommendation would be to get some references for previous jobs that are similar to yours, and take the time to call them.

SEO is also something of a mixed basket.

Search engine optimizers and marketers tend to specialize in particular areas, for instance Pay Per Click, On Page SEO, Organic SEO, Link Building, Social Media Marketing etc. I don’t want to go into detail on the topic of SEO, despite its importance to newly launched websites, since I’ve written frequently on this topic before.

The key with hiring an SEO/SEM company is a) check refences, and b) start with a small, limited scale project first, and don’t be afraid to drop them quickly if they don’t deliver.

As somebody who has worked in this field, I’m also aware that there’s a similar effect at play to PR people – over time the effectiveness of a specific technique may wane, resulting in a loss of interest on the part of the SEO people involved. When this happens, it may be time to move on.

To Be Continued…

The problem is partially one of not taking a broader “whole life cycle” view of the website as a business in its own right. It may also be exacerbated by web developers who may be more comfortable with creative or software development, as opposed to a hard-headed business-oriented view of a site.

The issue is that a website is a business like any other, and that implies that there is more going on than its appearance or functionality alone.

Developers also need to resist the temptation to take the easy way out and just implement whatever the customer asks for. This may require developers to pick up some business-oriented skills in order to provide a more professional level of service for their clients.

A look at the full cycle involved in building a website – or more accurately a web business – gives a wider picture that may suggest both areas for improvement on the part of developers, as well as a more realistic set of expectations from business owners.

The “Whole Life” development cycle starts long before anybody discusses what a website is going to look like, and continues (often for years) after the site has been launched.

1. Concept

Frequently, the initial concept for a website originates with the business owner.

In many cases, they take their flash of brilliance and immediately start trying to build it.

A quick feasibility study may be in order though.

This may consist of a quick Google search to see if there are competing products, or bouncing the idea off a trusted friend (I’ve encountered people who are incredibly paranoid about protecting their ideas, regardless of whether the idea is actually valuable or not).

Where web development companies come into this is in the area of professionalism: it isn’t easy to tell a potential customer that their ideas are terrible, or to try and make them modify their concepts in order to allow them to work better online.

Part of that is that developers and designers are by nature creative people, and we don’t like raining on somebody’s parade.

Part of it is also the risk of losing a possible customer.

Yes, this should be done tactfully (that could be a complete article on its own), but if we don’t address this up front, it creates a larger likelyhood of the project blowing up in our faces later on.

Attempting to adjust expectations mid-course isn’t usually much of a solution.

2. Business Model / Business Plan

This is a neglected area with new web businesses, and one that could provide additional revenue for development firms that are willing to learn new skills – or work with other companies that have the skillset.

Frequently new websites are built and launched without a hard look at how they are going to make money. “Oh I’ll just build something and throw ads up on it” or “I’ll have a shopping cart so people will buy things” don’t hold water any more – if they ever did. I’m still amazed at how many people I talk to still think along these lines.

Want a successful web business? Start with a well defined model for how it will make money. Then put together a business plan (and possibly a marketing plan).

A well-crafted business plan can take a long time to put together (Factor at least 35 hours for a simple plan, and 6 weeks or more for a complex one).

If the web development company you are working with doesn’t provide this service (hint: my company does about 3 or 4 per month) then hopefully they have a relationship with somebody else who does.

The business plan may help later on as well, if you are seeking financing for your website.

3. Financing

If you are building a small website, the issue of financing probably boils down to giving the designer an initial deposit and then whatever you owe once its all done.

Larger web projects, however, can be expensive, particularly when you factor in the labour involved in custom graphic design or software development. This means that you could potentially need to look at financing options, in order to complete your project.

Most web companies are far too small to be able to provide sophisticate financing options for web development projects, so it is possible you’ll be looking around for a different way to put together financing.

The current financial situation has resulted in difficulties in obtaining traditional sources of financing (typically loans) for web development projects. As of the time of writing, (tail end of 2009) the people I’ve spoken to have had little success obtaining bank financing for business development of any kind, including web development. It is unclear whether this source of funding is still viable for web projects.

I’ve recently spoken to people in the business of brokering small (i.e. under $100,000) loans, which are typically unsecured. My understanding is that this type of financing still exists, if one is willing to hunt around to find it, and it one is willing to accept the terms as-is. Secured loans on a larger scale can also be obtained for development projects, but again the terms may or may not be acceptable. Personally I haven’t had any experience actually taking out a loan of this nature, so this is mostly based on discussing the topic with people in that industry; I haven’t spoken recently to anybody who has obtained this kind of financing for a project.

“Angel” or “Venture Capital” funding is another traditional (at least in a Dot Com sense) way of putting together financing for web development. I also don’t have personal experience with going this route, although I’ve had “nibbles” from local angel investors that I know regarding specific projects in the past; none of those has resulted in anything to date… Usually people in either of those areas are looking to buy a piece of the equity of whatever it is that you’re building, so your track record is going to be important to them (hence the business plan!).

One unusual source of funding for web development (or software) projects can be equipment financing companies. Many of the “captive” financing companies for computer hardware manufacturers (one example would be IBM Global Financing, but all of the large equipment manufacturers have them) will finance software or web development projects, provided that you purchase equipment from them as part of the deal. So for instance you could buy the servers required to run your site, finance them, and then roll other startup expenses such as off the shelf software and custom development that are also required, into a single loan.

By cultivating relationships with potential sources of funding, web development companies can add a powerful sales tool into their “kit”, which will allow them to land larger projects. This kind of relationship could also be extremely beneficial for lenders and investors as well, since web developers are frequently the first line of vendors to see newly launched concepts. I’ve actively cultivated relationships with companies in these areas for years as a result, and I’m often puzzled when a VC doesn’t “get it” – in their position who wouldn’t want a steady stream of pre-qualified applicants?

To Be Continued….