ReportLab standard terms for hosted solutions and projects
ReportLab standard terms for hosted solutions and projects
Including standard working practices - last updated October 2024
1. Infrastructure for hosted solutions
When proposing to host a solution, we will work with the client to determine the appropriate solution. However, we have a mature, standardised approach, aimed at saving time and costs. Most solutions are based on our DocEngine framework, a collection of applications and libraries for use with the Django web framework.
1.1 Technology platform
ReportLab utilises an industry standard open source technology stack. Components evolve but for new hosted solutions we build, this generally includes:
Linux operating system (Ubuntu 22.04 or later LTS release)
Nginx web server (or Apache in some cases)
MySQL database server for classic relational storage
MongoDB for less structured data, audit trails and logging
Python programming language (v3.x for new projects, 2.7 still supported)
Django web application framework (version 2.2+)
Jquery and Bootstrap front end frameworks for server-side pages
Vue.js for complex front-end development
DocEngine – ReportLab's collection of shared app functionality to allow rapid creation of robust solutions
ReportLab PLUS – our PDF and chart creation products.
These technologies (part from the last two, which are ours) all have a global user base and active developer communities, with extremely deep expertise available for support and performance tuning. As well as the lack of licensing costs, the platform helps us minimise dependence on vendor-specific technologies. Further, the ubiquity of open source technology allows for relatively easy transfer to other platforms if necessary.
1.2 Standard hosting practices
Our standard infrastructure is designed to offer very high availability at reasonable costs. It has been used in 24x7 environments for many years for key clients such as the Post Office Travel Money website, and Hilton Hotels. Many of our systems have a measured uptime of 99.995% to date. Key features include:
a primary production server in one of three globally distributed data centers
a live backup server which gets a full copy of all software and content every night, in a different data center to the primary
a DNS monitoring service with automatic fail-over between primary and backup servers. If a data centre or server is down for more than a couple of minutes, users are directed to the backup data centre
separate staging and test environments used to test and deploy new releases
all code in version control
continuous-integration test suites, run on every code change, and when needed (e.g. daily) for batch data quality checks
automated test suites for all the key functions
independent service monitoring using Pingdom, which notifies us of any outages and keeps reports on uptime and performance
2. Security
ReportLab has a long history dealing with high security systems and operates according to current security best practices. We do not, however, hold certifications ourselves, as much of the relevant responsibility is delegated to ISO-27001 data centres.
For example, we have
1. spent the last decade and a half handling high volume applications for financial industry clients.
2. successfully passed extensive penetration tests as part of a project to build a secure financial application for the UK Post Office, complying with PCI-DSS standards.
3. successfully passed annual penetration tests for a secure government funding approval database, which we built and host for the department of Business, Industry and Skills.
All data centres used are ISO-27001 compliant.
For EU clients, we host any personal data entirely within the EU, for compliance with GDPR and the UK Data Protection Act.
Where substantial personal data is involved, it is agreed that ReportLab is acting solely as an agent of the Client, and the client should register if necessary under the Data Protection Act and should appoint a Data Controller. This is a 15 minute process which we can guide clients through.
Systems involving confidential data will generally be hosted and accessed only over HTTPS / SSL. Where upload facilities for file transfer are necessary, ReportLab will normally configure an incoming SFTP area protected by key pairs.
In our view, the best guarantee of security for a system is a programme of penetration tests. Upon request, ReportLab can arrange for independent external security auditing and penetration testing of our servers and code. However there will be additional costs both for the testing, and for the time needed in interaction with the testers; it may not be appropriate for all projects.
3. Project management
3.1. Agile methodology
We will try to align with a client's preferred methodology. We recognize that certain kinds of solutions (e.g. data feeds between systems) require careful advance integration planning, but that others can be developed iteratively in a more flexible manner. In general we prefer agile methods, as defined at https://agilemanifesto.org/.
We can make available a shared issue tracker to manage, prioritise and accept work as projects progress. Depending on project size or complexity, either Google Sheets or Pivotal Tracker are preferred.
The degree of formality will depend on the scale of the project and the kinds of people we are working with.
3.2. Weekly reports
ReportLab will normally aim to issue reports detailing progress, and any associated costs incurred, no less frequently than every week. However, if ReportLab, for any reason, does not produce a weekly report, our client will still be liable for the fees incurred during that week, provided there was reasonable cause to expect work was occurring. Such reasonable cause includes, but is not limited to: emails, conference calls, and project meetings.
4. Support for live systems (“Service Level Agreement”)
4.1. Uptime guarantee
All systems aim to deliver at least 99.9% uptime (and much higher rates are normal). However, where the client does not need 24x7x365 uptime, we may agree maintenance windows and a less costly release process which takes advantage of occasional allowed downtime.
In the event of failure to achieve 99.9% uptime, we will discuss in depth with the customer, conduct a root cause analysis and take demonstrable steps to improve future performance. We believe that this is far more important than the usual industry practice offering a partial refund of a very small percentage of a monthly hosting fee.
4.2. Responsiveness and performance
The majority of page loads for all logged in users should load in a few seconds, as measured from locations within the UK outside of corporate firewalls. Poor performance is often down to client firewalls and networks, which we cannot control. For pages with heavy Javascript content, especially single-page-apps, this may sometimes be longer. No guarantees can be given for document generation speeds as this depends on the amount of content on the page, but we commonly build systems able to generate rich 10-page PDF packs in a few seconds.
4.3. Standard support hours and channels
Support issues should be reported by the approved first-line support staff, in email to support@reportlab.com, with enough information to reproduce the issue. We can also create instant messaging groups for specific projects where we work intensely with customers.
Our support hours are 9am-6pm on UK working days. We may respond out of hours at our discretion, so recommend emailing any issue to support@reportlab.com as soon as possible.
4.4. Severity scale and response targets:
Our automatic monitoring will usually notify us of a serious outage before you know. We also receive detailed emails about unhandled server errors. We aim to respond in a relevant and specific manner as quickly as possible.
Our response may depend on the size and function of the system. An occasionally-used publishing system may not warrant the same attention as a business-critical public-facing web site. What follows below is for clients with comprehensive SLAs running business-critical systems. Non-critical systems may have slower response times.
Where the team is dealing with serious or multiple issues, we will classify the severity and aim to respond as follows:
|
Severity |
Definition |
Response |
|
1 |
Most or all users are unable to complete their tasks |
1 hour response; entire team available (stopping other projects) until issue is resolved or downgraded |
|
2 |
A significant number of users are unable to complete significant portions of their tasks |
2 hour response; qualified engineer working until issue is resolved or downgraded |
|
3 |
Issues exist but can be worked around by users |
Next day response; discuss with client whether emergency release is warranted or whether to fix on next scheduled release |
|
4 |
Minor cosmetic or nice-to-have issues |
Phased into appropriate development |
4.5. Warranty for functionality
Hosted systems can be large and complex and are sometimes developed to tight customer deadlines and budgets, or involve tradeoffs.Development is frequently part of an ongoing programme, with no single point in time where a perfect specification exists for the whole system.
We try to agree how each feature will work before it is implemented, and give clients a chance to review each feature in a user acceptance testing environment. When working on a time basis with frequent releases, bug fixes will form part of the regular development cycle and are chargeable work.
Where issues are caused by previously unseen or unexpected client data, we will treat any ensuing work as chargeable.
4.6. Non-bug support
Once solutions are up and running, unless on the most basic hosting contracts, clients will generally have a monthly allowance for “non-bug support” included in any ongoing hosting and licensing fees. “Non-bug support” includes:
Minor changes requested by the client
Correspondence about the system
General enquiries, including development cost quotes requiring detailed investigation
Issues arising from changes in the client's data or database structure which could not reasonably be anticipated
Issues arising from changes in 3rd party feeds or systems which are outside ReportLab's control
Documentation or staff training requests beyond those discussed in the Proposal
Meetings and conference calls beyond those required by work set out in the Proposal
Investigating an issue which is not initially presented as a concrete reproducible error, in order to determine whether there is a bug or not
Investigating issues which turn out to be caused by client data.
If ReportLab anticipates that a support request will exceed the client's monthly non-bug support allowance, ReportLab will notify them of the possible additional costs and await authorisation. Large scale change requests may become the topic of an entirely separate proposal.
5. Rates and charges
Almost all projects involve an agreed budget, and we often quote fixed prices where the specification is sufficiently clear.
5.1. Hourly rates
Our rates for services work are published on our website here and updated annually on 1st January
5.2. Overtime rates
It is not our normal practice to have staff working at evenings or weekends.
If you require us to undertake work outside of ReportLab's regular working hours (9am – 6pm UK) - for example to work jointly, attend meetings or manage releases during the night, or if we warn you clearly that a project deadline will require overtime - then we will charge overtime rates as set out below. Rates are as follows:
1. We charge double the usual rate for work outside our regular working hours (9am-6pm UK) and on Saturdays, Sundays and UK public holidays. This includes the evening period (6pm – 11pm) and early morning (7am – 9am).
2. We charge triple the usual rate for overnight work (11pm – 7am UK), irrespective of the day of the week.
However, if we choose to work outside of normal hours for our own scheduling, these rates will not apply.
5.3. Stand-by fees
If ReportLab staff are needed to be on stand-by (e.g. on call to support a release or upgrade), their time will be charged at a 25% of their standard rate for the duration of the period required.
For example, if you need an engineer with an hourly rate of £145 on call for 8 hours, the charge will be 0.25 * 8 * 145 = £290
Work undertaken during this time will be charged according to the terms outlined in “Hourly Rates” and “Overtime rates” above.
5.4 Travel costs
Unless otherwise stated, travel time will be charged at half the standard project rate for the employee, in addition to the actual travel costs.
5.5. Font licensing
Any system we build needs to have properly licensed fonts. We generally use Windows TrueType embedded fonts. Certain types of server-side solutions require more expensive font licenses than when designing for print. You may provide us with font files which you have properly licensed for the purpose, or we may procure them on your behalf. We find that the free Google Fonts archive is an excellent starting point for most projects.
5.6. Other expenses
Clients are responsible for reimbursing ReportLab for any specialist software, user licenses, or infrastructure changes required to deliver a client's solution. ReportLab does NOT maintain a fully licensed set of Microsoft or Oracle tools. ReportLab will seek authorisation in advance to procure such components if those costs exceed £100 in any given month.
6. Right to reference
We do not employ a substantial sales force, and we rely on real-world case studies and references to let people know that we exist. References for successful projects are very important to us.
Where systems are publicly visible, ReportLab will usually seek to produce a case-study for ReportLab's website and possibly a press release. If you do NOT wish to be disclosed as a client, please let us know before the project is signed off.
Front-end web sites built by ReportLab may contain a small credit to ReportLab in the footer which does not detract from the usability. Similarly, PDF output may contain a very small footer message mentioning that the system was built by ReportLab.
7. Payments and invoicing
7.1. Initial development costs
When we quote for work, the project proposal will set out milestones and stages for payments. ReportLab will normally invoice for a portion of the initial development and set-up portion of the work upon receipt of your instruction to proceed. Normally the last milestone will be invoiced on delivery of the system into User Acceptance Testing and/or on provisioning the live servers.
If the project proposal states that certain payments must be made prior to going live, then ReportLab reserves the right to delay a live promotion and/or to limit the functionality of the system until payment is received in full. For time-based projects, ReportLab may raise an invoice at the end of any month for work completed during that month.
7.2. Exclusions from quotes
The initial development and set-up fee covers only the work explicitly described in the Proposal, and is governed by the working practices and exclusions set out above. Any work outside this scope, whether explicitly classified as extra work in the Proposal or not, may be billed hourly or may be the subject of a costed change request. We will notify you and await approval if extra costs are incurred. Within a fixed price proposal, we will normally allow a reasonable amount of time for discussing and refining items which are not fully specified at the outset, and keep track of this allocated time. If the time appears likely to be used up we will advise you.
7.3. Invoicing for ongoing hosting / support
If the project implies an ongoing hosting or support agreement, it will enter this phase once the system enters User Acceptance Testing (UAT)or when live servers are provisioned, whichever is sooner. Unless stated otherwise in the Proposal, we will invoice for the period up to the end of the first calendar quarter of hosting when the project enters this phase. Thereafter, we will invoice at the start of each quarter for hosting with payment due thirty (30) days after receipt of a valid invoice.
7.4. Invoicing currencies
We invoice in GBP, and it is the sender's responsibility to ensure that the full amount reaches our bank account, paying any needed charges. If you require invoices in other currencies, we will use the exchange rate provided by our own bank, and may add a buffer of up to 3% to cover the risk of exchange rates moving between the invoice and payment date.
7.5. Late payments and penalties
Unless stated otherwise, Invoices are due in 30 days. We will apply the statutory penalty charges and interest rates allowed under UK law to any late payments. If the client requires purchase orders with invoices, it is solely their responsibility to issue us with the correct purchase order numbers on or before the date we are due to invoice.
Under extreme circumstances we reserve the right to temporarily disable the service until overdue amounts are paid.
8. Termination
During the initial development of a system, you may terminate a project by giving us 5 working days notice in writing. If the work is time based, we may charge for all work up to that point and for our estimate of another week of work at the same rate. If on a fixed price, we may charge for our own assessment of the percentage of work completed up to that point.
The project will enter the ongoing hosting phase once the system enters User Acceptance Testing (UAT) and/or live servers are provisioned, whichever is sooner.
New hosted solutions are subject to a minimum hosting period of 18 months from the above date. This is because ReportLab often absorbs initial development costs in the reasonable expectation of continued use. If a client seeks to cancel earlier than this, the full hosting fee for this period is payable.
Thereafter, termination during the ongoing hosting phase will be subject to ninety (90) days written notice (or payment to ReportLab of ninety (90) days hosting fees in lieu thereof).
9. Jurisdiction
All agreements are under the laws of England and Wales.