Electronic Price Tag Platform and Dynamic Pricing Prototype

Problem

A retail technology company wanted electronic price tags that a shop could control from one central system. The prices had to change on their own, based on things like the weather and local events. The company needed an architecture for it, a working prototype and a team to build it.

Approach

• I redesigned the architecture of the existing price tag platform.
• I built a working prototype together with my team, including the backend and the pricing logic.
• I worked with the company that made our custom hardware, so the tags and the software fit together.
• I hired the developers, because there were no experienced ones left when I started. I also onboarded every new person.
• I led the development team and made the architecture decisions.
• I presented the product at industry conferences and joined the CEO in sales meetings with possible customers.
• Before I became the lead, I advised the company as a consultant on architecture, technology choices and hiring.

Architecture and design decisions

• I designed the platform as small services that talk to each other through events, using Kafka. The price tags and the backend are connected this way.
• The backend decides when a price should change, based on outside factors such as weather and local events.
• The stack was C# and Node.js on the backend, with Docker for packaging. Data lived in MSSQL, MongoDB and Redis.
• The tags were planned to work later as beacons for indoor navigation, so the design left room for that.

Reliability and performance

• I started moving the Docker setup to Kubernetes, but I left the company before it was finished.

Outcomes

• A working prototype of the electronic price tag platform, with a backend and dynamic pricing logic.
• A development team that I hired, onboarded and led.
• The product was shown at industry conferences and to possible enterprise customers.
• As a consultant, I influenced the architecture and technology choices, which made the system easier to scale and maintain.

Known gaps

• The prototype was not measured. I have no numbers for how much prices changed, how many tags it ran or how fast it was.
• I do not know how far the product got after I left, and this page does not say it was in wide use.
• I do not describe how the tags and the backend talked to each other at the hardware level.
• The move to Kubernetes was never finished, so I do not claim any result from it.