web notes - a blog

If you are considering a web company, check their site. Do you like it? Does it look good? Does everything work well?

If you don’t like their site, you may not like the one they build you.

If you do like the site, ask them the following questions:

About how many person hours went into the site?
If they can’t answer this, they may not manage their projects well. Usually, the company site is handled as an informal project, interleaved with client projects. Professional service organizations are selling labor, and should be tracking ALL hours - whether they bill them to clients or not. That’s good business.

About how much would you charge a client for a similar site?
This number should be reasonable, and in line with the earlier answer.

What percentage of the project hours are management/overhead?
High caliber technical teams need less management.

There is a vast amount of information on the web, publicly accessible. Qualified observers can assess the technical skill of a web company by looking at a site and the page construction, they can perform complex analysis using validators and sites like http://websiteoptimization.com. They can easily determine the versions of software in use (unless security was done carefully), they can check how many sites have the same IP address (same server).

Clues:

Old versions of everything - site is not currently being maintained. Opportunity for maintenance and hosting upgrades. This can be very low risk if a robust application is in use, and it hasn’t be heavily customized. Same is true for copyright notices.

Broken link to web company - see above.

Poor design and application integration, broken links, missing images - site visitors have high expectations. A bad site can cost a company alot in lost business. A quick link to a demo may help the site owner see the value of your proposal.

Glaring security issues - it is easy to quickly check a site with non-destructive SQL injection testing and invalid data testing, as well as simple certificate checks. Alert the site owner with a screenshot or URL that demonstrates the vulnerability as well as a quick description of possible resolutions.

Scanning sites for information such as older versions of Apache/PHP and applications is reasonably cost effective. A few innovative email templates should allow a professional message to be delivered to prospective clients.

Finally, most sites last about 3 years before they need to be refreshed, improved, redesigned.

LinkedIn (and other professional networking sites) make alot of information available.

Want to know the organizational structure of a company? You can probably build a pretty good org chart using just LinkedIn.

What to know the interaction patterns? See who is connected to who. Who has alot of connections. Who has only a few connections.

Want to learn about the company? Look at the descriptions, what people said about the work they did and do.

Want to assess the qualifications of employees? Many people post their education and experience.

Want to know about turnover? That information is there as well.

Check the links posted, particularly blogs, to gain more insight.

Want to know more? Search the web for those names.

This information would be helpful for prospective employees, people that are considering purchasing a company, and people involved in ownership transfers, as well as potential customers.

The web is constantly changing and keeping applications on servers which can support them may be difficult, as hosting companies upgrade the servers to improve security, the applications may fail.

Most web companies are extremely careful and use strategies such as running PHP 5 through php5 extenstions, and leaving PHP 4 as the default, but there does come a time when the server has be upgraded. In addition, it is the responsibility of the application installer to ensure the application is maintained for security and performance.

This creates an excellent business opportunity for web companies, especially for powerful applications with complex hosting requirements, such as eZ publish. The key is careful identification and management of the opportunities.

Once identified, one must look at the site to try to assess the quality of work. Upgrades can be difficult, so the offer to upgrade an eZ installation should be made carefully - so all parties understand the risks and estimated costs.

Bear in mind if the application is running from a subdirectory, this strategy may not work. That’s okay, there are lots of other sites. :)

This approach will work for any application that provides identification information in a publicly accessible area (either the headers or the HTML). It is especially valuable for applications with steep learning curves.

Use curl or wget to get the site headers or HTML.

Using RPMs to install open source toolkits such as dojo, Smarty, and Zend Framework allows hosting companies to create a cost-efficient architecture to offer clients servers ready to support RIAs and sophisticated sites.

This may improve security by allowing the hosting company to prevent clients from modifying open source products. Access to the code can be provided easily through the use of symlinks. Account setup can be automated with server management/admin software like WebHostManager and Plesk - by customizing the account setup scripts with additional RPMs.

Advantages:

• Significant savings in disk space
• Elimination of installation at the account level
• Permission management performed at the server level
• Ease of toolkit maintenance, a single installation can be upgraded for the whole server
• Offering an RIA ready server is a valuable service that may be delivered in a cost effective manner. It may be an offering that makes one hosting company more attractive to clients than another, in other words, good business sense.

Disadvantages:

• Changes to the toolkits will affect every site, thus they cannot be changed easily, and upgrades may be disruptive. However, based on the assumption that this code should not be modified, and upgrades are often security related, synchronizing the toolkits across the server is reasonable.
• An excellent understanding of the server architecture, software, and RIA toolkits is required for a graceful implementation.