What Do We Do? Putting the Internet at the heart of your business. Request a Project Assessment Got an online project in mind? Get your free assessment of how we can help. A Personal Service Our team and your team, coordinated for success. Achievements & Expertise What are our strengths? What do our clients say about us? Our Development Process How we approach the site-building process, from initial consultation through to testing and release. How Much Does It Cost? HomePage's approach to project costing. Contact Details Email, phone and fax. Who's In Charge? Meet the principals at HomePage Home

HomePage has been building database-backed web sites since 1995, so we've got plenty of highly relevant experience helping us to build solid sites with none of the pitfalls common to less experienced developers.

Typically our development process has the following phases.

1. Consultation and project scoping

This is where we talk about the project, meet everyone involved and work out whether we'd be happy working with each other.

At this stage we'll give you our honest opinion on how well the project will work on the Internet and how we can help make it better. A good description of this phase would be creative brainstorming and making friends.

However, it's here when we'll try to understand the important data issues and work out a relational form for your database that will work at a reasonable speed on the web, and also discuss the most important issue of how the data will updated and maintained.

If you want to eCommerce-enable your site then we'll talk about the various options available. We've experience in interfacing with three of the UK's leading payment processors - DataCash, Secure Trading and WorldPay.

Next we'll consider the user interface and what technology and browsers the site needs to run on. We focus on speed and usability, not on fancy multimedia presentations, as when you want to interact and do business with someone, the last thing you want is a slow, self-indulgent web site.

Finally we'll discuss with you multi-lingual and multi-currency options.

2. Specification

The HomePage development process concentrates on strategic Internet services, and it's at the specification stage that the emphasis on strategy and results is important.

The wrong way to go about things would be to construct an unchangeable blueprint for the site's structure, design and functionality, with every single page on the site, every button, every graphic and every link laboriously mapped out. We have seen this approach used a lot - particularly within large projects where paperwork seems to count for more than results - and the upshot is nearly always a specification that is obsolete as soon as it is drawn, simply because it is a single tool designed to solve a single problem, and what's more, designed to solve it without any of the benefits of user testing, trial and error, and other valuable processes which form the real project specification - the one driven by the users of the site who, we find, know exactly what they want.

So we've found a better way: strategic specification.

Instead of specifying the entire project in a single document, we use the all-important initial consultation to understand what you're trying to do, and then write a specification document that says exactly what you want to achieve and how we'll go about doing it. Typically this will break the development down into a number of fully-costed options so you can see how much you want to invest. But if you're used to reading 'traditional' software development specifications then this isn't one - it's a broad summary of what we will do and deliver.

The important point about strategic specification versus a total functional specification is that it leaves room for manoeuvre. Our specification will completely specify the aims of the project and give you a full breakdown of costs and timescales, but it leaves HomePage with a free hand when it comes to the technologies to be used and the details of implementation, and essentially, it gives the client a free hand to change their mind during the process, to ask what-if questions as they occur, and to modify the project to suit changing business circumstances. Sometimes, changes may be introduced that involve extra costs, but on the whole we find that changes can generally be accommodated within existing project budgets, with an underlying advantage of flexibility which is simply not present in a project that has to deliver to a fixed specification, come what may.

3. Prototyping

In this phase we'll do three very important things:

• The first is to turn the data model into a real test database and populate it with the maximum amount of data that we anticipate the system will hold. We'll construct some sample queries to either search the database or insert any new data that the user of the site would typically do. We'll also do some performance testing and timing. If things get sluggish then we'll go back and redesign the database and then re-test until we're happy the site will run at an acceptable speed.
• Secondly we'll do a rough design of the user interface and the key screens, which will be in consultation with the client so that we know you're happy with how the site will look.
• Finally we do some work with your existing data sources to build data take-on routines and we'll also work with you to find the best way for you to keep the content of the site updated.

4. Phase One Development

This is where we build the site, develop the admin and web user interfaces, and author static content.

Although this is indicated as a single process, we typically split the development down into a number of separate phases and develop on a phase-by-phase basis, with 100% completion required for each phase before the developers move onto the next phase. In this way we can keep accurate control of the project to ensure that the delivery time doesn't slip.

During code build, changes to the proposed site/application structure will be evaluated as to how they would impact the current project. If they are a functional addition that can be developed later they will be scheduled for second code build. If they effect the current programme then they are evaluated and depending on the nature of the change may generate change requests to the current build.

5. Testing

At this stage, the application/site is formally tested (lead by internal QA).

During this phase minor bugs are fixed by the development team, major bugs or functional inadequacies are re-specified for the second build

6. Phase Two Development

The second code build is undertaken (this usually takes 30% of the time of the first code build).

7. Release Testing

The second code build is tested against the specification.

If you would like more details on how we may be able to help you with your web project, then please drop us a line for a free assessment.