Recently we were approached by a small business (a doctor’s surgery) to help them with an ambitious application they had commissioned.
They were having problems with functionality and reliability and their bespoke software provider wasn’t moving things forward as they would have liked.
We wanted to help so we agreed to look at the application and code and see what we could do. What we found was, zero tests, poor architectural patterns, terrible user experience and a lot of code smells.
We reported our findings and provided an estimate to refactor the mobile, web and backends and jumped on a call.
The client’s response was heart breaking; they had spent all their considerable budget with their supplier and had no money left for us to be able to fix even the biggest issues.
We were sad we couldn’t help but we wanted to learn how they had selected their supplier and the response was simple; “we picked the cheapest provider so we could build as much as possible.”.
This got us thinking; how should a client with no software development experience choose a bespoke software provider?
So, we produced a list of 10 things we would ask a bespoke software provider before engaging with them. If the provider can’t give a positive answer to these questions, then consider it a warning they might not be the development partner for you.
1: How can we be sure you understand our requirements?
We always start with a conversation. Together we focus on describing the goal of a feature as opposed to describing how it is implemented. We then add acceptance criteria for that feature so everyone involved knows when this feature is done.
2: How do we know what you build for us will work the way we expect?
Untested software has little value! There we’ve said it! Seriously no one would drive an untested car on a public highway so why depend on untested software?
We deliver fast and often so that you can tell us where we went right (and where we went wrong). We underpin our delivery by building a comprehensive test strategy that favours automated testing (Unit Testing, UI Testing) supported by manual testing all based on acceptance criteria. By automating tests, we can guarantee consistency, execute tests more quickly and test more frequently this leads to higher-quality software shipped more often.
3: How do we know your time/cost estimates are correct?
Estimating software development is hard; while fixed-price contract arrangements are accountant friendly, they leave no room for flexibility. What if our client realises they don’t actually need a feature they’ve described?; or that a feature is delivered more quickly than expected? Applicita favours Time and Materials cost model based around a budget agreed before commencement and here’s why.
Flexibility. A T&M contract presents the opportunity to make revisions, modify the volume of work, revise the design or change/add features, which helps clients who are still polishing the finer details of their application. Essentially it means you don’t have to describe everything you want upfront.
Control. Because Applicita delivers one feature at a time for demo, this allows the client to be more involved in the development process and quickly identify we need to change direction or modify something.
4: How can you prove to us you are using best practices to produce high-quality code?
We have invested heavily and are very proud of our Application Development Framework. This framework allows us to deliver high quality features quickly. We give our clients access to this source code to demonstrate what they can expect when we deliver their software project.
5: What happens if we find an issue after the system is delivered?
If a variance is found in the behaviour of the system compared to the acceptance criteria (e.g. a defect) then we resolve this with no charge in the first 12 months.
6: How can you help us build the best application possible?
Applicita has delivered many software projects in many sectors. We take real pride in the software we deliver and we love to share our gained knowledge and experience with our clients. An example of this might be suggesting an implementation approach for a certain feature; or advise on the prioritisation of features.
7: What if our requirements change overtime how will you be able to support us?
Applicita build software that is adaptable to change and so increase the lifetime value of the software. We achieve this by using software architecture which is well structured and easy to change. Having a repeatable regression test strategy allows rapid validation that a platform is functioning correctly after a change is implemented leading to faster releases of the software.
8: What do you need from the client?
Delivering a successful software project is a collaborative effort. We need our client stakeholders to ensure that their business domain expertise is available to us so we can ask questions as they arise. We also need the same engagement in our frequent release demos to make sure we’ve delivered what was described.
9: How do we know that the application is secure?
Applicita take security in all its forms very seriously and conform to implementing the latest best practice. We perform security checks before each release of the software using industry-standard tools and can arrange independent testing if required.
10: How do you ensure we know when things go wrong?
Trust and transparency with our client is essential. By regularly shipping our work, speaking daily to client team members, asking lots of questions and putting things right quickly we work to gain a long term trusted relationship with our clients.