Building the TradePoint apps

Behind the scenes of an enterprise retail mobile app

As the Principal Software Engineer for Kingfisher PLC during the mobile app development of their banner, I’ve experienced first hand how the complexity of enterprise development extends far beyond the code itself.

You may have seen TikTok’s and YouTube videos of people developing and launching a mobile app in a weekend or less, more so these days with low code and ai solutions. So why do enterprise apps sometimes take 6 months or longer to develop and bring to market?

I would categorise an enterprise retail app in this context as one that is created for the purpose of ‘the enterprise’ to sell its services or products to the general public.

When most people think about building a mobile app, they imagine one or more app developers sitting at their desk, coding away in solitude, crafting features one by one.

Other developers may also share this perspective, especially if they’ve primarily worked on personal projects or in smaller teams. But building an enterprise retail app? That’s a different universe entirely.

Let me explain …

Building a retail app at the enterprise level isn’t just about writing good code — it’s about navigating a complex ecosystem of multiple development teams spread across different continents and time zones, legacy systems that have evolved over decades. Security protocols that must meet stringent enterprise standards. Performance requirements that must scale for thousands of concurrent users coupled with data systems that process millions of transactions and support teams that need to understand and maintain the solution

Each of these elements interacts with the others in ways that aren’t immediately obvious. A seemingly simple change to how product prices are displayed might need to account for multiple data sources, various tax rules, special business customer pricing, and regional variations — all while maintaining sub-second performance.

The Reality Behind Every Feature

What appears as a simple feature to users often conceals layers of complexity that would surprise most developers who may be entering a corporate app development context.

Take something as basic as showing a product’s price:

• The data might come from multiple systems, each with its own update cycles
• Tax calculations might vary based on the delivery location
• Promotional rules might need to be applied in real-time
• Performance caching needs to be balanced against data freshness
• The display format might need to accommodate multiple currencies and regional standards

And that’s just for displaying a price. When you start adding features like real-time stock checking and delivery options the complexity multiplies exponentially.

Real World Example : Click & Collect

The business would like to present customers with an option to purchase an item and collect it from an specific store.

Seems straightforward, right? As a solo developer, you might think: “I’ll just make an API call, get the data, and display it.” However in an enterprise environment, this apparently simple feature becomes a journey through a maze of teams, systems, and legacy decisions.

The feature may land as brief but quickly expand into multiple scenarios, some of which are not covered in the initial requirement or simply not considered important, an example of just some scenarios to cover are as follows ..

Feature: Product Click & Collect Availability

Background:
As a trade customer I want to know if I can collect products from my local store
So that I can get my materials quickly for my job
Scenario: Item available for 1-hour collection
Given I am logged in as a trade customer
And I am viewing a product page
And I have selected my preferred collection store
Given the store has 5 units in stock
And the store supports 1-hour collection service
And the current time is within store operating hours
And the store has collection capacity
When I view the collection options
Then I should see "Collect in 1 hour" as an option
And I should see "Available today until [store closing time]"
And I should see the store address

If I told you this was less than one tenth of the possible scenarios that could present in the response, I’d probably still be vastly underestimating.

Let me take you behind the scenes of implementing this seemingly simple feature in our TradePoint app. What customers see as a straightforward collection options display actually involves navigating through complex business logic buried in various layers of the organisation, APIs that require institutional knowledge to interpret correctly and business rules that oft-times exist only in the minds of long-time employees

Each scenario would be refined, the logic defined, data dependencies identified, the UX/UI mulled over, before being turned into code, unit tested, integrated built and tested again before being sent back to Product to verify for customer release.

The challenge isn’t just technical — it’s investigative. You find yourself becoming a digital detective, tracking down the right people who understand specific parts of the system, piecing together information from partial documentation, and reverse-engineering existing solutions to understand the “why” behind certain decisions.

When “Who Owns This?” Becomes Your Most Frequent Question

In a solo project, ownership is clear — it’s all you. In an enterprise environment, finding the right person to answer a question can become a project in itself. With development teams distributed globally and systems that have evolved over years, simply identifying who owns a particular service or can explain a specific business rule can take days of investigation and numerous conversations.

This challenge is amplified when dealing where critical features involve complex logic spanning multiple systems, teams, and business rules.

