Parrot Finance runs a social investing platform: a social trading app where users follow vetted influencers and copy their trades. Rebuilding one is not a redesign, and the first calls to get right are ordering calls rather than visual ones. Copy trading fixes the sharpest constraint on the build: users act on the price the moment they see it, so the feed decides the screens rather than the other way round. This post is the order that work ran in. The Parrot Finance case study holds the scope and the shipped product.
Why Parrot’s original platform needed rebuilding
Three systems carry an app like this: the screens users tap, the market data behind them, and the code that runs on the servers. Parrot’s three had drifted apart. Pages were slow to load, prices arrived late and alerts came after the move rather than before it. The rebuild had to fix all three together.
- Screens built around an older feature set, so the actions users take most cost more steps than they should
- Features that had fallen behind what a trading app is expected to do
- Prices that arrived late, and alerts that came after the move rather than before it
- Performance that fell short on the screens users open first
Parrot needed a rebuild, not a restyle.
Latent’s solution
We rebuilt in a set order, and every step constrained the one after it. The hardest screen came first, because it decides the components and the data shape that everything else reuses. Where an action sits beside a moving price, that screen also decides how the feed reaches every other screen in the product.
Finding that screen is a counting job, not a taste one: count the state each screen has to hold and the steps the action users come for most takes. The screen that carries the most of both is the one to draw first, because every screen after it reuses its components and its data shape. Get that call wrong and the rebuild pays for it later, at the point where changing the data shape is most expensive.
- Draw the hardest screens in Figma, for both clients, before any code exists. That screen carries the most state, so it fixes the components and the data shape the build inherits.
- Wire the feed before the screens that depend on it. Prices and alerts come from the Front API, so nothing waits on a nightly job.
- Build both clients on one stack: ReactJS and Node.js for web, React Native for mobile, all of it on AWS. Two stacks would have meant two products to maintain.
- Hand over as a step, not an afterthought: the repository, the deployment steps and the documentation travel to Parrot’s team in the same run as the last release.
The results
The rebuild left one product in place of three systems that had drifted apart, and one place to change when a screen changes. The ordering is what bought that: the data shape was settled once, early, on the screen with the most to say about it. The Parrot Finance case study covers the scope and what Parrot holds now.
Key takeaways
- A rebuild earns its keep at the screen users complain about most, not at the home page.
- Put the live feed in the order of work, not on a list of integrations. On a copy-trading app a late price is a product fault.
- Fix the order before you start: hardest screen, live feed, build, handover.
- Keep the repository and the deployment steps in the handover, so the product stays the team’s to extend.
If you are planning this work, list every system your platform touches and pick the one that hurts most. Start there. The rest gets easier once the hardest screen works. For the stack and the kinds of app we take on, see fintech app development.
← All articles