Posted: 14/05/2019
This start-up guide is part of our Start-up Support initiative and was submitted by Codentia – a full-stack software development company that works with entrepreneurs across the UK and the Channel Islands.
Technology-centric ventures are risky. They fail. And for many reasons, but one of the key causes of difficulties is a poor (or poorly thought out) choice when deciding who to work with to build your product.
This is all too often because it is reduced to a simple cost/benefit analysis which does not capture all the nuances of working with a software development team – or indeed any group of people, so I’d like to take the time to explore some of the factors you may wish to consider – and why.
There is a pervasive myth that ‘anyone can code’, popularised by the heavy promotion of ‘learning to code’ in recent years. Speaking as a developer with almost 20 years experience, half of that running a technology business and as someone who teaches people about programming, this isn’t true.
For many, many people it is beneficial to learn about how programming languages (and by implication, software and computers in general) work in order to bolster their understanding of the world we live in, but in reality not everyone has the aptitude or attitude to become a professional programmer.
Why is this relevant when you are trying to find, for example, an agency to build your new app? Because this increasing perception that ‘anyone can code’ leads towards ‘coding is easy’ and ‘anyone can build this’.
Which isn’t true. Not by half. But you’d be forgiven for thinking I’m about to tell you how technical competency is the most important thing. Because that’s not true either.
Consider this. You’re working closely with someone (or a group of someones) who work in a very different way to you. You have strict 9-to-5 office hours and they work flexi-time. You do everything by email and they prefer real-time chat (or even the phone). Coffee shops, Libraries and Co-working spaces versus Offices and Meeting Rooms.
Don’t be fooled by thinking you all have to have exactly the same attitude to working environment and culture – what’s really important is that your core values are compatible – meaning you’ll be able to work together with less friction. Having a similar attitude about things like what ‘professionalism’ means to you and how you define success also helps greatly.
Think of the agency or team you are looking at as part of your start-up, or at least a partner who is going to be building your product with you – not for you.
Strongly tied in to working culture is the way that culture manifests in the work itself – there are loads of software development (and project management) methodologies proffered, ranging from Waterfall to Agile – or perhaps even ‘Spiral’ or ‘Extreme’ approaches.
Understanding in advance how you will work together is crucial – will you document everything for the whole project up front? Will you draft a top level plan and then fill in the details piece by piece as you go?
How will the roadmap look and what will happen later when things go off the rails (or at the very least wobble a bit) – how does their approach to keeping the project on track compare to yours?
Again, you do not have to choose to work only with people who do things the same way – perhaps the very opposite is true in some cases – but you need to talk about it and understand how each other work before you’re going to be able to collaborate.
Most of the time the developer(s) will advise as to the technology or technologies which they feel you should be using for a project. This is likely to be a coloured decision as most agencies (and individuals) favour particular development environments and technology stacks, but don’t be afraid to discuss possible alternatives.
There might be preconceptions which you (or they) have which mean an open discussion about ‘what are the right technologies?’ early on can provide a solid foundation for your start-up – definitely don’t assume they will always make the right choices on your behalf – and equally don’t presume you can make these choices without consultation.
While you can build anything in anything (more or less) there are often specific advantages and disadvantages to consider.
Sometimes the long term implications are as simple as the cost of hosting the solution later on, but they can be far more complex – for instance if a niche skill is required, or the language used is one which is ‘on the way out’ and not popular amongst new developers coming in to the business?
Stop! Listen! This is vitally important. Do not reduce the choice of technology partners to an equation based purely on cost.
I view cost as one third of a balanced equation – Cost, Time and Quality (or if you prefer the blunt version, “Fast, Good, Cheap – pick two.”). Want it done on the cheap? It’ll take a long time, be of poor quality or both. Need it right now? Be prepared to pay and/or put up with substandard work. Only interested in the best possible goods? It’ll cost you – and it won’t be quick.
Try to balance these elements – choose a software development company who is like minded and who will work with you to deliver an appropriate quality, on budget and on time.
Do NOT establish a firm budget or time-scale before you are able to have this discussion with your potential partners. If you tell them what it will cost – or when it needs to happen – you’ve already skewed the balance and the only element they are able to influence is the quality.
It’s corny, but where there’s a will there’s a way. Is it going to cost too much? Spread it out into more phases or sprints – or even defer features for development later. Is testing taking up too much of the budget? Perhaps automation can help, or you can offload some of the Quality Assurance to yourself (or your existing team). There are always options to manipulate these factors and a good partner will help you to do it.
Make sure you’ve talked about what happens next. And please don’t just say “There’s going to be loads more work!” – because that’s not what you need to know, it’s just an enticement and this should be an equal partnership, not one where you’re bribing them to take your project!
Will they help you set up and host the project when it’s complete?
What’s the plan for aftercare – do they provide any – and what will the product need?
Do you need anything in place in terms of people, skills, equipment, etc to manage and run the product?
Are future phases of development to be planned? If so, talk about them up front as they might have implications that need to be borne in mind now.
Does your relationship with this partner stop when they deliver the product and will someone else take over the management at that point? This is perfectly reasonable too – just make sure that what you expect to happen is what they are going to expect to happen!
En fin, I hope I’ve given you an insight into what is one of the most misunderstood areas of our business – and most importantly I hope you’ve picked up on the underlying theme here. For me it can be summarised neatly:
Above all else, communication is king.
A good partner to work with is, as with so many things, one you can talk (and listen) to.
Matt Chatterley, Owner of Codentia and CTO of HandsetExpert
With fifteen years experience in software, Matt started out in hospitality and his first IT job was working on a stock-taking system.