Choosing the Right Technology for Digital Transformation

When businesses start planning a digital transformation, it is very easy for the technology itself to become the centre of the conversation too early. The questions quickly turn to which platform should be used, whether the solution should be custom-built, whether an existing CMS can handle the job, or whether a cheaper off-the-shelf option could achieve most of the same outcome.

Those are all valid questions, but they should come later.

The most important question at the start of any digital transformation project is not which technology should be used, but what business problem actually needs to be solved. If that problem is not properly understood first, there is a very real risk of selecting a platform because it appears cheaper, faster or more familiar, only to discover later that it cannot support the way the business needs to operate.

We were reminded of this recently when a large South African property business approached us to modernise its entire technology ecosystem. What initially appeared to include a website redevelopment quickly became something far broader, because once we understood how the organisation worked, it was clear that the problems extended far beyond an ageing public website.
 

The problem was much bigger than an outdated website

The organisation consisted of two sister property companies operating nationally across South Africa, with five branches and approximately 100 property agents. Commercial and residential property operated as separate parts of the business, each with its own workflows and requirements, but both were being held back by an increasingly fragmented and outdated technology environment.

The public-facing website had been built by a property industry provider and had become dated, restrictive and difficult to use. From a marketing perspective, there were obvious shortcomings around user experience, SEO, flexibility and the overall presentation of the brand.

But the bigger problems were behind the scenes.

The business also relied on a legacy mobile application that agents were supposed to use while working out in the field. Unfortunately, the app was unreliable and outdated, which meant many agents simply stopped using it consistently and reverted to tools that were quicker and easier for them, most notably WhatsApp.

Excel spreadsheets were also deeply embedded in the organisation, with leads, listings and other operational information being captured or managed manually. As a result, important information was being spread across different systems, spreadsheets and individual conversations, rather than being held in one central place where the business could properly track and report on it.

When your team starts working around your software

WhatsApp itself was not the problem. In fact, the agents were using it for a perfectly understandable reason: it worked.

The problem was that once a prospective customer's enquiry moved into an individual agent's WhatsApp account, the organisation effectively lost visibility over what happened next. Management could not reliably see whether that lead had been followed up, whether a viewing had been arranged, whether the opportunity was still active or whether the prospect had simply disappeared.

Some leads were also being allocated through Excel spreadsheets, which created another layer of risk. If someone did not see an update, forgot to check the spreadsheet or only picked it up later, an opportunity could easily be delayed or missed completely.

This is something we see quite often when reviewing ageing business systems. Employees create workarounds because the official software is too slow, too unreliable or simply does not reflect the way they actually work. Over time, those workarounds become part of the operating model, even though they create significant gaps in reporting, accountability and data quality.

When teams consistently work around the systems they have been given, the problem is often not the people. It is the technology.

The bigger issue was the lack of reliable, real-time data

For management, the situation created an even more serious problem.

Because information was being captured across multiple systems, Excel spreadsheets, a legacy app and individual conversations, there was no dependable central source of truth. Reporting was consequently delayed and often inaccurate, because someone first had to gather the information, reconcile it and prepare it before management could make sense of what was happening across the business.

By that point, the underlying data could already be out of date.

This matters because a report can look polished and complete while still being based on information that no longer reflects reality. Making business decisions on outdated or incomplete data is dangerous, particularly when that data is meant to inform sales performance, lead management, staffing, marketing investment or operational priorities.

What the leadership team really wanted was a live view of the business. They needed to understand how many leads were coming in, where those leads were going, how quickly agents were responding, which brokers were performing well, where opportunities were being lost and how the different branches were performing relative to one another.

Instead of seeing that information in real time, the business was effectively trying to reconstruct what had happened after the fact.

Property data was being duplicated when it should have been centralised

The property listing process created another layer of inefficiency.

Agents were entering information into the legacy mobile application, while other data was also being maintained in Excel spreadsheets. Listings then needed to be distributed to major South African property platforms such as Property24 and Private Property through the existing PropData ecosystem.

