New digital products, applications and websites are created to serve organisational needs, transform and grow businesses, and deliver better user and customer experiences.

If you have a solid case for the launch of your project, and are beginning to plan its execution, one of the first decisions you’ll make with your team will be on which technology stack your product will reside. Should it utilise a framework? A CMS? A headless CMS? Which coding languages should you use and why? Should you build from scratch or will an off-the-shelf SaaS product suffice?

 Perhaps more to the point, should you even care?

The answer to that last question is a firm yes. Your chosen approach will dictate how smooth or challenging your journey will be. For you as a “product owner”, it also makes sense to understand the implications, limitations and benefits of your technical architecture.

Unfortunately, the question of the best approach isn’t one with a single, simple answer. If you choose a good development partner, however, you can lean on their expertise to chart the best path forward.

In this post we’ll unpack some general, “bird’s eye view” approaches along with a range of questions you’ll need to be able to answer.

So, what are your main options? While there are a variety of approaches to your project—whether it’s finite and stand-alone, or Agile and iterative—they can be grouped into three broad categories:

• Frameworks and Libraries
• Content Management Systems (CMS)
• Software as a Service (Saas)

Important note: these three major approaches do not have to be independent of each other. Depending on your needs, they can be combined or integrated.

A framework can be thought of as a developer toolkit that provides ready-made components, in a specific programming language, that helps to speed up the development process. Libraries refer to what can loosely be described as “pre-set functions” within a language. These pre-built components and functions can be meshed together to meet whatever the needs of your digital project might be, while being lean in code, high in performance, scalable, flexible and integratable.

There are frameworks available for most programming languages; for front-end like CSS and Javascript, back-end and server-based like Ruby, PHP, .NET and Python, and project-specific situations like mobile app development. Popular frameworks include Laravel, Symfony, Yii, CodeIgniter, Bootstrap, SASS, LESS, Angular, React, Vue and Xamarin.

Content management systems are built to manage web-based content and public-facing websites. Some of the more familiar open-source players include WordPress, Drupal, Wagtail, and Craft. A CMS-based website or application utilises the features and functionality of a pre-built platform, although the user interface is not necessarily ‘pre-designed’. CMSs have also evolved over time in many ways: use of block editors and builders, flexibility with cross platform integration, they’re more secure, faster, and more modular. We’ve also seen the rise of the “headless” CMS, whereby the front end is “decoupled” from the backend, and content can be delivered to multiple channels, devices and outputs via APIs for improved performance, flexibility and scalability.

SaaS products are more fully formed off-the-shelf products or tools, and are often licensed. Think those built to meet common business needs in areas like marketing, accounting, sales, client management, HR and communication. CMSs such as Shopify and Squarespace also fall into the SaaS category. SaaS can also encompass digital tools, plugins, or browser extensions. SaaS products tend to be limited for customisation, however as they often play a part of core business operations, they can offer opportunities for integration and to leverage data flows across a business’ digital ecosystem.

Do you need to develop a solution from the ground up? If you’re starting a blog, a wealth of solutions already exist. If you’re integrating A.I. into a government data repository to serve a niche industry, you’ll probably need to create your own. This question is about understanding your need for custom development. Analyse existing SaaS products—their structure, features, limitations and cost—and ask: is this capable? It might address a Phase One need, from which you could take learnings to reimagine it and tailor it to your needs.

If you’re developing a minimum viable product (MVP) or a minimum marketable product (MMP) you should take a pragmatic approach. Suitable tech will be rapid, flexible, scalable, extensible, iterable and pivotable. It will enable you to create a product that focuses on a core function and need—all those bells and whistles, those nice-to-haves, those things that ‘might be handy down the track’ should be ignored, as they run counter to an MVP/MMP mindset.

This mindset demands discipline and commitment. Perhaps a simple, core-value-focused version of your product can be developed rapidly and cheaply within a limited tech framework, such as one that isn’t scalable. With “proof of concept”, you could then pipe the product over to a more capable and scalable tech stack.

