Blueprint for Success: The Importance of Specifications in Tech Contracts
When entering into any tech contract for software design or development, we often see customers fail to lock down the specifications of the end product. Get this wrong, and you risk ending up in a costly dispute with the developer. It would be foolish to let a builder start building your house without a detailed plan and specification. Likewise, don’t let a developer build your systems without proper detail that you can hold them to account for.
This applies to almost any tech contract, from software or app development, to web design, and customisation of an existing system for the customer’s purposes. (It does not generally apply to Software as a Service (SaaS) and other ‘off the peg’ software systems, because they usually have detailed specifications of what the software does.)
In many cases, a software developer is likely to have made a variety of promises over what the end product system will be able to do, how it will work etc, in sales calls and emails, so that the customer is suitably enticed into proceeding with the project. However, these pre-contract assurances often do not make it into the final contract, leaving the customer with little recourse in the event that they are not fulfilled. In fact, the contract will probably have a clause saying ‘you cannot rely on any representations other than those in this contract’.
Given that tech contracts can easily run into the hundreds of thousands of pounds, ensuring that you have a sufficiently detailed specification in your contract is key to ensuring that you get what you bargained for! If you don’t get what you bargained for, proving that the end result has departed from the agreed specification will be key to your claim for a remedy.
Here are the key points to consider when working out a specification with the developer:
Have you chosen the right developer? A developer that knows how to ask the right questions and understands your business and/or specific industry is very valuable in this regard.
What does the software need to do? Have you thought carefully about your business needs, and all the different functions that you want from the software? Just as importantly, has the developer assessed your business needs correctly? Before they start building the system, it needs to be designed to accomplish the task it needs to do. Adding further functionality at a later stage can be problematic and costly, so all your desired functionality should be discussed with the developer as the outset.
How will the product achieve this? Set out in detail what the functions are of each part of the system, and what you expect the outputs to be.
User Interface. Have you set out what you expect the system to look like? Whether it is web design or the user interface of software or an app, appearances matter, because they are likely to impact the usability of the tools the system is built for. The developer should have provided you with example mock ups, or so called ‘wire frame’ outlines, of what key parts will look like.
Compatibility. What are the compatibility requirements? Software rarely works in a vacuum – there are always going to be external systems that it needs to interact with in some way. This could be off the shelf consumer software, like Microsoft Office applications, or more specialised tools that you already use in your business, such as accounting software. Has the developer taken account of these requirements?
Long Term Objectives. Have you or the developer thought ahead about what your long term objectives are for this system? You may set out to build a system which does a specific task (or set of tasks) to fulfil your needs today, but it never hurts to think ahead to how you would like it to develop in future. Leaving the option to add further functionality later can help the system grow alongside your business, rather than having to start again with a new system in 3-5 years.
Finally, some developers are keen to work on an ‘agile development’ basis, where little is agreed beforehand. Under this model, the customer must work closely with the developer at every stage to give feedback and refine the design until both customer and developer are happy. While this can give good results, it leaves a lot of uncertainty in the event that the relationship breaks down, so careful consideration needs to be given before agreeing to this.
Carefully setting out your needs and expectations in advance of starting the project will provide you with a blueprint for success, and a remedy if things go wrong. If you would like to discuss any of the issues raised in this article, or you have an issue that you need to resolve, don’t hesitate to contact us at info@techlaw.co.uk