From a technology perspective, the desired model was quite clear. Property information should ideally be captured and managed once in a central system and then distributed to the places where it needs to appear, whether that is the public website, internal systems, the agent application or external property portals.

Instead, different parts of the organisation were managing similar information in multiple places, increasing the risk of duplication, inconsistency and unnecessary administration.

One of the fundamental principles behind the proposed new platform was therefore to create a single source of truth for listings, leads, agents and reporting, rather than allowing important operational data to remain fragmented across the business.

We spent weeks understanding the business before defining the solution

Before recommending any final technology architecture, we spent approximately four to six weeks working through the existing environment with the client's marketing and operations teams.

We were given access to their current systems and shown how they worked. We looked at where information originated, how leads moved through the organisation, how listings were managed, what external platforms needed to integrate with the business and where the greatest operational problems were occurring.

This process was important because the requirement was not simply to replace an old website with a better-looking one. We needed to understand how the different parts of the organisation connected and what the future platform would need to support across both sister companies, five branches and approximately 100 agents.

The proposed tech ecosystem ultimately included a completely rebuilt public-facing property platform, centralised property and listing management, lead management, broker functionality, mobile applications for agents, real-time reporting, management dashboards, workflow automation and integrations with external industry platforms.

All of these components would operate from the same underlying technology foundation, which would finally give the organisation a consistent view of its properties, leads, agents, activity and performance.

The website was only one part of the wider ecosystem

The public-facing website remained an important part of the project, but it was only one part.

The site needed a far better user experience and substantially stronger SEO foundations, but it also had to support sophisticated property search, filtering, commercial and residential listings, enquiries and continually changing property data.

This distinction matters because a property website of this nature is not simply a marketing site containing a few pages about a company. It is a data-rich platform where users need to search, filter and interact with large volumes of structured information, and where the website must connect seamlessly with internal lead-management processes and external listing platforms.

Behind the website would therefore sit the systems responsible for managing the underlying data, user roles, lead workflows, reporting, integrations and automation.

This was why we never viewed the project as a website rebuild in isolation. It was an interconnected technology ecosystem where the public-facing experience and the internal operational systems needed to work together.

The technology also needed to remove unnecessary administration

Another major objective was to automate many of the tasks that were previously dependent on someone remembering to do them manually.

For example, incoming leads could be allocated to the appropriate agent, reminders could be generated when leads were not followed up, stale opportunities could be surfaced before they disappeared completely, listing expirations could trigger notifications, and management could be alerted when something required attention rather than only discovering the issue weeks later.

This is where digital transformation starts to create meaningful operational value. The purpose of automation is not simply to make an existing manual process happen slightly faster. It should remove unnecessary administration, create better visibility and reduce the likelihood of valuable opportunities being lost.

For the agents, the new mobile application would provide a better way to manage listings and leads while working away from the office. For management, the same underlying platform would make it possible to see broker activity, lead performance and business trends in real time. For marketing, the new website would provide a much stronger digital foundation for attracting and converting potential customers.

Different teams needed different interfaces and tools, but all of them needed to work from the same reliable data.

We deliberately planned the transformation in phases

Because the project involved so many parts of the business, we did not recommend replacing everything at once.

A large technology migration becomes substantially riskier when every system, process and integration is replaced simultaneously, so we worked with the client to define a phased rollout based on business priority, technical complexity, dependencies, risk and cost.

This approach also made sense commercially because the investment could be spread across multiple phases rather than requiring the organisation to fund the entire transformation upfront. The client liked this approach, and we worked together to refine the roadmap until everyone was aligned on the sequence and priorities.

The migration strategy was also designed around continuity. The intention was always to achieve a smooth transition with no unnecessary operational downtime, allowing the existing and new systems to coexist where required while data and functionality were moved across progressively.

By the end of the planning process, there was a clear roadmap for how the organisation could move from its fragmented legacy environment into a modern, connected technology platform.

The teams were aligned, the project had been verbally agreed and the paperwork was waiting to be signed. Then the direction changed!