Luckily at Kingfisher PLC we’ve been working to put this to rights. Through internal forums and working groups, I’m normally able to find the answer I need or at least the person who can find the answer I need. A multi-national organisation can easily lose touch with itself, however the Kingfisher PLC engineering core has been able to evolve and join the dots more effectively than ever before, which makes it a great place to work.

Technical Innovation amid Complexity

Managing the requirements and data dependencies is part of an engineers role, the other significant part is defining the technology stacks that will deliver the solutions. This is what we refer to as the ‘How’, which is the juxtaposition of the ‘What’ in the Product World.

In an enterprise context the Product teams own ‘What’ the customer wants, Engineering teams own ‘How’ the want is delivered.

One of the most exciting aspects of the TradePoint project was starting with a clean slate. As a greenfield build, we had the opportunity to make strategic technology choices that would set us up for long-term success. However, we were careful to avoid the trap of “shiny object syndrome” — every technology decision was driven by clear business and technical benefits.

The five strategic decisions that helped us deliver the ‘How’ are as follows.

1. Shared Code with Kotlin Multiplatform

In a traditional retail app development scenario, you’d have separate teams implementing the same business logic twice — once for iOS and once for Android. This approach not only doubles the work but also increases the risk of inconsistencies. By adopting Kotlin Multiplatform (KMP), we were able to write core business logic and networking code once and share it across both platforms.

This meant that critical features like product data handling and Search and Browse only needed to be implemented and tested once. When we found and fixed a defect in the networking layer, it was fixed for both platforms simultaneously. This approach not only accelerated our development but also ensured a consistent experience across platforms.

2. Platform-Specific Excellence: Embracing Native UI

While sharing business logic through KMP was crucial for efficiency, we recognised that a great user experience means embracing each platform’s unique characteristics. This is where SwiftUI for iOS and Jetpack Compose for Android came into play — two modern declarative UI frameworks that allowed us to create authentic native experiences while maintaining development efficiency.

Gone are the days of clunky, obvious cross-platform apps that feel out of place on either platform. Using SwiftUI and Jetpack Compose allowed us to:

Embrace platform-specific navigation patterns (back swipes on iOS, back button on Android)

Utilise native components that users instinctively understand (action sheets on iOS, bottom sheets on Android)

Implement platform-specific animations and transitions that feel natural

3. Balancing Consistency with Platform Identity

The trick wasn’t just in using native UI frameworks — it was in knowing when to maintain consistency across platforms and when to diverge for platform authenticity. We established a design system that:

Maintained consistent branding and core functionality

Adapted to platform-specific patterns for interaction design

Used native gestures and animations that users expect

Preserved platform-specific accessibility features

This approach meant that whether a customer was using an iPhone 16 Pro or a Samsung Galaxy, they got an experience that felt natural and intuitive for their device, while still maintaining the TradePoint brand identity.

4. GraphQL: Taking Control of Our Data

One of the biggest challenges in enterprise development is efficiently managing data from multiple sources. Traditional REST APIs often lead to two common problems:

Over-fetching: Imagine asking for a friend’s phone number but receiving their entire life history. This is over-fetching — receiving more data than you need, which is especially problematic on mobile networks.

The “n+1” problem: Loading a product list, then making separate API calls for delivery options, stock status, and pricing for each product.

By implementing a GraphQL Backend-For-Frontend (BFF) layer, we gained precise control over our data requirements. This meant the mobile apps could request exactly the data they needed, no more and no less. Multiple data sources could be combined in a single request and we could adapt and reshape backend data to perfectly fit our mobile needs without requiring changes to core enterprise services

5. Modern CI/CD: Building for Speed and Reliability

Enterprise mobile development often struggles with slow deployment cycles and complex release processes. We broke this paradigm by implementing a mobile-first CI/CD system that could, build and deploy multiple times per day. Target different audiences (internal testing, beta users, production) with different configurations. Automatically run comprehensive test suites whilst managing iOS and Android releases from the same pipeline

This meant we could rapidly iterate on features, get quick feedback from users, and maintain high quality through automated testing. When critical fixes were needed, we could deploy them quickly and confidently.

Enterprise Teams

In this section, I’d like to reflect on how key it was to enable others in this programme of work to arrive at a team that pulled in the same direction.

The most valuable lesson wasn’t technical at all — it was learning how to navigate the human aspects of enterprise development. Success in this environment requires 4 key disciplines:

1. Building relationships across teams and time zones

