Extensibility, Portability, Scalability

Restrained by parameters, how do we ensure that the product we create is extensible, portable and scalable (value for money)?

5 minute read


Software development companies are fortunate, in that their employees (developers, designers and everyone else involved in the delivery of a technical product) are usually in this line of work because they really have the passion to do it. It’s not easy, it takes a certain mentality to learn and eventually master, and there are rarely individuals of low calibre involved – certainly in top city agencies.

This considered, it is always the case that whenever there is a feature up for implementation the team strive to do the best job they possibly can. The cutting of corners only ever occurs when the business (client-side) makes the call to push something out quickly, maybe for a marketing campaign or an event, or just a news bulletin.

It’s a remarkable industry to be involved in, and a privilege to associate with such level of professionals who enter at, typically, a young age and maintain passion and dedication throughout their careers.

The concepts of Extensibility, Portability and Scalability introduce a notion of generics into the product, which means that it is as transferable as possible regardless of how bespoke the specification. This carries value for money, as subsequent features, change in specification direction, extensions or refactors are reduced in complexity and scale.

Products should be as extensible, portable and scalable as possible. By introducing a generic element, additional value for money is attained and subsequent maintenance overhead is greatly reduced.


Often, during the feature development lifecycle, a junction appears in the road and designers and developers have to decide on an approach to take. Almost always there are several routes, with advantages and disadvantages associated similar to the example below…


On a FAQ listing page there are results and a filter-by-typing search bar. As a user I would like to be able to filter results by “text contains” as I type, on desktop and mobile.

Solution A:

Client-side filtering (JS)

Results are served to the page on page load, filtered subsequently in JavaScript. Results are delivered in bulk on page load



  • Fast to implement in client-side development
  • Requires minimal server-side development
  • Quick and easy solution
  • Difficult to unit test
  • Likely poor and inconsitent mobile performance
  • Not extensible for results of great number (40+)
  • Analytics data difficult to retrieve
  • Business logic in the presentation layer


Solution B:

WebApi driven AJAX filtering

A WebApi endpoint receives requests from the client and filters on the server.



  • Filtering logic can be made portable and reusable
  • Filtering of results is not dependent on platform performance
  • Filtering results can be cached
  • Business logic remains on the server, where it should be
  • Personalisation can be applied based on rules configured by the author (Sitecore)
  • Extensions more permissible, i.e. pagination, load-more etc.
  • With Sitecore CMS, this is not as straight forward with conventional architecture
  • Excessive implementation if result count < 20
  • Ultimately, it takes longer to implement


So there is no right or wrong answer; there are two possible solutions, one of which is more extensible and future proof, whilst the other is quick and easy to implement. One is probably overkill for the (current) requirements, but the other is at capacity if the requirements evolve. One can takes considerably longer than the other, but is more likely to stand the test of time, can have abstraction logic reused elsewhere and is primed if “little changes” appear in the requirements, in the short or long term.

Not in scope – why wouldn’t we just do the best one?

Features are based on requirements, and requirements are (hopefully) driven by ambition and goals optimistically derived from the business vision. Requirements are prioritised, slotted into a project plan which is moulded around the two fundamentals which fuel the project – delivery deadline and budget.

When either of those two are contested or subject to compromise in favour of an enhanced feature set, they rarely lose. This means, that regardless of having the best designers, developers and other skilled professionals involved, there are simply cases where best-in-class could not be achieved.

In such indeterminate situations, it is not developer responsibility to dictate the outcome, but merely advise and present the case to the business who make the decision.

In most cases, it is entirely possible (and thankfully commonplace) to be extensible, portable and scalable without huge effort overhead, and with the right approach when developing.

In Summary

Sadly, a number of legacy solutions in existence today won’t have had this luxury, which is likely due to the limitations defined above.

As a supplier

It is so important to reiterate the possibilities, regardless of whether or not they are chosen, when considering the future proofing of a feature. In agile delivery, where financial considerations are less impeding, there is no excuse for painting oneself into a corner in this regard.

As a client

It is important to consider exactly what the implications are of squeezing a project budget, rather than investing in robustness to make a more substantial saving long term.

More often than not, unfortunately, value for money is seen in the negotiated fixed price/fixed scope delivery secured by the short-term hire colleagues on the project who likely won't see it through until the end.


Positively, future proofing and top quality outputs are a key attribute of skilled professionals in the digital delivery world today. This could be due to its competiveness, or just the nature of the people involved. Either way, it’s an interesting place to be.


  • Best Practice
  • Extensible, Portable, Scalable
  • Delivery
  • Product Development
  • Consultancy
  • Enterprise
  • Advanced

Leave a comment