iOS & Android App for a Hardware Store
An e-commerce app that brought a hardware store with no mobile presence onto iOS and Android - without touching their existing ERP system.
- Role
- Full-stack Developer (solo)
- Stack
- React Native · Express.js · REST API · SQLite
A digital gap that had sat there for years
Our client was a well-known hardware store in their region. They had a website. They had heavy foot traffic. What they didn't have was anything to offer customers who wanted to shop from their phones.
The constraint was set on day one, and it wasn't about the app: don't change the ERP. The stock management system they had been running for years was working, the team knew how to use it, and the entire product / price / stock data lived inside it. What we were asked to do was to build a mobile layer on top of that system - without disturbing it.
“Build a new mobile layer on top of the existing system without changing it.”
Our Approach
There was a choice to make going in: either try to modernize the ERP and open up an unbounded transformation, or accept the existing system as-is and build a bridge on top of it. We chose the second. The client's day-to-day operations needed to keep running, and our work needed to move independently.
So we built a bridge backend in Express.js: it pulled data from the ERP, translated it into something the mobile app could understand, and cached what made sense to cache. The mobile app never spoke to the ERP directly - only to our API.
Technical Decisions
Working with an undocumented API
The company that built the client's ERP system offered an API that had no written documentation at all. When we talked to them, even they couldn't give a clear answer about what some endpoints returned. Before deciding anything, we had to get to know the system: for a few weeks we tested every endpoint one by one, mapped out the response formats, and figured out what each field meant through trial and error. Our Express.js backend then turned that chaotic source into a clean REST API the mobile app could work with.
React Native for a single codebase
One developer, four months, two platforms (iOS + Android). Going native wasn't an option at that scope. With React Native we shipped to both platforms from a single codebase, and added native bridges where they were actually needed (push notifications, payment flow). The result was something close to a native experience without doubling the development time.
Offline-first product catalog
A hardware store customer is often inside the store, behind a stockroom, or somewhere with poor mobile reception. Having to re-download every page on every visit wouldn't be a good experience. With a combination of AsyncStorage and SQLite, we built a caching layer: once a user has browsed the catalog, they can keep looking at products and adding to cart even offline. A connection is only required to finalize the order.
Secure payment flow
Payments carry a different kind of weight. Card details were never stored in the app or on our backend - we used a PCI-compliant payment provider's token system. The user entered their card directly into the provider's secure form, and we only received a token back to finalize the order. That kept the legal load off us and left the security responsibility where it belongs: with the payment provider.
From the UI
Outcome & Impact
By the end of the four months, the app was live on both the App Store and Google Play. The client made their offering available on mobile devices for the first time, extending a digital presence that had only existed on the web for years.
The more lasting win was on the architecture side. The existing ERP wasn't touched - an API bridge was built on top of it instead. Stock and price data synced in real time, and the store team never had to leave the systems they were used to. That approach - keeping older but essential systems intact and layering new digital channels on top of them - is still a reference point we work from.
Got something we could build on top of your existing systems?
An ERP that's been running for years, an old but essential backend, an API that's hard to integrate with? Let's talk about building a new layer on top.
Get a Quote