Six technical considerations to reduce risk when building an online community platform.

If you’re looking to build and foster an engaged online community, you have multiple options for the best way forward. How do you choose the optimal approach and reduce risk in the midst of known unknowns?

Depending on the type of community you intend to build and support, you likely have one of three options from a technical perspective.

1. Build your own platform from the ground up. This can be more resource intensive, time-consuming, and risky than the two option below, but it ensures you have granular control over nearly every aspect of the project from the very start. Before you get to the technical questions we mention in this article, it’s vital that you determine whether your team has the capability to deliver on time and on budget or whether you may need to engage specialists to help you.

2. Use a software-as-a-service solution. This approach is significantly quicker. However, given you won’t be hosting the solution nor have access to the underlying codebase; you’re stuck with whatever features and functions you get ‘out of the box’. There’s no room to customise or configure things to align with the unique needs of your community.

3. Customise or augment an existing white-label platform. With the right approach, this can offer the best of both worlds: speed and flexibility to deliver on the unique needs of your community.

That said, if you take option three without doing your due diligence in platform research, there’s every chance you can hit roadblocks along the way as the scale and functional requirements of your community evolves.

Here are the six questions you need to ask—or things to assess—before making your decision.

1. How easy, or difficult, is it to modify the codebase?

This consideration relates to how much you’ll want—or need—to customise different elements of the platform you intend to build.

Any platform you white-label will come with core functionalities. In the context of a community platform, you might have a standardised set of features that allow you to quickly set up community forums, for example.

A codebase that is easier to modify gives you greater flexibility for theming and branding the visual interface of the platform itself, which in turn provides a better connection for your audience. Beyond branding and visual delight, a more flexible codebase will also allow you to drastically improve accessibility, if that’s a consideration for your project.

The structure of the code is a significant consideration. Some platforms come with ‘hooks’ or in-built mechanisms that allow you to easily add different functionalities. Others will require your development team to modify the core codebase to make certain additions.

There’s a balancing act here, as too much modification of the core codebase can make it difficult to implement or inherit rolling platform updates in the future.

How do you assess flexibility and get a sense of the core codebase? Typically, the go-to protocol is to analyse developer documentation or tinker with a test environment, which offers a perfect segue to the next consideration.

2. What is the nature of developer support for the platform?

Reviewing developer documentation is one of the surest ways to determine:

• The flexibility of the codebase (how easy it is to make updates or tweaks to ‘out of the box’ functionality).

and

• The extensibility of the codebase – how easy it is to connect with additional systems and platforms, like customer relationship management (CRM) systems.

A platform with more extensive and thorough documentation is likely to provide a more accurate indication of the codebase’s flexibility.

The truest and most accurate test, however, will come from a test environment or developer instance. Ensuring your development team has the ability to get under the bonnet before committing to the platform is the best way to assess flexibility and remove the risk of being constrained in your options for the future.

3. How easy is it to integrate the platform with other applications and plugins?

This consideration is all about planning for the growth of your community. That growth can refer to both the short and long term.

In the short term, easy integration allows you to leverage plugins or developer add-ons that already exist. This allows you to move quickly to market and roll-out new functionality for the community without investing time or money to build functionality that’s readily available. You can meet the evolving needs of your community in a fast and resource-effective manner.

If the platform is supported by a large developer community, it’s more likely to have a wide range of valuable and well-built plugin options. These can empower your team to quickly spin up sophisticated functionalities as different needs become apparent, like:

• Gamification, to incentivise more people to complete different actions within the community.
• Events calendars and booking systems, to allow people to arrange and host activities or meetups within the community.

Longer-term, ease of integration ensures you have scalability if your required functionality evolves over time. For example, if you want to integrate with a CRM so that you can track different customer journeys and community members’ relationships with your organisation.

4. What is the ongoing cost of licensing the platform?

The importance of this consideration is fairly self-evident.

Different platforms will offer different pricing models, so it’s worth considering your objectives for the community in both the short and long term.

For example, some platforms will charge a one-off fee, others will bill through recurring monthly or annual costs.

Some platforms offer pricing tiers or scaling costs based on the number of members that visit the community. For this reason, it’s worth considering any benchmarks you hope to achieve and the proposed trajectory of your member base: there’s a risk associated with building a highly customised platform in this pricing model and having an explosion in popularity mean that ongoing support of the platform becomes cost-prohibitive.

Depending on the nature of your organisation, it’s also worth considering any unique offers or discounts that developers may offer. For example, a wide range of platforms have distinct pricing options for not-for-profit organisations, which can be compelling.

And, finally, you should get a crystal clear understanding of who owns the data under the licensing arrangement, how that data is protected, and the process or cost involved in ending the agreement and leaving the service.

5. How frequently does the developer release updates to the baseline platform?

Frequent updates are a good indication of the health of a community platform. It’s a sign developers are actively working on improvements.

By contrast, a platform that isn’t updated regularly presents numerous ‘red flags’. That includes potential security risks. It may also be the case that the platform is nearing the end of its life and is no longer compatible with the kind of modern hosting environments or third-party systems you may want to integrate with.

To check the frequency of updates, check the release history along with a changelog of items they address. Most platforms will openly publish them, and they’ll include any security patches, bugfixes and new features added.

In some cases, developers will also publish a roadmap of upcoming features which can help to indicate if they are heading in a trajectory that aligns with your community needs. Which brings us neatly to the last, but certainly not the least, question worth asking.

6. What are the needs of the community—short and long-term—and how do they align with the platform in consideration?

All of these technical considerations are important in managing and reducing risk to your community platform.

Ultimately though, the technical solution you choose should be calibrated based on the outcomes you hope to deliver for your community members.

The importance of code flexibility, performance, cost, ease of integration, development community support and other platform requirements are best assessed in the context of project objectives.

When you’re looking for the best tool for the job, it’s crucial that the job (or more specifically, the jobs-to-be-done) are thoroughly documented and agreed upon by all key stakeholders involved in the project.

A strong starting point.

Should you ask more questions than the six above? In some cases, the answer could very well be yes, but with answers to those we’ve provided in this article you’ll be in a stronger starting position than before. They’ll provide you with some of the key information you need to make that momentous choice between building your own platform, using a software-as-a-service solution, and customising an existing white-label platform.

They’ll also reduce the risk associated with what has the potential to be a large, expensive project.

If you’d like to chat more about the technical aspects of building an online community, or anything related to the development side of digital platforms, get in touch. We’re always happy to chat.