Bullionaire: a React Native app, web and publishing backend on one market-data contract

This was a custom React Native app and CMS build. One shared price contract sits behind the phone app, the website and the publishing backend. Bullionaire covers commodities news and market prices. The brief put articles, prices and personal watchlists in one place, so a reader can follow a market as well as read about it. Autonomous built the publishing backend, the React Native phone app, and later the website. React Native is a toolkit for building one phone app that runs on both iPhone and Android.

Autonomous is a Shopify systems agency for ecommerce founders and operators. Clients hire us for React Native app development for the same reason they hire us for Shopify: to stop a business paying twice to rebuild the same screens.

That mix creates two needs. Editors have to run the publication without asking an engineer to change the front page. And the product has to take in market data without tying every screen to the shape of one vendor’s reply.

This was a build from scratch. The lesson that travels is simple. Put a fixed contract between the outside services that change and the screens your customer uses.

We settled what the product had to show first. Then we made one backend hand over exactly those fields, whichever data vendor sat behind it. The backend uses Django and Wagtail. It serves both articles and market records through one API, the door other software knocks on to fetch data. The market side holds assets, watchlists and daily snapshots. The publishing side holds articles, authors and featured content.

The price contract is small: four fields. Current price, change in dollars, change as a percentage, and the time of the last update. Each vendor gets its own task, and every task writes those same four fields. So the phone app and the website draw the same shape, even when the source behind it changes.

The sources moved from Yahoo Finance to Financial Modeling Prep, and TradingView was added on top. Each one meant backend work, because every vendor names and fetches things its own way. None of it meant renaming the four fields the apps read.

Workflow: Market-data providers → Shared price contract → Backend API → Mobile and web.

The phone app and the website each serve their own kind of reader, and both read the same data from one backend. The phone app holds articles, market views, watchlists and links straight into a story. One shared piece of code handles price refresh. It stops when the app goes into the background and starts again when it comes back, so that behaviour lives in one place.

The website came later and reads the same backend. It uses the snapshot feed for the small trend charts, and the article feed for the writing. A different engineer built it after the phone work, which gave the shared contract a real second reader.

Editors control the featured items on the home page and the source list for market wires. Not everything is editable, though. Changing the sectors still needs front-end work. The freedom is real, but it stops at the controls we built.

Holding the right price is not the same as showing one price everywhere, and the gap between the two is where bugs live. One bug made that plain. A chart and a label beside it could refresh at different moments, so two numbers for the same asset were on screen at once. The team fixed the refresh pattern on the phone and wrote the trap down for the next piece of work.

The vendor code turned out to be less tidy than the stored contract. The three sources did not all follow one shared pattern. What held was the shape of the data the product reads. That is a useful split for a technical buyer. A neat-looking layer of code is worth less than a boundary the readers can count on.

The code includes review settings, database checks and a build pipeline on the backend. Automated tests of behaviour, though, are patchy across the product. So this case shows the design and the shipped screens. It does not claim that a build pipeline proves the product is well tested.

The three codebases hold the product screens and the shared API. The price fields stayed put while the sources changed, and the later website used the same contract. The publishing controls let editors shape, set parts of the reader experience without a code release.

The last commit we can see in the code is from July 2026. Everything above is drawn from those repositories, not from a vendor report. We cannot show a public launch, an app store listing, user counts or revenue for this one. It is a build story. The result is a joined-up design and three shipped screens, with a clean line between outside vendors and the data the product shows.