Six Years of Product Engineering for a UK Residential Property Data Platform

A product company rarely needs the same team shape for six years. Early in the roadmap, one specialist may be enough to unblock a backend. Later, the same product may need data engineering, APIs, frontend redevelopment, UX, QA, and delivery coordination at the same time.

That was the pattern behind Smartym Pro’s work with a UK residential property data and analytics platform. The engagement ran from 2016 to 2022 and grew from one Scala backend engineer into a flexible cross-functional team of up to eight specialists.

This extended case study focuses on the engineering work, the way the team changed with the product, and the practical lessons for CTOs building data-heavy SaaS platforms. For the visual summary and product screens, see the concise property data platform case study.

The engagement at a glance

• Period: 2016–2022
• Team size: from one specialist to approximately eight people
• Initial need: Scala backend support and stabilisation
• Expanded scope: backend, data ingestion, ETL, Java APIs, Vue.js and React frontend, maps, UX/UI, QA, and project management
• Delivery model: role-based team extension that evolved into a cross-functional product team
• Infrastructure and data: PostgreSQL, Amazon S3, Jenkins workflows, AWS Elastic Beanstalk, and heterogeneous property datasets

The engagement did not begin with a proposal for a large outsourced team. It began with a specific technical requirement and expanded only when the product created demand for additional capabilities.

Starting with one Scala backend engineer

In 2016, the platform’s CTO needed extra engineering support for the existing backend. Scala expertise was one of the reasons Smartym Pro was selected.

The first engineer worked on concrete backend problems:

• fixing issues in the existing Scala and Akka codebase;
• stabilising existing functionality;
• supporting data-ingestion processes;
• resolving backend problems around external datasets;
• helping maintain ETL-related workflows.

This was a focused team-extension engagement. The client retained product and architecture ownership, while Smartym Pro supplied the specialist capacity needed inside the existing engineering context.

The initial scope also created a useful proving period. Instead of committing to a large team before the working relationship was tested, both sides could evaluate technical fit, communication, and delivery through real production work.

As confidence grew, the engagement expanded. This progression—from a specialist role to a broader product team—is one of the practical team shapes described in our guide to dedicated team engagement models.

Building the data foundation behind property analytics

The platform depended on multiple classes of external property and market data. Inputs arrived from public, commercial, and sector-specific sources, often in different formats and through different collection mechanisms.

The engineering problem was not simply to fetch data. The platform needed a repeatable path from heterogeneous raw inputs to information the product could search, compare, map, and report.

A simplified flow looked like this:

External data sources
        ↓
Collection and ingestion
        ↓
Amazon S3 raw storage
        ↓
ETL workflows
        ↓
Cleaning, transformation, and normalisation
        ↓
Internal property data model
        ↓
Java APIs
        ↓
Web application and product workflows

Some historical collection processes ran as separate Jenkins jobs. Raw outputs were stored in Amazon S3 and then passed into ETL workflows. Keeping acquisition separate from transformation meant that source-specific collection logic did not have to define the product’s internal data model.

Smartym Pro contributed to both sides of this flow:

• backend and source-integration work;
• ingestion of external datasets;
• ETL and transformation workflows;
• cleaning and normalisation;
• PostgreSQL-backed data handling;
• Java API development;
• integration between the data layer and the customer-facing application.

The Java API work extended the original Scala backend scope. It gave the evolving product a clearer application and integration layer around the underlying property data.

For teams facing similar enterprise backend and integration work, this part of the engagement maps to our Java and enterprise engineering practice.

Redeveloping a data-heavy frontend: from Vue.js to React

As the platform matured, the engagement expanded from backend and data work into the web application.

Smartym Pro provided two to three frontend engineers during larger frontend phases. Their work included:

• redeveloping parts of the existing interface;
• improving frontend structure and maintainability;
• integrating the application with evolving backend APIs;
• improving data-loading behaviour;
• redesigning product workflows;
• supporting analytical charts, reports, and filters;
• improving the experience of working with large property datasets.

The first version of the frontend used JavaScript, Vue.js, Vuex, Chart.js, Webpack, and SCSS; the application was later rewritten in React. This was not a static dashboard: it was an analytical product in which users moved between maps, property records, comparisons, charts, and detailed filters.

In 2020, Smartym Pro participated in another major product redesign. By then, the system was already mature. The work was therefore not a greenfield visual refresh; it required adapting existing functionality and workflows while the product continued to operate and evolve.

The combination of gradual redevelopment and live-product constraints is typical of complex web application development rather than a one-off website build.

Map performance was a product problem, not just a UI task

The map was one of the core product interfaces. Users needed to explore geographically distributed properties while applying filters and working with market and property-level information.

That created a four-way engineering constraint:

Large datasets
    +
Interactive maps
    +
Browser performance
    +
Usable analytical workflows

Smartym Pro worked on loading strategies, UI bottlenecks, responsiveness during pan and zoom, interaction with property objects, and the usability of map-based workflows.

