Thoughts on the early stages of a tender doc.

DC,

I have viewed this from the position of being a consultant to internet based SMEs with high growth potential, and developing specifications for IT projects / infrastructure.

Without knowing what the client does and what they require it's difficult to comment, however given the other items on your tender I think a major omission appears to be hosting and management of a version control system.

You mention a one-year contract - are you working on the same time scale as the client here? Are you offering a solution which you/they believe will meet their requirements by the end of one year, rather than an adaptable service which can grow with the business? Your proposal should look beyond the first year, your client may want assurances of a continuity of service for perhaps 5+ years.

A clear plan for sale up, and the ability to scale up rapidly if required is often important for SMEs with infrastructure such as that you are proposing. Showing that you have planned for, costed, and are capable of coping with expansion in your tender may pre-empt some inevitable questions from the board. In this case consideration of dedicated database servers and dedicated web-caches might be appropriate.

Where is development taking place? Yours is an entirely outsourced proposal, this might scare some SMEs who want to keep core development capibilities in house. In house developers will need infrastructure, which may be best provided in house. Development servers at the company's premises might be appropriate.

I realise your posting is a brief overview - but the kinds of comments you might expect from semi-technical internet company directors include:

*Two application servers located in separate data centres.
With this level of contract the client will want the details, location, who runs them, connectivity etc.

*99.999% uptime
What is that based on? Past performance? Or is it the level you are assuring as a part of a service level agreement.
What does the "uptime" refer to? Impress the company by relating this to the key business purpose of the application. Ie. don't tender for X% uptime of a server, go for X% uptime of the client's key services.
If it does refer to an SLA, this, and compensation under it needs detailing.

*24 hour contact number with 4-hour resolution
Can you assure the client your company can supply that. A common question is - "How many individuals do you have who will be familiar with our infrastructure?".

*Distributed Database across the servers
Mirrors? Fragmented?
You are introducing a lot of complexity here - a question that might be asked is what's the business justification for that?

*Daily RAID backups within each server
Use clear unambiguous language, the last thing you want to do is trigger a director's "Bullshit detector" - some are highly tuned. Don't over simplify to the point of it not being obvious what is meant - which I think you might have done here.

*10 development sites
Sounds complex / excessive - is there a need to differentiate between "development sites" and the "staging site" ie. The dev site that is sent live overnight.

*Monthly 1 hour of DBA time
You need a clear understanding of what it is you do, and what is the client's responsibility. The "1 hour" quoted appears trivial compared to the scale of the contract and unnecessarily restrictive. You'd be better off quoting for DBA services separately by the hour - and not including this potential red flag here. Do make it clear that maintenance of the distributed DB etc. is included.

*Real-time stats
You note the load issue with running stats compilations in real time. Consider what stats are really needed in real time - and can be provided at lower cost.

Other things to consider include server software (OS/PHP/Apache) maintenance patching and updating. (You may need more dev sites/ servers during a major upgrade / migration). You might need a support ticket / bug tracking system.

Security also probably needs to be addressed - looking at your post I'd substitute FTP for SFTP. Firewalls, security of the distributed database etc. could also be considered.

Overall clear demarcation between what's covered by this proposal and what's the client's responsibility is probably one of the most important things to get clear from an early stage with a proposal such as this.