Welcome to the second part of ‘How To Choose A SaaS Development Team’. Part 1 explained the risks and pitfalls of enthusiastic, entrepreneurial coders taking on a whole SaaS project alone - it might nonetheless be somewhat irresponsible and prone to failure (read part 1 especially if you disagree with that). Now, let’s move on to the building and running of a rocking SaaS product by a team. What kind of team should you look for? Read on to find out!
SaaS means a never-ending project that exists in a constant state of beta – meaning that an almost a constant stream of maintenance, updates and upgrades will need to be made to the programme throughout the whole duration of its existence. That’s no mean feat for a lone soldier traversing the often troublesome programming terrain.
Furthermore, questions surrounding the quality of the code produced, the testing environments, and the programming language(s) that will be needed all pose further challenges even to the most well-equipped development team, but especially to the single programmer trying to manage everything on his/her own. Check what qualities a perfect SaaS development team should have.
As discussed in part 1, if you decide to build your SaaS product all by yourself, then you can never really be sure that your coding is robust enough during construction. Sure, you may be able to hash together a workable programme, but, without other people checking and testing your code on a regular basis, you’re more likely to let yourself “get away” with taking a few shortcuts, or turning a blind eye to some glaring flaws that perhaps a few colleagues would be more willing to pick up on.
In short, you need to assemble a team whose members all have the same goal in mind – to create a durable, robust code structure that is going to deliver to consumers exactly what it says on the tin. For the same reasons that writers need editors, coders need fellow experts to pick over what they’ve done and pick out the bits that need improvement. It can be incredibly difficult to spot the flaws in your own work – but a dedicated team will help each other through.
The key to success in almost every endeavour is of course communication. If you’re working alone, then you’re going to be spending a lot of time talking to yourself – and if you’re the one asking the questions, then you’ll probably find yourself a little stuck when expecting answers.
A great development team, on the other hand, will be a communicative team. It will be a team full of people who ask each other questions and keep each other – and the client (if it’s not you) – up to date precisely with the progress of each iteration of the ongoing project. All members will be proficient in and happy to use project management apps and will know exactly what it takes to run a successful IT project. Put simply, your development team will be willing and able to collaborate and communicate with everyone involved with the project from the get-go, and will indeed share your philosophy that communication is everything when it comes to success.
You will, of course, be undertaking the massive endeavour of creating a SaaS product with the end of goal of profits in mind – and you need to pick a team that understands that. At least one member of the coding squad should be proficient in building in an extremely robust and, above all else, secure payment gateway into your finished product. What is more, you need to make sure that this person (or persons) understands the differences in payment options, and, as such, will be able to advise and discuss with you what is most suitable to the SaaS that you are constructing. Will a freemium model be best, for instance, or do you want to build a straight up premium product? Cheapium is another option that is gaining in popularity – and if you haven’t heard of it, or the reasons why some experts are arguing that it’s a better approach than freemium, then this all the more reason why you need an experienced person on your team who is equipped to advise you.
If you’re heading up the development of a SaaS product on behalf of someone else, then you need to make sure that your team is able to communicate to that client in appropriate terms. Business people are nearly always proficient at communicating their ideas, but programmers are not always proficient in communicating complicated processes in layman’s terms. This, indeed, is a project management problem that you will have to overcome, and it will involve dividing your project plan into bite-sized chunks, creating lots of visual mock-ups and graphs, and engendering a sophisticated communication schedule that all members must rigorously adhere to. The whole process indeed needs a blog post all of its own, and it just so happens that we’ve already put one together, and so I refer you to ‘How To Communicate Your Ideas To Developers’ for more advice and information.
Development has no room for divas. Well, the world, in general, doesn’t – but you know what I mean. Your team should have the ability to think, work and act rationally – as a team. This means that there can be no one person who in any way, shape or form adopts the “I know best” attitude. In fact, the attitude of any kind has no place at all in the dev house. Problems will arise, and challenges will have to be overcome – that’s all part and parcel of building great SaaS. But, what you don’t want is a bad apple making things difficult for the communication of the team. Trust your intuition when hiring and weasel out any divas or rock stars before you start to build – the success of your SaaS project depends on it.
SaaS is a very particular type of IT product. It requires a team with a very specialised set of skills and a very clear understanding of the security measures that need to be taken to ensure successful and safe deployment to multiple subscribers. Additionally, SaaS architecture means that a fast, secure and easy-to-use data services layer needs to be developed – especially if you’re going to need to develop a public API. Indeed, the success of your SaaS product will probably mean that you are going to have to allow for its integration with other software packages, and allow for the development of additional capabilities by third-party developers, as well as providing services for mobile applications – and all of this means consistent and dependable APIs.
In 2016, the world is mobile – and that’s not going to change. When you or your client first conceived of the idea of this great SaaS product for desktops, there will nonetheless come a time when your subscribers will simply expect to be able to access the product on their smartphones and tablets as well. When it comes to SaaS, the case is that many projects will require native apps developed separately to accommodate these devices – and so it makes the best sense to appoint a team which contains members with the skills and expertise to develop mobile apps from the start, rather than make your clients wait whilst you build the mobile apps later. Indeed, you will risk losing your subscribers to competitors if you go for this approach.
The current limits that HTML5 imposes on mobile applications means that creating a viable user experience (UX) on mobile is presently not best practice, as David Key from Cloud Strategies explains:
“The majority of SaaS vendors will provide both a desktop and mobile application. While HTML5 is rapidly become de rigor on the desktop, its use on mobile platforms is situational based on the application requirements. According to Flurry (April 2013), only 20% of the activity on mobile devices is in an HTML browser (though B2B applications would likely be different).”
The collection and management of client data is no walk in the park – and, when the new regulations from the EU officially kick in over the next couple of years, the seriousness of handling people’s personal data cannot be overstated.
The EU’s General Data Protection Regulation (GDPR) means that hefty fines are now in place to ensure that data protection rules are taken extremely seriously by all companies who obtain data on EU citizens – whether your business actually resides in the EU or not. A company can now be fined up to 2% of its global annual turnover just for not having its records in order or by failing to conduct risk assessments on the data in its control.
Furthermore, 4% fines can be issued for more serious matters, such as violations of data security and the conditions of consumer consent for having their data collected and shared. From a development perspective, the most critical point about the GDPR is now that privacy precautions must be built in by design and default – not merely as an afterthought. This means that your developers have to be building data protection facilities into your SaaS product right from the word go, and you must be able to provide clear and unambiguous evidence of this. No short cuts can be taken, nor stones left unturned. Users must also give clear and unambiguous consent for your SaaS to collect their data, which must be indicated by an action (such as the ticking of a tickbox). Consent, indeed, cannot be implied any longer – i.e. just because people are signing up to your product does not mean that you can assume that they wish you to collect their data. Consent must be actually given, not implied. Needless to say, this is serious stuff, and your development team needs to understand this and ideally have experience in developing software that incorporates data protection.
Consistent, uninterrupted uptime is, of course, one paramount of SaaS – indeed, if you can’t deliver this, then you’re not cut out for SaaS. One of the beauties of SaaS is that frequent updates and innovations to the product can be delivered to the user, who will always be enjoying the most up-to-date version of the product whenever they log onto it.
But, this is no mean feat for your developers, who must know how to plan and to execute these updates, all without disrupting the continuity of the service. This means that fault-tolerant architecture must be in place underneath everything, with robust fail-over plans in place should difficulties occur. Put simply, the software must be architected to anticipate and recover from failures without any (or only minimal) impact to the service.
SaaS is difficult and demanding, there’s no denying that. Ask yourself: is your development team capable of providing all of these things? If you need a helping hand, don’t hesitate to get in touch - we’ve got the experts that can provide all of the above and a lot more besides in abundance. We’d love to hear your idea for your next project!