The important point is that map performance could not be isolated from backend and product decisions. How much data the API returned, when the frontend loaded it, how objects were grouped, and what a user needed to see at each zoom level all affected the experience.

This required collaboration between backend, frontend, data, and UX specialists rather than optimisation inside one component.

UX for complex analytical workflows

A Smartym Pro UX/UI designer joined the engagement as the product surface grew.

The design work included:

• analysing existing user journeys;
• simplifying complex screens;
• improving navigation and information architecture;
• redesigning map-related interaction;
• developing concepts for new product capabilities;
• helping users interpret dense analytical information.

The goal was not decoration. A property intelligence platform can expose a large amount of data while still making the user’s decision harder. The UX work focused on turning that data into workflows that property professionals could understand and operate.

This part of the engagement complemented the engineering team through UX/UI design for data-heavy products.

Adding a dedicated listings-acquisition capability

In 2020, the platform needed an additional category of market information: property listings published on estate-agency websites.

Smartym Pro developed a separate Scraper Manager for collecting and operating this data stream.

Estate-agency websites
        ↓
Scraper Manager
        ↓
Property listings
        ↓
Raw listing data
        ↓
ETL and normalisation
        ↓
Property data platform

The system supported the collection of listing information such as sale or rental status, asking prices, property characteristics, source details, and availability.

This capability did not simply replace the earlier Jenkins-based ingestion. It addressed a distinct source category with a different operational problem: multiple websites could change independently, while the platform still needed a central way to operate and maintain their scrapers.

Keeping this distinction clear matters. “Data ingestion” was not one subsystem; it included different acquisition patterns feeding a shared data and product layer.

Scaling the team with the roadmap

The team was not fixed for the whole engagement.

At different stages it included combinations of:

• one or two backend engineers;
• a data engineer working on ETL;
• two or three frontend engineers;
• a UX/UI designer;
• one or two data-acquisition engineers;
• QA;
• a project manager.

When the engineering group grew beyond approximately three people, Smartym Pro typically added QA and project-management capacity. During maintenance or incremental phases, the team could scale back down. Larger product initiatives brought the required disciplines back together.

This model allowed the client to add capacity without treating every project phase as a new vendor selection or permanent hiring decision. The company kept control of the product and architecture while Smartym Pro adjusted the delivery shape around the active roadmap.

The model combined elements of staff augmentation and a dedicated development team:

• role augmentation when one specialist was required;
• team extension when the client already provided day-to-day leadership;
• a broader cross-functional team during larger delivery phases.

What the partnership delivered

The strongest result was not one isolated release. It was the ability to support different layers of the same product over six years:

• stabilisation and continued development of the Scala backend;
• ingestion and transformation of heterogeneous external datasets;
• Amazon S3 raw-data workflows and ETL;
• Java API development and integrations;
• redevelopment of major frontend areas;
• map-performance and geospatial UX work;
• UX/UI support for complex analytical journeys;
• a separate listings-acquisition and scraper-management capability;
• flexible access to engineering, QA, design, and delivery roles.

We do not attach unverified percentages to those outcomes. The available project history supports the scope, duration, and team evolution, but not a defensible “three-times faster” or “X% fewer errors” claim.

For an engineering buyer, that distinction matters. A case study should show what was built and how a delivery model worked—not manufacture precision that the project records cannot support.

Lessons for CTOs building data-heavy SaaS products

Start with the bottleneck, not the final org chart

The engagement began with one scarce competency: Scala backend expertise. A larger team followed only after the relationship and product demand justified it.

Data acquisition and product delivery are connected

Source collection, ETL, APIs, maps, and UX were not independent workstreams. Decisions in one layer shaped performance and usability in the others.

A mature product needs different team shapes over time

Backend stabilisation, a frontend redesign, scraper operations, and maintenance do not require identical staffing. A team that can scale by competency is more useful than a fixed roster disconnected from the roadmap.

UX is part of analytical accuracy

For a data-heavy platform, presenting more information is not automatically better. Navigation, filtering, map interaction, and information hierarchy determine whether users can make sense of the analysis.

Long engagements still need bounded phases

A six-year partnership should not mean one endless project. The engagement moved through concrete phases: backend support, data and API work, frontend redevelopment, map optimisation, UX, listings acquisition, and mature-product support.

From specialist support to product partnership

This partnership demonstrates a practical path for extending an engineering organisation without choosing one team shape forever.

Start with the missing expertise. Add the roles required by the next product constraint. Introduce QA and delivery management when coordination becomes a bottleneck. Scale down when the roadmap moves into a quieter phase.

That approach allowed Smartym Pro to support the property data platform across backend, data, frontend, maps, and UX from 2016 to 2022 while the client retained ownership of the product and its engineering direction.

View the concise visual property data platform case study →

---

Building a data-heavy SaaS product or deciding between one specialist and a cross-functional team? Tell us about the current bottleneck.