2. Developing diplomatic skills to negotiate technical decisions

3. Understanding that documentation is as much about people as it is about code

4. Recognising that every system has its history & reasons for being the way it is

Advice for Aspiring Enterprise App Developers

If you’re moving from solo to enterprise development, here are 5 important pointers:

1. Technical excellence is just the beginning — people skills are equally important

2. Documentation archaeology becomes a critical skill

3. Patience and persistence are your best friends

4. Building relationships is as important as building features

5. Master the art of delegation and empowerment

That last point deserves special attention. One of the most crucial transitions when moving into enterprise development is learning to let go. As a solo developer, you’re used to having your hands in every piece of code. In an enterprise environment, success comes from these 5 tips:

1. Identifying clear, well-defined chunks of work that can be owned end-to-end by team members

2. Trusting your team with meaningful responsibilities rather than just tasks

3. Creating opportunities for others to showcase their skills and grow

4. Understanding that giving others ownership not only motivates them but also multiplies what the team can achieve

5. Providing support and guidance while resisting the urge to micromanage

The magic happens when team members feel true ownership of their work. I’ve seen developers transform challenging features into elegant solutions simply because they felt empowered to make decisions and take initiative. This not only leads to better technical outcomes but also builds a more resilient and capable team.

Key Takeaways

In this section, I’ll cover my 3 key takeaways for success in an enterprise development programme.

1. Take action

A valuable piece of advice, which may sound simple, is to ‘just get on with it’. Many a project suffers paralysis through over-engineering and remains on the table, to slowly wither away as its oxygen inevitably depletes over time.

During enterprise development its all too easy to get lost in a maze of conflicting initiatives, that can hamstring progress. Being brave, focussed and getting on with the job at hand with all the noise surrounding an enterprise pays dividends.

2. Build for Scale and Sustainability

Our experience has shown that the future of enterprise development lies not just in writing code that works today, but when building systems that bear these 5 pieces of advice in mind.

1. Adapt to changing business needs

2. Scale with growing user bases

3. Evolve with new technologies

4. Be maintained by future teams

5. Remain resilient in the face of organisational changes

3. The Human Element Remains Critical

I haven’t spoken about AI, an aspect that will no doubt creep further into enterprise as time goes by, however, one thing that won’t change is the importance of the human touch in development. If anything, as systems become more complex and interconnected, the ability for personal skills in order to master the following.

1. Navigation of organisational relationships

2. Building consensus across teams

3. Mentoring and empowering others

4. Understanding and translating business needs into technical solutions

These skills will become even more crucial. The successful enterprise developers of tomorrow will need to be as skilled in communication and collaboration as they are in coding.

The Road Ahead …

The lines between solo development and enterprise development are starting to blur. Modern tools and practices we employed, such as KMP, GraphQL, and declarative UI frameworks, are making it possible to maintain the agility of smaller teams while operating at enterprise scale. This trend will likely continue as cross-platform tools become more sophisticated while maintaining native feel, API technologies evolve to better handle complex data requirements and CI/CD pipelines become more intelligent and automated.

As we look to the future, it’s clear that enterprise mobile app development will continue to present unique challenges and opportunities. The key to success will be finding the right balance between these 5 drivers of success:

1. Innovation and stability

2. Speed and quality

3. Standardisation and flexibility

4. Technical excellence and customer experience

5. Global reach and local relevance

For those embarking on similar journeys, its often quoted that enterprise app development is a marathon, not a sprint, actually it’s neither. It’s a series of sprints with some easy runs interspersed between and maybe a scramble at the end. Whatever the tactics, the objective is to complete the course in a timely fashion. Most of the energy and skill, just as in a plane taking off and landing is expanded at the beginning and the end, the trick is not stalling in the middle.

The complexity we’ve discussed isn’t a burden to be eliminated but a reality to be embraced and managed. The most successful projects will be those that can harness this complexity to create solutions that are greater than the sum of their parts.

In the end, building an enterprise retail app isn’t just about creating software — it’s about orchestrating people, processes, and technology to create something that provides real value to customers while being maintainable, scalable, and adaptable for years to come. What you are building is not just an app but a platform from which you can deliver a product that happens to be an app.

We are really excited at Kingfisher PLC about the new TradePoint app and there are already a host of new features and platform upgrades planned for 2025, become part of this journey by visiting our .

TradePoint: Available on the App Stores

and