Development Choices, Benefits and Downsides - Common Core vs Custom vs Bespoke

When you decide you need an app or some sort of digital platform for your business, you have of course hundreds of possibilities typically as to which direction to take. There’s probably a tonne of generalist off-the-shelf solutions available which are near matches, as well as a number of more specialist options which have been tailored towards your particular type of business or sector.

Many people simply look at the most commonly used solutions by their competitors and then select one of those. Yet right from the offset there are a number of considerations that should be made, but are often overlooked:

Briefing and Specification

I cannot overstate the importance of the initial briefing process, which includes your complete requirements write-up - right through to your acceptance and sign-off on the solution vendor’s proposal. There are two things to be aware of here - requirements omissions and vendor oversell.

The vendor can only really quote and carry out work based on your specifications and requirements - it is up to you to do the due diligence to have a record of everything that is needed, including use cases and customer journeys. You cannot complain later when something potentially critical was left out of the development - if it was not mentioned in the brief nor properly covered off in the proposal. You cannot say ’oh but it was obvious’ - if so, then it should have been in the brief and proposal - it’s a legal agreement, and all legal agreements are eventually disputed on technicalities in enforcing the letters of intent, as written down - meaning if it’s not down in writing you cannot enforce.

Proposals tend usually to be negotiated on price, and if you want a keener price, you generally have to compromise by reducing your requirements to a certain degree. Some vendors can be unscrupulous in that they just say yes to everything and then keep sending you additional bills which end up at almost twice the assumed price. We at Affino will stick rigidly to the signed-off proposal, and systematically complete development and deployment of everything recorded there. Note that often there are compromises in functionality in the proposal too, as certain requirements just aren’t feasible - either for the timescale, for the pricing, or for the current state of that technology - so the proposal really is the bible and yardstick for what gets done, and as long as everything happens in accordance with the proposal - then you should not get any nasty surprises along the way. Be sure you read the proposal carefully to ensure it matches up with your requirements.

Be advised that often the theory does not hold out versus the practice, and sometimes things need to change during deployment - but there is a significant difference between an entirely new feature or change request vs technical issues in trying to achieve a certain pre-agreed function. For whatever is properly recorded and referenced in the proposal, Affino will endeavour to absorb incidental costs as certain parameters shift very slightly. Note though that if there is a technology- or industry-wide paradigm change, or change of mind by the customer, then Affino does reserve the right to re-quote for those sections / portions of the proposal.

Costs

You need to be aware that there are two essential costs to technical solutions- start-up cost - i.e. what it will take to get the initial version up; and overheads - your monthly and annual billings to maintain ongoing daily / monthly function for that solution. You will need to factor in both elements to accurately calculate and gauge the cost and value of what you’re getting. In fact to be totally accurate there are usually three costs, certainly as concerns Affino - the core solution cost, the custom development and the ongoing overheads.

When you buy something like Affino (an SaaS solution) within the initial cost is the setup and starting configuration - with whatever custom development the requirement / proposal sets out. There are then ongoing monthly licence and hosting charges to maintain the running of the solution. The degree of custom work / differentiation is usually the key factor here, and the one that makes up most of the early expenses.

Once you are up and running with a solution like Affino, your renewables should be relatively low-cost vs comparable technologies, especially as Affino consolidates so many different technologies into its core workings. When Affino is deployed on a customer’s site, it often replaces as many as 10-20 different incumbent solutions, each of which would have had its own ongoing overheads and renewable costs.

Maintenance

Maintenance - as is the case with much on this page, also covers two slightly different aspects. Maintenance of the core platform - i.e. the core renewable costs, and maintenance of any custom elements and integrations.

If you are not running something like Affino, say instead that you are running an enterprise stack of 20 or so disparate but API-integrated 3rd party solutions, then your Maintenance will likely be equally extreme - not just in terms of monetary overheads, but human resources too. For companies that have a complex hybrid technology infrastructure, their technical staff will spend a disproportionate amount of time simply just maintaining daily function, doing such tedious tasks as database cleanups and de-duping. Where with Affino, all core functions are run through the one single database, meaning staff are freed up to develop, evolve and improve the overall solution and connected services versus just managing to keep it all running.

It goes without saying that the more customisations and integrations you run, the higher your ongoing maintenance overheads. This will limit also how quickly you can react and respond to fleeting market opportunities, if you depend on several third party systems, turnaround will typically be slow. Also, at key junctures - like when there is a major industry step-change or paradigm shift, then having to rely on so many different diverse solutions will make it impossible to update and upgrade those quickly.

So above we have 3 of the key considerations that need to be made before you decide which route to take, and each will have a significant impact on the pros and cons of what you end up with, Next follows the 3 different paths you can follow or mix up as appropriate:

