Emergent Software works with retail and eCommerce organizations at different stages of growth, helping solve challenges across software development, cloud, data, and AI. The projects can vary, but they often start with the same question: how do we make the technology behind the business work better for the people relying on it every day?
In this client story roundup, we’re walking through four retail and eCommerce client wins:
Gladstone’s Window & Door Store: Modernizing the application behind the sales process.
A growing enterprise organization: Building a more reliable data foundation with Microsoft Fabric.
A rapidly expanding car wash chain: Bringing store operations data together for faster insights.
Each project started with a different problem, but all four show what can happen when the technology behind a retail business is customized to empower the business itself.
Gladstone’s Window & Door Store: Modernizing a Tool That Had Served the Business for Years
For nearly 20 years, Gladstone’s Window & Door Store relied on a custom desktop application to support one of the most important parts of its business: the sales process.
The family-owned Minnesota retailer had used the application since 2006 to build customer proposals, calculate pricing, estimate labor, and manage the details behind highly customized window and door projects. Over the years, it became deeply connected to the way the Gladstone team worked and played an important role in supporting the business as it grew.
Eventually, though, the company needed more flexibility than a desktop application built nearly two decades earlier could provide. Employees were increasingly working in ways the original application was never designed to support. The system was available only on select computers in the office, which made remote access and on-site use difficult. Project files were stored locally, backups required a manual process, and finding historical proposal information could take more time than the team wanted.
The application had done its job well for many years. Gladstone’s next step was making sure the technology behind its sales process could support the way the team wanted to work going forward.
Emergent Software began by working closely with Gladstone employees to understand the application they already knew so well. The goal was to preserve the business logic and functionality that made the existing system valuable while creating a more flexible experience around it. The discovery process also gave Gladstone an opportunity to incorporate improvements and features the team had wanted for some time.
From there, Emergent rebuilt the application as a modern web platform using Blazor WebAssembly and Microsoft Azure. One of the biggest changes was accessibility: the sales team can now securely use the application through a browser with their existing Microsoft credentials, whether they are in the office, working remotely, or meeting with a customer.
The new platform also makes everyday project management much easier. Instead of navigating individual files and folders, employees can search a centralized project database. Customer photos and project information live together, proposal templates are easier to configure, and proposals, purchase orders, and work orders can be generated directly from current project data.
Behind the scenes, Azure SQL Database and Blob Storage provide centralized cloud storage, backups are automated, and Azure Key Vault helps securely manage credentials. Emergent also introduced a CI/CD process so enhancements can be tested and reviewed before being released to the team.
For Gladstone, the project was less about replacing something that had failed and more about building on something that had already supported the company for a long time. The original application was created for the way the business operated in 2006. The new one gives Gladstone the flexibility to work the way it does today, while creating room for the application to continue evolving alongside the company.
That ultimately helps the sales team spend less time navigating the technology behind the process and more time focused on the customers and projects in front of them. It’s a good example of what retail software development can look like when the goal isn’t just to build something new, but to make an important part of the business easier to use and easier to grow with.
A Growing Organization: When Everyone Has Data, but the Numbers Still Don’t Quite Line Up
Data problems rarely begin with someone saying, “We have a data architecture problem.” Usually, someone in finance has one number, someone in operations has another, and the meeting spends the first 15 minutes figuring out why they don’t match.
That was the kind of situation facing another Emergent client.
The organization had an existing on-premises data warehouse, but the business had changed considerably since it was built. New systems had come into the picture, new data sources had been added, and different departments had developed their own ways of getting the information they needed. That meant a lot of spreadsheets, exports, reporting extracts, and manual reconciliation.
Finance needed one view of the business. Operations needed another. Product teams were looking at their own metrics, while leadership wanted a broader picture. None of that is unusual, but when the underlying data lives in too many places, it becomes surprisingly easy for two people to walk into the same meeting with two perfectly reasonable versions of the truth.
The company didn’t just want aesthetically pleasing dashboards. It needed to fix what was underneath them.
Emergent began by talking with stakeholders across departments about the reports they were using, the questions they were struggling to answer, and where they were losing confidence in the data. Those conversations helped the team separate the immediate reporting requests from the bigger issue. If the company wanted faster refreshes, more consistent metrics, and better visibility across the business, it first needed a place where the data could come together in a controlled, repeatable way.
Emergent recommended Microsoft Fabric and OneLake as that foundation.
Rather than asking the organization to commit to a large transformation based on a presentation, the team started with a proof of value. Key data sources were brought into OneLake, and the initial bronze layer was created so stakeholders could see their own information centralized and queryable in the new environment.
That early work helped make the idea tangible. The organization could see what a unified data environment would look like before committing to the larger roadmap.
From there, Emergent built out a layered architecture using bronze, silver, and gold data layers. Raw information could come in as-is, then be cleansed, standardized, and eventually shaped into business-ready data that reports and analytics could consistently use.
Security, data lineage, access controls, workspace structure, and repeatable ingestion patterns were designed into the environment from the start. That mattered because the goal wasn’t to create another platform only a consultant knew how to manage. Emergent also trained the internal team to extend pipelines, add new data sources, manage security, and monitor performance themselves.
The payoff is less dramatic than replacing a 20-year-old application, but anyone who has sat through a meeting arguing over whose spreadsheet is right knows how valuable it can be.
Teams now have a clearer path toward working from shared data instead of rebuilding the same answers in different places. Leadership gets a more consistent picture of the business, while the people closest to the data spend less time reconciling it before they can actually use it.
That becomes especially important in retail and eCommerce, where finance, inventory, product, supply chain, operations, marketing, and customer activity are constantly influencing one another. The more connected the business becomes, the more expensive disconnected data gets.
A Rapidly Expanding Car Wash Chain: When More Stores Mean More Data, but Not More Visibility
Opening another location gives a growing retail business more customers, more revenue opportunities, and more data.
A rapidly expanding regional car wash chain learned that as its footprint grew. The company had detailed operational information coming from its locations, including data from multiple point-of-sale systems such as Micrologic and DRB.
There was plenty to analyze. The harder part was getting all of it to tell a cohesive story.
Each POS system had its own structure and quirks. A metric that sounded straightforward on the surface could be defined differently depending on where the data came from. As the number of locations grew, leadership needed a consistent way to look across them without wondering whether a difference in the numbers reflected actual performance or simply a difference in how the underlying system recorded it.
The questions leadership wanted to answer were extremely practical: Are we staffing this location appropriately for the volume coming through it? How are subscription customers behaving compared with transactional customers? Which marketing efforts are paying off? Is one store genuinely outperforming another, or are we measuring them differently?
These aren’t once-a-quarter questions. For operators, many of them are most useful while there is still time to do something about the answer.
Emergent built a modern data platform on Microsoft Azure centered around a store operations data mart. Azure Data Factory pulls information from the company’s source systems into a medallion architecture, where it moves through bronze, silver, and gold layers before becoming analytics-ready.
Getting there required a fair amount of detective work. POS data can be messy, highly specialized, and not always documented in a way that makes sense outside the system itself. Emergent used AI-assisted development techniques to help interpret schemas, map transformations, generate pipeline logic, and validate data structures as the platform came together.
This is one practical example of AI in retail that has very little to do with a flashy customer-facing chatbot. AI helped the engineering team move faster through a difficult data environment, while the platform itself was designed to give operators better information about what was happening across the business.
The goal wasn’t to build an impressive data architecture for its own sake. It was to make store data useful while operators still had a chance to act on it.
The platform refreshes data every 15 to 60 minutes and can run queries across millions of records in fractions of a second. That creates very different possibilities for a metric such as cars per labor hour. If staffing efficiency is visible soon after it changes, operators have a much better opportunity to adjust. If the same information arrives days later, it mostly tells them what they wish they had done differently.
The platform also opens up a clearer view into customer behavior, subscriptions, service activity, marketing performance, and other areas that had previously been harder to connect.
Importantly, Emergent didn’t design the data model around a handful of reports leadership happened to want at the beginning of the project. The platform was structured around the underlying business processes so the company can keep asking new questions as priorities change.
That matters because the company is still growing, including through acquisition. Every acquisition can bring another location, another POS system, another way of organizing data, and another opportunity for the reporting environment to get messier. The platform was built with that reality in mind.
For a multi-location business, scale isn’t only about whether you can open the next store. It’s whether you can still understand what is happening across 10, 20, or 50 stores without creating a small army of people whose job is stitching the numbers together.
A Global Automotive Retailer: Turning a Complex Spreadsheet Into a Modern Platform
A global automotive provider relied on a highly sophisticated Excel workbook to manage monthly vehicle allocation across roughly 1,000 dealers. The workbook contained thousands of formulas, nested logic, and years of accumulated business rules that helped determine which vehicles went to which dealers, in what quantities, and when.
It had become one of the most important operational tools in the business, and crucially, it worked.
That last part made modernization complicated. When an old system is obviously broken, replacing it is relatively easy to justify. When the system produces trusted results but depends on a handful of people, manual SAP exports, countless formulas, and institutional knowledge, the risk looks very different.
Nobody wants to be the person who replaces the spreadsheet that handles vehicle allocation and discovers afterward that one obscure formula from tab 47 mattered a lot more than anyone realized.
There were problems around the process, though. SAP data had to be exported and refreshed manually. There was no comprehensive version history or audit trail. Reproducing exactly why a past allocation decision had been made could be difficult. A small number of people understood the deepest parts of the logic, which meant business continuity depended heavily on institutional knowledge.
The dealer side was fragmented too. Approximately 1,000 dealers were using email, spreadsheets, and PDFs to submit forecasts, check allocations, and communicate about the process.
The manufacturer wanted to modernize all of that without losing the trusted logic sitting inside Excel.
Emergent built a new enterprise allocation platform with two connected applications: an internal portal for allocation analysts and an external portal for the dealer network. The internal team can manage allocation cycles in one place, while dealers can submit forecasts, review allocation status, and access their own historical information without relying on long email chains and scattered files.
Behind both portals is a centralized allocation engine that recreates the workbook’s business logic in software. SAP data is ingested automatically into Azure, and Azure SQL Database provides a system of record where allocation inputs, adjustments, and decisions can be stored and queried over time.
The most important part of the build was not simply recreating the formulas. It was proving that the new application could be trusted as much as the old one.
Emergent took a parity-driven approach, repeatedly testing the new system against historical Excel outputs. Each piece of the allocation process had to produce the expected result before the team could move forward.
AI also became an important part of how the project itself was delivered. The engineering team used an AI-assisted development model in which AI maintained project context, helped plan and implement features, supported validation work, automated repeatable engineering tasks, and reviewed code within Azure DevOps.
That doesn’t mean the application was turned over to AI and hoped for the best. Human engineers remained responsible for architecture, code quality, business logic, validation, and production readiness. What AI did was give a small team more leverage against a very large amount of complexity.
Features that traditionally might have taken days to plan, implement, test, and review could sometimes move through that cycle in hours. For a project with thousands of formulas, complicated data flows, and a compressed delivery timeline, that speed mattered.
The finished platform changes both sides of the allocation process. Internally, allocation cycles that previously took days of manual work can now run in minutes. Analysts spend less time moving data around and maintaining spreadsheets and more time reviewing the decisions themselves.
For dealers, the experience is much more straightforward. Forecasts, allocation status, and historical information live in one place instead of being scattered between email attachments and files.
The business also gains something that is easy to underestimate until you need it: a clear record of what happened. Allocation inputs and decisions can be traced over time, and a process that once depended heavily on the knowledge inside a spreadsheet is now documented, testable, and repeatable.
Sometimes retail software development starts with an obviously outdated application. Other times, you realize the spreadsheet everyone is afraid to touch has quietly become one of the most important applications in the company.
Four Different Problems, but a Familiar Retail & eCommerce Story
These stories only show a few of the ways technology can support a retail or eCommerce business. For some organizations, the priority is a custom application that makes an important process easier. For others, it’s connecting data across locations, giving field teams better tools, or bringing more automation and intelligence into day-to-day operations.
Emergent Software works across that bigger technology environment, helping retail and eCommerce organizations connect commerce platforms with ERP, inventory, and fulfillment systems; bring sales and operational data into clearer reporting environments; build and modernize custom applications; and use cloud, AI, security, and managed services to support what comes next.
The specifics look different from one retailer to another, and that’s the point. The right solution depends on how your business operates, where the friction is today, and where you’re trying to go next.
Does any of this sound familiar? Reach out to Emergent Software to talk through what’s slowing your team down and what a better path forward could look like.
Author
Let’s Start Building Together
Whether you're modernizing legacy apps, strengthening your cloud security, or planning your next big initiative, Emergent Software is here to help.