Ask: do we have to stick with the tech we’ve chosen for the lifetime of the project (or product cycle)? Should we be open to pivoting and changing our tech stack? Are the business or digital environments likely to change in a way that will impact our project or product?

Technology tends to degrade over time as the environment changes, which means it needs to be maintained, patched and updated. How much maintenance will your solution demand? Would another platform lower the amount of upkeep? Have you budgeted for this work? Does your chosen technology – and expertise of the development team – have the potential to generate unnecessary ‘technical debt’?

Look into your crystal ball and make an educated guess as to how your new product/app/system might need to talk to other systems in the future. Which systems will it encounter? What are they built on? Are APIs available? Will you build an API for your product? Gauge the likelihood, do a cost-benefit analysis, build a case. It could be a true standalone product, in which case you should focus on predicting the features and functionality that will prove valuable in the future, but that you can build cost-effectively right now.

There’s no one way to peel a carrot, but every chef has their preferred method that they’re adept with. The same can be said for your digital project: similar results can be achieved with any number of methods and languages, and the best way for you will depend on the preferences and skills of your dev team. If their preferred tech stack is capable of delivering what you need, it may be wise to stick with it. That said, if your team gets too comfortable in their particular development niche, you may be limiting your options down the track.

Talk to your team about where your new digital product will be hosted. This may raise a whole set of compatibility, performance, security, provisioning and deployment cycle issues that you haven’t yet considered.

Some stigma surrounds the term ‘legacy systems’. It conjures up images of archaic and outdated systems—a 30-year-old machine running MS-DOS in a dark, dank room. But this term can also be used for tried and true systems that work just fine.

If your legacy system is the latter, you’ll need to consider how it will work with your shiny new product. Can it be integrated? Should it stand alone? Do you perhaps need to extract data, get things working, then extract data again in a few months time when your system is built?

Perhaps the process of undertaking a digital project reveals issues with your legacy systems.
Perhaps you uncover just how much of a challenge it’ll be to move your staff to a new system.
Perhaps you can upgrade your existing system without starting afresh.
Perhaps you can redesign your website layouts and templates without forfeiting historical development.

• How much can you afford to spend initially?
• How much can you afford to spend post-launch?
• How much reinvestment do you expect?
• Which commercial model will you use, and how will you build it into the product?
• How will you define and prove success?
• Are you bootstrapping, or seeking external investment?
• Will your organisation provide future funding based on KPIs?

Be realistic and ruthless with budgets. Between shifting needs, priorities and scope creep, development costs can quickly blow out.

In tech, theoretically the greater the pre-existing functionality, the lower the start-up cost will be. However, there’s usually tradeoffs such as:

• Higher cost to customise
• Functionality and customisation limitations
• Licence fees
• Lower scalability
• More difficult to integrate

Custom development and the use of frameworks, meanwhile, will bring higher startup dev costs, but can bring a wealth of perks, including:

• Fit for purpose
• Leaner builds
• Greater flexibility
• Easier to iterate and pivot
• The opportunity for simpler and more streamlined future development.

In development terms, there’s no one way to implement your next project, to build your next product. Across the gamut of frameworks, languages, CMS and SaaS technologies, there are general approaches which need due consideration.

Be super clear on what your objective is. Work to form a strong rationale for your approach, and think about future needs. Take your legacy systems into account, and be open to change where needed. Keep an eye out for buggy and unscalable building systems. Build in flexibility so that you can pivot and iterate without undue cost.

Be aware that agencies and development teams tend to provide recommendations based on their strengths, which is fine, provided you’re aware of the future impacts of today’s decisions. Be clear on your cash limitations and where the dollars will come from in the future.

Take care with SaaS products and proprietary platforms— the devil is in the detail. They can be costly or difficult to customise, which can spell trouble if you end up too closely wedded to or embedded with their tech.

If you put in the time and effort to work out the best approach for your digital product – in partnership with your development team – you can be far more confident of long-term success.