A cheaper technology option changed the entire project

The main stakeholder had been introduced to another proposal recommending that WordPress be used instead.

It was presented as a considerably more cost-effective route, which understandably made it attractive from a purely upfront cost perspective. The problem was that the limitations and trade-offs associated with that decision did not appear to have been explained with the same level of detail.

We raised our concerns around the architecture, data structures, search requirements, integrations, scalability and the level of customisation that would be required to make WordPress support the broader platform requirements.

Ultimately, however, the decision had been made and the project stopped before development began.

It is important to make one thing clear here: we are not against WordPress. We have built many WordPress websites ourselves and continue to recommend it when it is the right technology for the job.

The problem was that this was not the right job for WordPress.

Why WordPress was the wrong tool for this particular platform

WordPress can be an excellent option for marketing websites, corporate websites and content-driven platforms where the primary requirement is to publish and manage content efficiently.

This project was very different though.

The technology needed to handle large volumes of structured and constantly changing property data, sophisticated search and filtering, lead-management workflows, broker activity, real-time reporting, external integrations, listing syndication, mobile applications and a central data architecture serving two businesses and multiple branches.

Trying to make WordPress the foundation of that ecosystem would have required significant customisation, a heavy reliance on plugins and a number of architectural compromises. Some requirements would have become unnecessarily complex, while others may simply not have been practical to implement properly.

There is a point where extending an off-the-shelf platform becomes less sensible than building a solution around the actual requirements.

If a business has to heavily modify an existing platform to make it behave like custom software, it is worth asking whether custom software would provide a cleaner and more sustainable foundation in the first place.

A cheaper proposal is not necessarily a cheaper solution

The WordPress option was clearly less expensive than the wider technology ecosystem we had scoped, but the two approaches were not really comparable.

One was designed to address the public website, internal operations, mobile applications, lead management, reporting, automation, data migration and third-party integrations as part of one connected transformation.

The other was a cheaper technology route being presented as though it could solve much of the same problem.

This is where technology buying decisions can become misleading. If two proposals do not provide the same capability, comparing them only on initial development cost tells you very little.

Businesses also need to evaluate whether the proposed technology can support the required functionality, how well it will integrate with the wider environment, how scalable it is likely to be, what compromises will need to be made and what those compromises may cost to maintain later.

A lower upfront price can be attractive, particularly when a transformation project represents a significant investment, but the cheapest technology is only genuinely cheaper if it solves the business problem properly.

We never got to see how the alternative approach played out

We did not build the project and were never brought back into the process, so we cannot fairly claim to know what happened after the direction changed.

What we do know is that the ageing website we were originally approached to replace is still running today.

We also know that the business problems uncovered during those weeks of planning did not disappear simply because a different technology was selected. Fragmented systems still needed to be addressed, Excel spreadsheets still needed to be replaced, lead-management challenges still required a solution, agents still needed more effective technology and management still needed better real-time visibility.

This is perhaps the most important point in the entire story.

Changing the proposed technology does not change the underlying business problem.

If a company has fragmented data, inefficient workflows, poor system adoption, limited reporting and missed opportunities, choosing a different platform does not make those challenges disappear. The technology still has to be capable of solving them.

This problem is no longer just about WordPress

Although this particular project involved WordPress, the lesson is much broader and is arguably even more relevant today.

Businesses now have access to an enormous range of technologies that promise to make software faster, cheaper and easier to build. There are low-code platforms, no-code tools, AI application builders, SaaS products, CRMs, ERP systems, website platforms and industry-specific solutions for almost every imaginable requirement.

Many of these are excellent technologies when used in the right context.

The problem begins when the organisation starts with the platform rather than the requirement.

A team decides it wants to use a particular CRM and then reshapes its processes around what the software supports. A business discovers an AI app builder and assumes it can become the foundation for a mission-critical internal system. Someone suggests Shopify, WordPress or a no-code platform because it appears cheaper and faster, and the technology decision is effectively made before the operational requirements have been properly understood.

