Thousands of tech articles get published every day. Hundreds of “Top-10 best-things-you-need-to-know” lists flood your feed. And to be honest – we kind of love that format. While not every list is gold, many are packed with real experience and hard-earned lessons.
Today’s article is one of those. It is packed with practical advice our team gathered through the two decades down the software and mobile development road. Across industries, continents, and various project sizes.
And here’s one thing we’ve learned along the way: mobile development doesn’t fail because of one big decision, it suffers by avoidable cuts. At Lerpal, we’ve seen plenty of what can go wrong (and what really helps). So we asked our mobile team: what advice would you give if you could whisper into a client’s ear before kickoff? Here’s what they told us and what we are sharing with you today – some useful things we wish everyone knew before building an app.
Start with architecture (or you’ll end up rewriting the thing)
You’d be surprised how many projects kick off with features, UI, and “quick wins” and leave architecture for “later”. That “later” either never comes or shows up as a need for a complete rewrite.
Good architecture isn’t about overengineering. It’s about giving your app room to grow without collapsing under its own weight. A solid foundation means it is easier to scale, fix bugs, add features, support more devices, and adapt when your product vision evolves (which it will).
“An architectural approach will make it easy to maintain and scale the project in the future, so you don’t have to constantly rewrite everything and spend a lot of money on it”.
Dreams and duct tape won’t hold your app together. A solid architecture will.
Don’t skip analytics. Seriously. Don’t
It’s fun to launch an app. It’s less fun to have no idea what users are doing inside it. Are they dropping off mid-flow? Are they even opening the feature you spent 3 weeks building? Without analytics, you’re guessing, and it should be built in from the start. Not just for product metrics, but for crash logs, usage flows, even feature-level success. Otherwise, you’re flying blind. If you’re not measuring what matters, you won’t know what to improve. Or when.
CI/CD is not “for later“
You don’t need to be building a unicorn startup to set up a CI/CD pipeline (which means continuous integration and delivery). Even small apps benefit from automated testing, consistent builds, and faster release cycles. CI/CD makes your life easier. It means stable builds, faster releases, fewer human errors, and your QA team crying less. We run it even for small projects, because time spent setting it up saves time every single week after. It pays off. Every time.
“CI/CD is not «excessive», it is a necessity. It is not simply automation for the sake of automation”.
Don’t treat the release as the finish line
People often forget: post-release is where the real work begins. You ship version 1 and that’s just the starting line. Now come updates, analytics, SDK changes, UX tweaks, user feedback, and the occasional App Store drama. Features need refining. Bugs need fixing. Trends shift. What worked at launch may not work three months later. Plan for that. Budget for that.
“After release, the project doesn’t end – it only begins to live“.
Fancy doesn’t mean easy
A sentence like “Should be simple enough” in software dev is the equivalent of saying “Quiet day, huh?” in a hospital. That’s usually when the chaos starts.
Animations, offline sync, Bluetooth connectivity, proper push notification behavior across time zones and languages – none of it is that “simple”.
External integrations? Even trickier. Attribution analytics is critical if you’re buying traffic, but setting it up and making sure it works takes real effort. Subscription tracking becomes chaos if you are segmenting by calendar weeks instead of user cohorts. Push notifications? Simple until you deal with localization. Sleek design? Great, until you realize Arabic reverses everything you thoughtfully designed.
What we do differently – and why it works
We don’t claim to reinvent mobile development. But there are a few things we always do, no matter the project size. Because they work.
Code reviews with checklists. Not vibes, not “looks good to me”, but structured, consistent code reviews that save us from future pain.
CI/CD for every project. Even small ones. Especially small ones. Automation is not a luxury, it’s your best friend.
UX first, not last. We think about the user experience before we start building.
We build for real life, not the demo. Patchy signal, offline modes, network hiccups, background interruptions – we assume all of that will happen. So our architecture reflects it. Every project starts with our internal framework that helps set up the project fast and build stable.
Alert systems that actually alert. If the app starts crashing, the team doesn’t find out from Twitter. We have backend-style monitoring for mobile – especially critical during release.
And one more thing:
“We don’t write tests just for the sake of it. We write them because they identify bugs and maintain the integrity of the product. A high coverage percentage looks good on a dashboard, but it is reliable tests that do the actual work”.
So, that’s our current top five. We could go on (and probably will – our content manager is already thinking about part 2). But if there’s one common theme in a successful project, it’s this:
Things go better when all sides treat each other like partners.
Share your vision with us. Share your concerns. And when it comes to collaboration, trust us to ask the awkward questions early on. We’d rather challenge assumptions together before building a single screen than have to have a tough discussion about refactoring after the launch.