Common Core

For us, this is what is readily available in the system, or is being developed (for not too distant future release) as part of the system’s core evolution - meaning you don’t have to pay any extra beyond the core price list / monthly renewables - the functionality is either already working or coming soon on the road-map.

When we work on any iterations of Affino we normally get input from a broad range of our customers - benefiting from ’Hive Mind’ - where more thought has gone into the overall solution with likely more and smarter options and greater versatility developed than if a solution was created for just a single customer.

There are multiple benefits of going with the Core - including the ability to learn from what other customers are doing with the system, and copy / adapt their approaches. The Hive Mind approach is huge too in providing more feedback and consideration into the development - more experimentation and of course more testing than you would get with a more bespoke development.

So our advice would always be to explore what is available ’out-of-the-box’ first and how your requirements map onto that. You can look at other sites deployed on the technology and figure out what you like and dislike about those workings.

Custom

This can mean two things. Firstly, it is not always advisable to keep adding options into the Core Common solution, as you very quickly get to ’option paralysis’ and some of those settings may only ever be used by one customer. In those instances. we would build custom extensions to the core system - templates, scripts etc. to benefit solely individual customers, while maintaining simplicity and integrity of the core for everyone else. ’Custom’ itself can be quite broad, but as is becoming common say for instance in electric guitar specification - ’custom’ tends not to mean ’bespoke’ but rather more specific tailored option choices. So you don’t get a whole bespoke system, just a number of custom components.

As many of our Clients are currently undergoing the transition from Affino Classic to fully Responsive, they are discovering the additional cost of deploying custom components - particularly custom scripts and templates that were created for them several years ago. What this means is that if you had something developed custom for you in the past - the entire cost of that customisation, and the cost of maintenance thereof resides with you. When you then update your core platform, you will likely discover that you need to either invest in new / updated custom components / elements, or take an option B approach where you to try to replicate the same / similar out of the already-available components.

Custom in this sense will give you all the underpinnings of ’Hive Mind’ with an increased degree of flexibility and differentiation achieved by a few custom components. What many customers aren’t fully aware of is just how much Affino custom components are reliant on other Affino proprietary systems - meaning that they cannot be exported or replicated to other systems, and will not work outside of Affino. Nearly every custom component we build runs on top of and makes use of several of the core system’s functions. This gives you incredible cost savings and speed of development, but the infrastructure of those custom components is proprietary to core Affino.

Bespoke

This typically means building / developing something from scratch - meaning that the commissioning company is usually looking to own the IP of the inner workings of their app or digital platform. If you are intending on going to market at some stage, occasionally this is a requirement for certain types of investment.

Be warned though that this route is tortuously complex and expensive and time-consuming, and even having the time and the funds is no indicator of likely success. You will need to be in a position to hire the best minds and human resources to work on your solution - but as I’ve noted in ’Briefing and Specification’ above, if that part is not done properly then you are immediately heading for trouble.

There are so many key roles required at this level - you need the best specifiers, analysts, project managers and coders - who will not only develop something that works, but develop it in a format that can be ongoingly maintained and evolved. A number of these kinds of startups run into problems after the initial solution is launched, when some of the technical personnel decide to move on, and it is then discovered that the code is organised and marked up in such a way that it is almost impossible to decipher for personnel other than the original team deployed.

And much like ship building there are wholly different degrees of suitable crew when you compare those who built and launched the vessel versus those who need to man and sail it. So recruitment and retention is key here, as is ongoing documentation and management.

The immediate advantage of Bespoke is that hopefully you will have something wholly unique and innovative, but it will have cost you an arm and a leg to get there. Time and money are always key criteria for Bespoke as is continuity. With bespoke, your input, testing etc. is limited to your personnel - you don’t get the benefit of Hive Mind here, either in terms of innovations input or co-sponsorship - so you really need to carry this one alone - and that requires a number of really smart staffing choices.

We have pitched on many a project where the commissioning agent has decided that they had to go with bespoke - rather than Affino Core plus Customisations. Of all those fledgling companies we don’t believe any of them eventually made it - those that got the furthest were 3 years into development, when they often ran out of funds or hit other operational issues. We can’t recall a single successful iteration of those that passed on us; many ended up turning to off-the-shelf components in the end, but the business model was no longer the same.

We tend to recommend that in these instances the commissioning agents at least test the concept first with more of an off-the-shelf solution - a sort of proof of concept / prototype. If they can prove that this works, they can be more confident when they get to commissioning the bespoke work. All need to be mindful that development costs and timings can rapidly escalate, and in the end there are actually much greater risks associated with bespoke development than any of the other routes - but you know for sure that it will almost always take you longer and cost you more than you planned for.