The same principle applies in every case. Technology selection should follow problem definition, not replace it.

How should a business choose technology for a digital transformation?

Before deciding whether to use a CMS, SaaS product, low-code platform, AI builder or custom software, the organisation needs to understand how the business actually operates today and how it wants to operate in future.

That means looking at where information is created, how it moves through the organisation, which systems need to communicate with one another, where work is being duplicated, where staff have created informal workarounds and where opportunities are being lost because the technology does not support the process properly.

It also means understanding what information management needs in order to make better decisions, what customers expect from the digital experience and what the organisation may require from its technology several years from now.

Only after those questions have been answered can the available technology options be assessed properly.

In some cases, WordPress may be exactly the right answer. In others, an established SaaS platform could solve the requirement quickly and efficiently. Low-code and no-code tools can also be extremely valuable when the use case suits them.

There are also situations where the requirements are unique enough, strategically important enough or operationally complex enough that custom software provides the better long-term foundation.

The objective should never be to choose custom software for the sake of it. The objective should be to select the technology that best supports the problem the business is trying to solve.

Digital transformation is ultimately about business capability

One of the reasons digital transformation projects go wrong is that they are often described in terms of the technology being delivered.

A new website, a mobile app, a CRM, a reporting dashboard or a customer portal may all be part of the solution, but they are still only outputs.

The real value lies in what those technologies allow the organisation to do differently.

In this property business, the value was never simply about having a better-looking website or a newer mobile application. It was about reducing missed leads, removing duplicated administration, giving agents better tools, improving the customer experience, centralising property information and giving management a real-time view across two companies and multiple branches.

That is the difference between simply replacing old software and genuinely transforming the way a business operates.

Digital transformation should not be measured by how modern the technology looks, but by how much more capable the business becomes because of it.

Start with the business problem, then choose the technology

One of the easiest mistakes to make when modernising a business is to begin the project with a predetermined solution.

“We need WordPress.”

“We need a new app.”

“We want Salesforce.”

“We want to use AI.”

“We should build this with a no-code platform.”

Those statements may eventually be correct, but they should be conclusions rather than starting points.

A better conversation begins with understanding what is preventing the business from operating efficiently, where customers are experiencing friction, where information is being lost, which processes are unnecessarily manual, what data management cannot access and which systems need to work together.

Once those questions have been properly answered, the technology decision becomes far more informed.

The lesson from this project was not that WordPress is a bad platform. It was that even a good technology can be a very bad choice when it is applied to the wrong problem.

Understand the business first. Define the problem properly. Then choose the technology capable of solving it.
 

Planning a technology modernisation project?

If your organisation is working with outdated systems, fragmented data, manual processes or software that your teams are increasingly working around rather than working with, the answer is not necessarily to immediately replace everything.

The more valuable first step is to understand where the real problems are, how your systems and data connect, where operational inefficiencies exist and which changes will create the greatest impact for the business.

At Elemental, we help businesses plan and build custom web platforms, internal software, mobile applications and connected digital ecosystems by starting with the business problem before making the technology decision.

If you are planning a digital transformation or modernising legacy systems, speak to us about how to approach it properly before deciding what technology to build it with.

FAQS

What should come first in a digital transformation: the technology or the business requirements?

Business requirements should come first. Organisations need to understand their workflows, users, data, integrations, reporting needs and future growth before deciding which technology is most appropriate.

When should a business choose custom software instead of an off-the-shelf platform?

Custom software becomes worth considering when the organisation has complex or unique workflows, significant integration requirements, specialised data structures or operational requirements that would require extensive compromises in an off-the-shelf platform.

Is WordPress suitable for complex web applications?

WordPress is well suited to many content-led and marketing websites, but it can become a poor fit when a platform requires complex data structures, sophisticated workflows, extensive integrations, real-time reporting or application-like functionality.

Why do digital transformation projects fail?

Digital transformation projects can fail for many reasons, but a common problem is selecting technology before properly understanding the business requirements. This can lead to compromises, additional development, poor adoption and systems that fail to solve the original problem.