Choosing the right developer for your app or web site is a major decision. There are quite a few factors to consider – experience, technology, etc. The major factor, the one everything revolves around and your success depends upon, is risk. And how the developer manages it.
When we say “developer” we aren’t talking about a programmer you found on a freelance site who is eight time zones away and slow to answer your emails. We’re talking about an actual software development business with professional staff, standards, and a good reputation.
Website, web app, mobile app – they’re all major investments and key strategic moves. They need to pay off. You’re already taking a big risk in commissioning them. Why would you add to that risk by engaging a developer that offers no assurances, no protections and no process for reducing the risk they expose you and your business to?
This article is going to outline what you need to be looking for, and what you should be demanding, from any developer when it comes to risk. There’s a checklist at the end that summarises the things you need to be asking about.
Before the project starts
Ideally, you’re reading this before you have chosen your developer. Until you’ve been down this road a few times it can feel like you’re making a major decision based on screenshots of previous products, hand-picked quotes from clients, and a few paragraphs about how “agile” their development process is and how you will be in complete control.
That’s the standard messaging. Even we use it. It’s all true — our apps, sites and clients are real, and you need to be in the driver’s seat or it’s just not going to work.
But you need to ask deeper questions and demand evidence of professionalism. This is vital when you can’t visit their office and see your project being built in front of your eyes.
The clearest evidence for professionalism is risk mitigation. What systems do they have in place to mitigate the risks to you, their client? There will be a large overlap between their risks and yours. If they’re not taking care of their risks, how well can they be taking care of yours?
Here are some of the risk mitigation elements you want to see in place:
- Business continuity planning: do they have plans in place for how they will meet your deadlines in the event of unforeseen circumstances like floods, bushfires, earthquakes, COVID-related restrictions, or even something less catastrophic, like a programmer falling ill?
- Police checks for staff: are their staff all fully vetted to be trusted with access to your product, your details, and your customers’ details and payment information?
- Separation of developers and DevOps: at its simplest, developers build the app and DevOps handle deploying it and keeping it running. Because they manage backups and recovery from crashes, DevOps have access to the database where your app stores all its information. Everyone on the DevOps team needs to be properly vetted. But they need to be separate so that the developers writing the code that manipulates your database don’t also have access to your customer data. More practically, you don’t want your product to be held up while the programmers fix someone else’s app problems.
These are vital. Particularly Business Continuity Planning. It takes a team to consistently meet deadlines in this crazy world. While using a lone developer your business plans can be set back by them tripping over a cat. A team with strong leadership ensures you don’t lose forward momentum.
When production begins on your app, from the very start, when ideas are being tried out in wireframes, you already need to begin thinking about the bigger picture. Does your developer have team members with this expertise:
- GDPR compliance: GDPR (General Data Protection Regulation) is Europe’s over-arching consumer protection legislation for the internet. A global market means global customers and local laws. Does your developer understand GDPR? Have they built GDPR-compliant products before? Can they tell you if or how your project will be exposed to GDPR and how they will mitigate that for you?
- Pen Testing and Vulnerability testing: No business wants to be hacked. But if you will be accepting payments online you will be a target. Pen testing (penetration testing – breaking into a site or app) and vulnerability testing should be performed to confirm your product is secure before launch. And not by the same developers who wrote it, naturally.
- Security policy and protocol: Security is more than worrying about hackers. It’s also about keeping your source code secure, keeping the office where your project is being built secure – it’s security at all levels. Does your provider have a comprehensive security policy in place? Do they have well defined protocols that their team follows? Are the protocols recent?
Once your product has been deployed and is enjoying a rush of traffic from excited users, it is now up to the dedicated DevOps team and good security protocols to keep you online. Your developer needs the people and expertise for around-the-clock monitoring and they need to be responsive to:
- Security releases: all software is built on top of a deep stack of other software. Your product’s code may be less than 2% of the entire stack needed for it to run. Vulnerabilities may be discovered anywhere in that stack. Software updates need to be applied as quickly as possible. Can your provider do that?
- Backups and snapshots: Something can always go wrong. Backups and snapshots are the final line of defence. Is your data being replicated to a fall-over server? If not, how often is your database being backed up? How quickly can it be restored? How will your app handle this?
- Monitoring: because security is at heart about business risks. Automated monitoring can send email and phone alerts if there is a fault or failure. It’s the first step and needs to be in place. But it’s useless without someone to answer those calls and emails. A serious provider has a 24/7 DevOps presence.
The strongest proof
Any developer can tell you they have all the necessary security policies in place. They can even show you their policy documents. But a developer serious about security will have a Compliance Officer whose role is to ensure that those policy documents are being followed on a day-to-day basis and are kept up-to-date.
The final level
Last, and certainly not least, you want to go with a developer who understands your business context. They should have an understanding of your local market conditions and be accountable under the same legal framework as you are. If you’re Australia-based the ideal is a developer with an Australian office and local staff. The clear communication and shared context in this situation can save you days if not weeks of time and frustration.
The developer trust checklist
Don’t let the number of things that can go wrong scare you off. Risks can be mitigated. An experienced, conscientious developer will be always working to minimise your exposure (and theirs).
Below is a checklist you can use to screen potential developers. Every item is mandatory. If a developer doesn’t tick all the boxes you are unnecessarily exposing yourself to failure. Whether that failure occurs before the launch or after depends on the item and luck.
Does your developer provide:
- Local contact – is there someone in your timezone you can contact? Or even meet?
- Access to Source code – do you have access and can you keep control of the code?
- Control of your hosting
- Daily reporting
- Project Management software
- Support (also known as Ticketing)
- Service agreements for site monitoring and emergency support
- Instant messaging
- Monthly technical reporting
Forewarned is forearmed
Hopefully this information will save you some missteps on your path to building the dream app or site that your business needs and your competitors fear. There are thousands of developers out there. If you count the lone wolves on freelancing sites offering to build your app for cheap, then there’s hundreds of thousands. Choosing the right path is the most important decision you’re going to make. Even more important than picking a logo.
If you want to talk to a locally managed development team who ticks all the boxes, you can reach us through our contact page.