Application Development
Websites are largely a visual medium, so it is important that the visitor experience includes the elements of design: color schemes, high-quality graphics, and easily readable text, as well as usability and sensible navigation, all wrapped in a package that works equally well on different browsers.
While many websites are primarily focused on advertising and exposure, and are sometimes called "brocureware", many businesses have needs for online applications: programs that collect data, allow searching of databases, client logins, registrations, inventory control, online testing, accounting functions, reporting, product sales, etc. Since most such applications are quite different from each other, reflecting the specific needs of that business, these are not "drop-in" modules, but independent projects assembled by a programmer, following a (usually) well thought-out flowchart. The programmer may reuse small bits of code that he uses on most projects, but this is analogous to an architect using the same size or style of bricks on different buildings. In both cases, the finished product is assembled to entirely different proportions, and with different purposes.
Many clients who purchase websites are less knowledgeable about this area than about the more visual aspects of a site, and are thus often unaware of the process by which such applications are built and delivered, thinking instead that it must be a "point-n-click" operation. If that were true, you wouldn't need programmers, just a mouse.
Application Development starts with a Functional Specification, which outlines the purpose of the application, including all functionality, requirements for databases, administration, authentication, navigation, reporting, and related areas.
This may lead to, in collaboration with graphic designers, mockups and screen shots of all the relevant screens: login, register, input, search, results, purchase, or whatever the application requires.
The previous two stages may then be used to develop a flowchart, Use Case studies, and a UML layout, using the Unified Modeling Language, to further refine the relationships between the various functions of the application layer and the database layer. At this point, an estimate of the time required can be developed, so that a cost estimate can be presented to the client. If the client accepts, coding can begin.
The salient point here, is that almost 30% of the time required for building the application is expended before the client even sees the proposal. This is tedious, and expensive, but if a project is not pre-defined in minute detail, the client can be expected to ask for "small changes" here and there, which will invariably lead to cost over-runs at the best, and fragile, hard-to-extend (or even buggy) code at the worst. That doesn't even address the possible security and liability issues that may arise from changing the plans in mid-stream.
Back to the architect analogy, this is like the new homeowner asking to have the downstairs bathroom moved to the opposite corner of the house after the first floor walls are up and the framing plumbed. Even if it's possible, you won't like the result.
This is not intended to dissuade someone from including web programming in their website; if you need such functionality, you need it, but in order to get the best results, it is necessary that you carefully think through your business model, your short-term and long-term requirements, and any budgetary restrictions, to arrive at a scope of work that makes sense for your situation. We once had someone ask for a custom-built clone of eBay, for under $5000, when it could not be done for 10 times that amount. You don't want to be the person that someone mentions in an article like this two years from now.
