FanMsn is the app you use to write straight to the celebrities you follow: direct messages to creators and public figures, from the app or from the browser. One thing belongs right at the top, because it makes this case study different from the others: it is not my product. It belongs to RJC Soft, where I work as Team Leader. I led the frontend, drove development and stayed with it all the way onto the stores.
The problem
A business tool roughly knows how many people will open it on Monday morning. An app where you write to someone famous does not: that person mentions it once and by the evening there are people who were not there at breakfast. You cannot size everything for the worst case, nor afford the good night to be the one night the app will not open.
When two people message each other inside a product, the product answers for whatever goes through it. Reporting, blocking, stepping in: those have to exist before launch, not get bolted on once the problem has happened. On an app open to anyone, that is the price of entry to the stores, not a nice extra.
Apple and Google look harder at apps where users message each other and where a public person is involved. A rejected build is not just a few days lost: it is a launch date gone, while a whole team has already done its work and is standing there waiting.
My role
In a team, the what is decided by whoever owns the product. My job was making sure the decisions actually shipped: written once, written the same way by everyone, and sent down a road we had already walked.
1
Put several people on the same frontend and the choices multiply: how state is handled, how the app talks to the server, when a piece of interface earns the right to become a reusable component. We made those calls once and wrote them down, so every new screen starts off pointed the right way instead of reopening the same argument.
2
Naming, folder structure, formatting, what gets reviewed and what does not. This is not paperwork: it is the difference between a file anyone can open and fix and a file only its author dares to touch. In a team, the second kind is not expertise, it is exposure.
3
Publishing is not the last box to tick. What the stores ask for goes into the plan at the start: how the shipping build is produced, what the listing needs, who answers when a reviewer comes back with a question. Getting there ready means shipping when you need to, not when it happens to work out.
Architecture→ Standards→ Code review→ Build→ Release
Under the hood
Keeping two separate products alive would have meant twice the work and twice the ways to get it wrong. FanMsn is used from the app or from the browser, but underneath it is the same thing.
People who install the app and people who open the site see the same product because the code underneath is the same. A fix is made once and counts on both sides: nobody has to remember to carry it across, and nobody discovers weeks later that one of the two had quietly fallen behind.
App · Web · Shared base
Every change goes past somebody else before it lands. That catches mistakes, but mostly it keeps knowledge moving: after a few weeks there is no such thing as one person's corner of the codebase, and nobody takes a piece of the product with them when they go on holiday.
Conventions · Review
Version number, release contents, a build that comes out identical every time: whoever ships should not be holding twelve steps in their head. If a release goes wrong you go back to the previous one without a debate, the only kind of safety that counts once the app is in people's hands.
Versions · Builds
Listing, screenshots, description, notes for the reviewer: that is working material, not last-minute admin. Store publishing is something I handle myself on my own projects too, and it is the same craft I describe on the page about mobile apps for iOS and Android.
App Store · Google Play
Where we are
FanMsn has been live since 2024 and there are three doors into it: App Store, Google Play and the browser. That is the fact that matters most, because an app that stays published is an app that keeps clearing review with every new version, survives operating system updates, and carries on changing while people are using it.
The change I can describe honestly is not a product metric: that one is not mine and I am not going to claim it. It is the way of working. Architecture decisions are not made again on every screen, because they are written down and they hold for everyone. The same thing is not written twice in two places, because app and web share a base. And publishing stopped being the moment you find out what is missing.
Decisions written down/ Code anyone can read/ One base for app and web/ Repeatable releases
This project proves something my other case studies cannot: I can work inside a product that is not mine, the way I did for five years as a front‑end developer at LuisaViaRoma. The extra step here was answering for other people's work as well: a wrong technical call is wrong for the whole team, and the team then builds on top of it for months. The same road to the stores, walked alone instead, is in the Single Fin Pet Centric case study.
What this means for you
An extra pair of hands is not always what is missing. Sometimes what is missing is someone who decides how the code gets written, holds the line, and keeps the project pointing one way while the people around it change. I can come in like that, without writing every line myself: frontend leadership, architecture calls, shared standards and review.
Leadership · Architecture · Review
Apple and Google review is a trade of its own, and on a consumer app it is where projects stall. I handle it from the inside: developer accounts, listings, screenshots and the replies when a reviewer asks for clarification. Knowing in advance what will be looked at is the difference between a launch date and a launch date moved.
App Store · Google Play · Web