Integrate, don't imitate - when an API beats rolling your own

It wasn’t long ago that every agency and freelancer had their own custom CMS they’d use for client projects. We decided that was a bad idea. But we’ll often be seen writing custom code within that standardised CMS. Are we making the same mistakes again?

This blog accompanies my talk at the Thames Valley Umbraco User Group on 30 April 2020. I also have the slides for my talk available.

Let’s start with a couple of scenarios.

Scenario 1: John the roller coaster enthusiast

Meet John. He’s a rollercoaster enthusiast and he’s decided that he wants to ride a roller coaster at least once a week. He’s got a good budget and money is no object.

How could we solve his problem?

Option 1: Build a roller coaster in John’s back garden

We could recommend to John that we build a roller coaster in his back garden. This could be quite fun and he could ride the roller coaster as often as he liked, with no need to queue. But on the downside, the estimated cost of this solution is £2.5 million to £25 million (source: BBC).

Option 2: Go to a theme park

Alternatively, we could just recommend that he goes to his local theme park. He’d have his choice of various rides with no build-time, planning permission, health and safety, insurance, etc.

As for cost, a “premium season pass” at a well-known theme park costs £85 (notice the lack of the word “million” as a suffix), plus the cost of fuel (which, no matter how far you’re travelling is negligible, again due to the lack of the “million” suffix).

I’ll let you decide which option to pitch to John.

Scenario 2: National Bushcraft Association website

Some of you may know about the time I lived in the woods for 6 months and taught wilderness survival skills to school children. So, I've created a scenario around the fictional National Bushcraft Association, a membership organisation for bushcraft instructors.

Members pay an annual fee to gain benefits such as networking, client referrals, news sharing capabilities and the obligatory newsletter. They want a Content Management System (CMS) with member management functionality to manage membership fees, expiry of unpaid memberships and mass mailing.

So the obvious solution?

Umbraco! That’s my go-to CMS, and I love working with it. Of course, simply being my favourite CMS doesn’t justify the choice on its own, Umbraco is open source with an enthusiastic community meaning it's free and actively developed. Umbraco will easily cover the requirement the Bushcraft Association has for content management. It also has a highly extensible membership management system.

The membership management functionality in Umbraco by default, however, is comparatively basic. So we’d need to build custom functionality to allow sending newsletters, membership payment and expiring members who haven’t paid.

But wait! Isn’t this the theme park scenario all over again; are we building a roller coaster? And if so, what are our other (“season pass”) options here?

As for membership management, there are dozens of pre-built systems available that have this down to a tee, and many of them have an API we could integrate with. A third-party system would handle the membership fees, expiry and renewal reminders in the requirements, but also take GDPR off our hands and give us extra functionality to, for example, allow members to manage their own details and upgrade their membership tier as they need to, without phoning up the office team.

Similarly, a newsletter sending platform would handle sending newsletters and managing subscriptions and unsubscriptions as required while also handling GDPR and providing the Bushcraft Association with analytics.

In this scenario, I think building a basic CMS site and integrating with some third party services is the clear winner.

The problem solver mindset?

But where does this “backyard roller coaster” attitude in developers come from?

Personally, I think it’s due to the problem solver in us. We’re in this career because we like to solve problems and when someone gives us a brief we like to find an “ideal” solution, built exactly the way we think it should work.

As well as this, as a premium service provider, we might feel it’s our duty to build everything bespoke rather than “cheating” by using other people’s work.

It seems to take some maturity as a developer to realise we’re not taking the easy way out by using other people’s work but standing on the shoulders of giants.

We’re all too keen to use open source packages to speed up development and provide our users with a better experience, so why not complete services too?

Benefits of integration

For us developers, integrating makes life less repetitive, I get to spend more time writing new code rather than making poor imitations. Being honest, I just find building integrations more fun; I don't get too excited about another document type or building another news page. Writing more in-depth C# is more interesting to me!

But how do we sell an integration to higher-ups, project managers or the client?

Over-delivery and extra features

Integrating with more complete systems can result in over-delivery. Third-party systems likely have more features built into them over the years than you could do with the budget, the client’s going to get an industry-standard application, rather than the bare minimum.

Not to mention the fact that the client may get extra features “for free” as the third-party developer continues to improve their application over time.

Less scope creep

Since a client is buying into an existing system, chances are they can trial that system before they commit to using it. Since the client knows exactly what they’re getting and has already taken part of the system for a test drive, the requirements are less likely to change, reducing scope creep.

Less support

Since you’re building less, it means you handle less of the support after launch. There can be positives to this for the client too such as a reduced retainer cost and perhaps a better response rate than your team could provide. This also means that the client is less reliant on you or your company in the future, which could go a long way towards easing their minds!

A solid platform

By buying into an existing ecosystem, some of your application has been built and tested already.

A balancing act

Of course, it’s not always as simple as integrating. If nobody built their own roller coasters, there wouldn't be a theme park to buy an annual pass for!

It wasn’t long ago that every agency and freelancer had their own custom CMS they’d use for client projects. We decided that was a bad idea. But equally, not every website should be built with Wix, Squarespace or Shopify. There’s often a trade-off between bespoke and prebuilt. Every project needs an evaluation. Integration may not always be the answer, but it should always be considered.