Why building internal tools could become a costly mistake

Having worked closely with software developers for almost a decade, I’ve noticed some common traits amongst them.

Technically minded people think about problems in different ways. I’m often stunned how I could miss such an obvious data point or edge case when discussing product changes with people who have a far greater technical mind than myself.

I also find myself looking around for third party tools to solve problems, whereas developers like to scratch their own itches and have the skills to be able to build pretty much any tool or product themselves.

But here’s where things start to get a little more complicated

The in-house vs third party conundrum

It’s a dilemma thrown around teams almost daily and CIOs are often left fighting both sides for an answer. Usually the CMO wants to just buy it, and the CTO thinks they can build it.

Building in house solutions often ends up with the following outcomes:

• The initial scope seems simple. The engineering team promises you it’s easy and won’t take much time or effort

• Building commences and priorities shift from building your own product to an internal tool

• Scope grows and more team members are pulled in

• Timelines on core customer facing tasks start to slip

• You end up deploying a half baked version lacking in much of the functionality the third party tool had, with a unattractive and hard to use UI

• Bugs and issues are found that you don’t have time to fix

• Staff that have to use the internal tool become frustrated it doesn’t do as needed and start wanting improvements

• The tool becomes a big piece of technical debt, lacks support and maintenance. Falling way behind the innovations of third party tools

At Raygun, we provide error, crash and performance monitoring software for tech teams.

I’ve lost count of the number of times I’ve seen development teams trial Raygun alongside their in-house solutions and found that they were missing 99% of the issues that users were experiencing with their software that Raygun picked up.

Though building something internally may seem like a good idea, it’s easy to forget there has been years of work put in to refine how a third party tool does the precise job it is designed to do, and what their customers are happy to pay for.

It makes little sense.

GDPR is about to make things, interesting

Lately we’ve all seen tech companies send out a barrage of privacy policy updates to their users about the upcoming General Data Protection Regulation (GDPR) changes, set to come into force on 25th May 2018. This is a concern for any tech business who stores user data.

This has led to us taking more thought into just how complex this legislation is going to be, especially for teams that have built in-house solutions to solve particular pain points rather than rely on third party software.

For us, we’ve had to build in functionality for our customers to remove Personally Identifiable Information (PII) data from the data we have to process for them, and make sure that any sensitive information that is sent to us in error and crash reports is also easy to remove.

Now imagine this - You’ve built an internal tool that logs user activity and provides you with detailed analytics on user actions. Within this you store user IP addresses, full names and contact details.

Using a third party solution which you pay for on a monthly basis, complying with GDPR is as simple as reviewing a Data Processing Agreement (DPA) and signing it. You’re done. All of the compliance is handled by the provider as they need to ensure their product complies with GDPR legislation and support their customers.

Now take the other side of the argument and consider all the internal tools you’ve built including this one for tracking user analytics. You now need to support GDPR with all your internal tools you’ve built too, as well as the ones you pay for.

User details must be deleted and audits must be able to prove the requests for data removal were actioned - Though I’m not quite sure how you prove something was deleted when it no longer exists, but that’s probably a whole new post.

Now you have additionally functionality you need to build into all your internal tools to comply with GDPR. How much time is this going to cost your team? How much money?

Suddenly the idea to build all these internal tools is coming back to bite you, having to shift over all your resources to fix up internal systems before the GDPR deadline. Customer facing issues and innovations are pushed aside and the whole business suffers.

Summary

If you are already struggling to keep up with GDPR and how it is impacting your business, you’re not alone. Internal tools have added a lot of additional complexity to development roadmaps over the past few months.

When considering when to build an internal tool vs purchase a full solution, consider just how much time will be taken to maintain it once it is built. It rarely stacks up to create something internally that can be purchased via a subscription model.

Developers and tech teams will always assume they can build it themselves, but does it really stack up as a business decision?

The last thing you want to be doing is to be losing focus on what you are supposed to be building for your customers and improve sales than be forced into building a whole new product internally that requires maintenance and support.

Leave it up to third party tools to cover the necessary legislations and keep improving their offering.

Otherwise you’ll be left maintaining your internal tools rather than building things that will generate better business outcomes for your customers and stakeholders.

If you’re looking for a way to manage errors and crashes in your applications, Raygun is fully compliant with GDPR requirements and will easily beat any internally built solution at detecting problems that are affecting your customers. Don’t believe us? Try it out and see for yourself just how many problems you’re missing.