Ping. Your lightbulb moment happens. You’ve had the gamechanging idea that will shake up the market or revolutionise how you do things. Now you just need software that will bring it to life. But should you do this in-house, or appoint a development partner?

Okay, so if you have a crack dev team that can, 100%, deliver what you need – and has capacity – then that works. But what if you don’t? There are compelling arguments on both sides and this Purple Crane blog looks at things to consider in your decision-making. 

Forming your own team:

Cons: 

The financial investment and time needed to recruit, lead, and manage a team is just the beginning. Add ongoing costs in training, running an office, HR, pension, National Insurance, illness, parental leave, holiday, and so on. It all adds up. 

Once you have the team, you must justify the time and expense by keeping them busy. But work patterns fluctuate. Can you afford for skilled professionals to sit on the bench, or committed to an overrunning project? 

You will need to understand the unique nature of a development, or dev, team. These intelligent, creative people must be kept engaged, stimulated, and challenged. Can you commit to that? 

Nothing is forever: staff turnover and natural ‘churn’ will cost your team in knowledge and specialist expertise. 

Pros: 

Use the desire to be ‘kept current’, and busy, in your favour. Set the team loose on your other projects, and technology; expose them to new environments and solutions. New stuff they learn ‘out there’ also helps ‘in here’. 

Learning new skills, tools and technologies constantly adds depth to your dev knowledge pool. What one person doesn’t know, could be second nature to another. 

Partnering with a development company:

Pros: 

Appointing an external development partner represents a more stable, cost-effective alternative.

While contractors come and go, a longer-term relationship builds consistency, and increases organisational and domain knowledge that can’t simply be archived and retrieved. 

‘Ownership’, control, and the economics of running the team defaults elsewhere and while the team may lack the emotional bond with the commissioning customer in the short term, trust and good communication improve over time. Customers and contractors soon build relationships.

Engaging with a company that lives and breathes development support means tapping into increased capacity, and the extensive knowledge, support, reliability and consistency that only a large team with the experience of many successful projects behind them can bring. 

Robust contracts, formal agreements, negotiated pricing and SLAs keep projects on track. Suddenly the supplier and parent company are aligned in a mutually beneficial ‘partnership’. Everyone benefits. 

The economics of repetition mean that reusing shared code, tools and processes, and growing your libraries over time, reduces project overheads in cost and time. Every project deepens the knowledge pool, and the well of knowledge a new customer can access. 

Crucially, a long-term, ongoing relationship equates to a formal partnership. It supports a better understanding of each other’s companies where the contracted development company becomes an extension of the host’s own team. 

Code and IP ownership concerns?  The code underpinning bespoke software is usually owned by the customer, so full access and oversight should be a given. 

Cons

Okay, so I haven’t thought of any that can’t be addressed by good communications, management and building a good relationship. But there is a third way, of course.

A word about using contractors, or freelancers 

A quick Google search will secure some short-term help, and maybe even something longer, depending on the project. But when a relationship has a pre-programmed end date, the potential for a lack of engagement with, understanding of and loyalty to the host company is real. It may also be difficult to secure follow-up help, as anyone who has ever tried to get a plumber or builder to return once they have been paid will confirm.  

I am sure anyone reading this, who has experience of working with external, appointed dev teams may not always have had a good experience. This blog outlines how things should work. 

Sure, some projects are easier to deliver than others, but with the right framework in place the work takes care of itself. The devs at Purple Crane work to a model of shared goals and mutual respect. We have many happy customers and successful case studies that prove that it works. 

Get in touch and let’s create something great together.