by Lisa
We're noticing a real trend in organisations of all sizes using SAAS applications inplace of having their own development done.
SaaS solutions are nothing new - it's been a term for years. But during the pandemic, the shift in people buying extra little bolt ons for this and that really shot up. But why are these options so appealing? And what are the pros and cons?
Budget
Let's start with what everyone would expect to be the obvious one - cost. You might expect paying a few pounds a month to a service would be cheaper than having something built yourself. Sometimes it is, sometimes it actually isn't. In an ideal world, have a chat with your developer about how much it'd cost to build something (be a dear and pay them for their time, seeing's you're actually using them as a Solutions Architect whilst you work out the pros and cons of other options) and compare that to a couple of years of subscription payments. Personally I'm shocked at how much some "little bolts ons" are per month, but then I see how AWS costs rack up (and how tech start ups have so many people working for them, to sell you the thing they're making) and I realise why they're priced so highly.
However, if you pay a monthly fee you're not having to pay a developer to look after and upgrade the feature if they'd custom coded it for you. And upgrades are coming thick and fast now a days as technology and security threats move on so quickly. So a small monthly fee can be a lot cheaper than that in the long run.
Timescales
It can be much quicker to just take something out of a box than to build it. Not always, but it should be generally. It does depend on the individual situation though. Similarly it can then take less company resource (by which I mean people's time) to just take something off the shelf rather than to get involved with a build project. But again, it depends on specifics so it's always worth checking with your developer.
Exact requirements
If you get something built, depending on your developer and your existing framework, it can in theory do exactly whatever you want it to. But herein lies what I think is the - perhaps subconscious - shift to so many small solutions. If a client briefs a developer on exactly what they want, and then it doesn't fulfill that brief, it's on them. Meanwhile, if they find a tool and say "the sales guy tells me this'll do everything I want" and get it signed off by someone else, then they're more in the clear. As more and more digital roles are created, they aren't all able to be filled with people who are bothered with the technicalities of how systems work or have headspace for answering some of the "but what in this scenario?" questions that a developer building it from scratch would need to ask.
It's much easier to be sold an existing, off the shelf product, than it is to stop and think about the exact requirements you want and see that through to completion.
There is also definitely something to be said for keeping things simple. We've got 2 clients at the moment who are headed in very different directions in this regard. Both membership organisations, one is bending over backwards to get their system to address every little indiosyncracy their members throw at it, never pushing back or saying "no, just pay online the way everyone else does". As a result, their website (behind the scenes) is very complicated and all little updates they want in the future will take a little longer to do because you're having to be so careful not to upset some other little complication.
Meanwhile the other client is taking features away that their members have had for years as they move to a solely hosted solution approach, joining together services that can be slightly tailored to their specifics, but at the same time need to remain quite generic, so can't be as tailored to their organisation as a bespoke build.
Which is right?
I can see why large organisations don't want members of their team getting bogged down in the finer details - sometimes too much choice (and bespoke development does give you ALL the choice, very often) just makes things grind to a halt. Or people who aren't necessarily the most pragmatic thinkers end up asking for things that blow the budget or make the code a mess. So setting boundaries, by selecting solutions which can only do so much, does get around that issue.
Personally I'd prefer a middle ground. I think it's important to offer your audience the best UX you can, whilst remaining pragmatic about budget, timescales and future technical debt (both time and money). I always try to steer clients - if they do want a bespoke feature added - towards features that can have more than one application, so they can be useful in more than one way, to make that feature work harder for your business. To try to illustrate that point I'll give an example - a client with a bespoke shop wanted to run an offer with a partner so asked for something very specific to be added for that offer. I suggested some tweaks to their brief which meant it took the same amount of time to build the feature, and so cost the same, but can be used in different ways by any partner going forwards.
Meanwhile, if there's a small little bolt on that costs a few pounds a month and does exactly what you need, then yeah, sign up, no point in reinventing the wheel.
Where I feel people maybe go too far is when their whole website or infratructure - and I'm only talking about large organisations here - is a series of hosted services. For me, that doesn't give the same business security as having your own code base which you can plug things in to. If those hosted services go down, you're in trouble. If they change their business practices, they can hold you hostage. For me, have your own central base and then plug things into that so that if you need to get rid of one of those services one day, you've still got your core and you can just replace the bit you needed to get rid of.
Maybe the organisations who are moving to rely solely on hosted services are happy to run the gauntlet and just face getting a new set up anytime things don't go their way - but for most of my clients, a website is an enormous investment that they want to work for them for years to come. (If you're a small company building your own website on SquareSpace or similar, then go for it. Worst comes to the worst, you'll need to spend a few more evenings building things again if you suddenly decide you don't like them anymore.)
The other side of the coin, is you have things specifically made to your requirements and your developer moves on or you fall out with your development team, it can be hard to find someone willing to pick up the pieces. Whereas if everything is just a series of bolt ons, it can be easier for someone new to come to it.
As with everything in this industry, it depends on the specifics. But my personal choice would be a stable core of your own code base, with various bits and pieces plugged into where they make life better, quicker and easier.
