So, you’ve got an idea for a digital product. It could be anything; a mobile app, an enterprise service platform, a consumer-focused subscription service, whatever. No matter what type of software you’re developing, you’ll quickly find that there are myriad service providers out there with products that claim to make your build quicker and easier.
Need to take payments in your app? No problem says Stripe. Want a content management system for your marketing site? WordPress stands ready.
However, with each one of these services you use, you give up a bit of control. Each will need to be integrated ‘just so’ and have data presented to it in a prescribed and potentially inflexible way. Not only that but maybe you’re not comfortable locking yourself into a single service provider, or sharing your data with third-party companies.
In almost any digital product development, you’ll find yourself needing to weigh up these competing forces of convenience and control, and it’s not as easy a balance to strike as one may think. Based on our experience of projects that have been at either end of the scale, here are my thoughts on how to go about making that call
Bespoke build vs off the shelf
First up, the obvious – building an application (or a specific function of an application) bespoke gives you complete control of the end product.
Yes, building from scratch can potentially be an enormous task (encompassing everything from architecting the system to assembling the team, through to maintaining the system after delivery), but once it’s done, you’ve got the freedom to choose exactly how you control the data, user experience, branding, payments, access; the list goes on.
Buying an off the shelf component or product, on the other hand, provides you with a cost-effective, often quick solution that in most cases is robust and reliable. Plus, the reality is that these days, even if you’re not a developer, you can normally find a way to connect separate systems or functions using an automation service, such as Zapier.
As mentioned previously, however, the negative to this approach is a loss of control and a necessary willingness to share a portion of your data. Off the shelf products are, by definition, made to please as many people as possible, so if your requirements are more particular than most, you may find yourself compromising your product or service just to fit into third party systems.
The Goldilocks approach
In my experience, the best strategy for most projects is a Goldilocks approach; a considered mix of bespoke build and off the shelf functions that aim to be ‘just right’ for the particular project at hand.
The rub? Well, the real trick is deciding which bits of the project to buy, and which bits to build.
How to find your digital product’s ‘just right’
Sometimes, you can turn to the brief for help deciding what proportion of the product needs to be built from scratch.
For example, I can recall a digital product development where the brief dictated a need for very stringent security standards (see the case study here). This made decisions about third-party services and modules very easy; we used almost none, as our client was not comfortable with the risks posed by having third-party code plugged into their systems.
On the other end of the scale, there are briefs with tight resource constraints (e.g. budget or time). In this instance, when it’s about getting a digital product to market as quickly or as cost-efficiently as possible, we’ll typically make maximum use of third-party services as they are quicker and cheaper to implement (in the short term) than building and testing a function or module ourselves.
Of course, most projects will sit somewhere between these two extremes. You’ll have enough resource to make some of the build bespoke, giving the client a high level of control over the important parts of the product, but you’ll also need to use some third party services.
Prioritise value to the customer
For these ‘hybrid’ builds – which make up the majority of the projects we work on – my suggestion is to pick your battles and prioritise developing (from scratch) the parts of the application that add the most value to customers. Making sure you have maximum control and the ability to tailor these crucial elements exactly to your customer’s needs should give your product the best chance of succeeding.
If you’re not sure which elements of your product or idea add the most value, then it’s time to run a research project (sometimes called a discovery phase) to establish this. This process will likely involve competitor research, customer interviews, a design sprint and, towards the end, a prioritisation exercise (such as a MoSCoW Method) which will help crystalise which elements of your product are crucial to its success, and which are just nice to have.
For agencies, a note on client management
If you’re reading this as an agency or freelancer, don’t forget, that on top of all this you need to take your client’s expectations into account, too.
I raise this because it’s not unheard of to find clients pushing back against the idea of using prefab, off the shelf elements to complete their product or platform. There can be a perception that doing so is somehow lesser than building an element or function from scratch, so this is where you need to make sure that you’re explaining your choices properly to the client, and flagging up early what the benefits of these choices will be to the larger project.
If the client understands how much money and time can be saved by using, say, the Stripe payment platform, rather than building a bespoke checkout, and what benefit that saving could have if reallocated to more crucial parts of the digital product development project, then they are much more likely to sign it off.
Third-parties require due diligence
Clearly, third-party services have a place in most modern digital product development projects, but if you’re going to approach your build with a hybrid mindset what do you need to bear in mind?
Well, I’d argue that there are three primary bits of due diligence you, or your project team, need to carry out on each third-party supplier.
#1 – Data security
Highlighted as most client’s number one concern, data security is an ever more important factor when deciding whether to work with a service supplier.
Ask, are you comfortable running your data through their service and systems? I always think it’s important to find out where are they based, how long have they been around and who are they funded by. Secondly, what’s in the company’s T&C’s – will they get to hold your data, or have any rights to monetise it in any way?
These can be difficult questions to answer, but most reputable suppliers should be used to getting asked them and may even have a dedicated area within their FAQs. If you ask these questions and get hazy or evasive answers, time to look elsewhere.
#2 – Scalability
This is a tricky one to get good information on upfront, but it’s vital to know whether a service will be able to continue to serve you as you grow.
We’ve used services which cater really well for a user base of around 50k – the numbers stack up and it works out cost-effective – but if the product took off and, say, the user base quadrupled to 200k, it blows the numbers out of the water. This renders using that service completely ineffective from a cost reduction position and means you’d need to start the arduous task of finding a replacement service.
Viewed from this perspective, sometimes it’s better – in the long run – to work with a supplier that’s a little more expensive, but you know can scale, than with a cheaper alternative you’ll just have to replace in a year.
#3 – Reliability
As a new product, knowing your suppliers can support you reliably is key, as any early outages of your platform or product could irreparably damage your young brand.
This is a problem that can be avoided with an effective due diligence check, but quite often, some of the most attractive services can be susceptible to bad engineering.
I can recall an instance where we were looking at integrating a new search service called Algolia into a project. The platform was new to the market, with an exceptional offering, and everything pointed towards it being ideal. The system worked and ran very smoothly until we tried to contact their support team, who took over a week to reply to a very simple query (even on a paid contract). By the time they got back to us, we’d given up and moved on to a competing service. Thankfully, that was a while ago, and the company has since bucked up their ideas and improved their support processes (and we’re now a happy customer once again).
Final thoughts
I’ve tried to be balanced throughout this article, but if I’m honest, I’m a big believer in using as many existing services as possible in a digital product development. With thousands of stable, secure third-party services out there, most of which you can access at a fraction of the vanilla build cost, why wouldn’t you?
In fact, that’s kind of what I think the modern web is these days; a network of discrete, interconnectable services that business or product owners can pick or choose from. The challenge is to set up these services in a way that provides meaningful value to your end-user.
Naturally, there may be some extenuating circumstances, but for most projects, I think they offer more upside than down. Anything that helps reallocate resource away from the ‘generic’ parts of a build and towards the elements that add value to the end-user has to be a good thing in my book.
Think about it. At the end of the day, your users don’t care how it’s done, they just want your app or platform to fix a problem and be simple to use.
The post Digital product development: should you build or buy your services? appeared first on Browser London.
Top comments (0)