Your business needs a new solution, and you’re staring down a critical decision: build vs. buy. Successfully moving into the development and innovation realm requires entirely different skillsets than your typical internal IT possesses. Some large carriers have made that shift, but if you’re considering it, be aware of your options and where challenges may arise.
We covered hurdle #1 in July, recruiting tech talent, which brings us to hurdle #2, cost. Standing up a dev shop is expensive: infrastructure x 3, CI/CD pipeline, disaster recovery, numerous software development tools, compliance, licensing costs that can absolutely blow your mind and your budget, and of course, premium pay for highly skilled staff who can make it all work. A little creativity can avoid some of that cost, e.g., open source software reduces licensing costs, serverless architecture reduces infrastructure costs but requires significant expertise to design, build & manage, no-code platforms circumvent some of the top tier expertise costs, but good no-code platforms aren’t free and they come with limitations in designing for your specific business needs. Also, you’ll need some highly skilled people to even properly evaluate these options and others to manage the solution. Does it need to share data with any other applications? If so, add that expertise and cost to the tab.
Hurdle #3: Actual innovation. IT’s top priority is to keep the lights on and the business running. As a result of that necessary priority, internal development tends to deliver a static end result, meaning it’s not touched unless it breaks. No one is tasked with anticipating how the solution needs to evolve, so when you need new features or integrations, the business owns initiating and driving that lengthy process.
No matter how you slice it, there’s a hefty price tag despite efforts to shave off a few nickels and dimes, and the build path can very rapidly become more intensive than planned. A quick assessment to identify if you have a “build-ready” organization: have you bought into software, even market-leading software, only to find that your organization couldn’t implement it or get the full benefit? Have you been presented with change orders or professional services quotes over and above the original cost just to get a project over the line? Has a vendor cited issues with your internal systems, data, or processes as reasons they couldn’t deliver? If any of this sounds familiar, you’re likely not in a build-ready organization.
A middle-of-the-road approach is to outsource: select a vendor and tell them what to create. While outsourcing negates the need to find your own talent, it also means you don’t get to vet the talent provided, and I’m here to preach that the skills you see on an SOW aren’t always what you get behind the keyboard. Further, implementation and maintenance fees are marked up. Finally, any future changes drive additional cost. If you have a reliable vendor, and they’re out there, outsourcing custom solutions can be an effective method of risk transference, but otherwise, there aren’t significant benefits over DIY. If you do opt for this route, be sure to get trusted references from colleagues who’ve used the vendor for similar scale projects.
Finally, there’s buy. When you buy software, you’re buying fractional resources, meaning you get the top-tier tech experts you need at a much lower cost. Additionally, the software provider has already made the heavy investments needed to stand-up a purpose-built dev shop. Finally, industry-specific providers keep pace with trends and innovate to stay in tune with business needs, without you having to drive every new piece of development. There’s a very good reason that the largest and most successful tech companies in the world have enormous marketplaces; they fully understand build vs. buy, only in their case, it’s build vs. partner.
Some larger carries do manage extensive in-house development, but even they often struggle with wrapping a risk-averse business with different lines moving at different paces around the rigorous disciplines of technology. Before you opt for the build route, take deep stock of your ability to recruit the necessary talent in today’s market, the full sticker price and the hidden costs, and your organization’s potential need to evolve the solution. If you don’t plan to go to market with a specific tech offering, it may not make a great deal of financial sense to stand up a full development shop. Your bottom line is likely better served with its leaders driving revenue rather than IT projects.
