15 steps to make sure your project is scalable from the get-go
8 min read
Often we hear about the term scalable, we think about our architecture, we think about our code cleanliness, but we some time forget little things, that totally boost the project’s life-span, increase bug-fixing probabilities, decrease crash rates, and overall make the app healthy
I’m going to make this post about 3 things that any project should have, be it backend applications, be it front end, be it mobile applications, be it even games, so? let’s get started!
1. Backend for Frontend design pattern
You might be reading this as a backend and say, ok, what the heck does design have to do with me?
Design is VERY important to you, because, if the clients come to integrate with you, their main priority is to implement what is in the design, not what your API provides, the design coming from the designer is what drives the whole project, it enforces the backend to build for the front end (BFF Design pattern rings any bells?)
So, often do I see and feel that the backends are totally isolated from what’s going on with the front ends (mobile + web), like it’s your job to follow up with your teammates and make sure they are not lost, like how would I do X with API There should be proper documentation about what does an API do, don’t shove me all the data of your API on Swagger and call it done, you need to clarify what should I do in each flow, let’s say if we are building a chat that has an offers feature, you need to tell me, how does your API contribute to the flow of the feature, this way you help the whole team be more productive, and this way, you keep the team from interrupting you each time they need to inquire about something or how does the API contribute to the flow
2. Designers should make developer’s life easier, not just by UX, but by better there game in exporting assets
Countless times, do I see a designer, missing to mark the assets as exportable in Xd, or sketch, now Figma by default magically marks everything as exportable, he does that out of the box, but if you really wanna help your developers, you need to make sure that you use the Grouping feature, carefully and professionally, and make sure that your illustrations are not all over the screen, just group them into one element on the design (talking about illustration here) and export it, don’t just jot the whole illustration with tons of paths and when a developer comes in, he can’t inspect the element he is implementing because the paths are blocking the whole view!
3. Designers should always upload the app’s flow with every possible interaction
Another thing is, please upload the Prototyping! If you just upload static designs without the flow, you’re basically telling your developer, GUESS THE FLOW, you leave a lot of guesswork to the developer, especially if this is a new project, you will always let the developer come back to you and ask, where does this button lead to again? or what is supposed to happen if I delete the last person from my contact book? By adding that, you shut the door for all of these interruptions, and you make everyone’s day easier, and on top of that, they will thank you from the bottom of their hearts because you made their life easier
4. Designers with ambitious illustrations all over the screen should for god sake group those illustrations in one group, shove it into the back, call it background and MARK IT EXPORTABLE
Ok, I know I sound angry, but seriously, if you were a front end developer, you will see that a screen is filled with tons of strange stuff that doesn’t have a rule for the UI to follow, now coming from an iOS background, Autolayout (Constraint Layout in android) needs a pattern, a rule for it to follow so that you can build the UI and deliver it pixel-perfect on each and every screen Most designers don’t know how do developers build their UI, If they did, it would totally change the way they push the design on whatever platform they host the design on
So for example, check this nice looking screen
Notice the scribble between the title and the body? yes exactly, how the heck would that be put?
It has no rule, you can’t tell Autolayout to display that correctly for all screens, iPads even if you told the designer to group everything into a group and make it a background, this image might not scale well on different screens, the aspect ratio wouldn’t allow it, so we have two options, redesign, or remove that troublesome element
So as a designer, my advice, see any video about a developer who develops a screen’s UI from top to bottom on Android XML or iOS Interface Builder, it will really put you ahead of the pack
5. Always have a list of must-have libraries, packages, pods that goes into every project
Whenever I start an iOS project, Laravel project, Unity project, there are those packages that I always import into the project, without even writing any line of code
Not because I like to fill up my app with dependencies, or I want to add code debt from the get-go, but because these Utility pods will speed things up, ever heard about
SwifterSwift in iOS? it's a pod that contains TONS of extensions, for basically everything in iOS, macOS, watchOS, I almost write it every time, I go to my terminal, setup Cocoapods, and jot some pods down that I know I must use, not even Alamofire goes into that list unless I really need something specific from Alamofire that a simple abstraction around the network won't do
6. Always script your way into doing tasks
remember point 5? you can make a simple bash script that runs this whenever you want to make a new project, even better, export that script into your PATH file, now you can use it everywhere
always look for ways to automate stuff, even if it will take you 2 hours, you can always reuse those 2 hours to save countless 30 mins (Fastlane, anyone?)
CI/CD is basically what everyone should be doing, it makes sure your project compiles, it make sure your tests run, it makes sure that your TDD actually works!
Start simple, like running App Center, its dead simple, and cheap as well!
You won't have to manually test your code before each PR, and your teammates will also know that the tests run successfully when they are reviewing
No CI/CD budget? no time to set up a CI/CD, no CI/CD at all? no problem Fastlane is there for you
Fastlane is automation on Steroids!
you can do all sort of stuff with Fastlane, you can run your tests, send tests results to SonarQube and make it analyze the code for any smells or anything, build, add provisioning profile, archive, send to the app store, generate screenshots with correct dimensions, send debug symbols to Crashlytics and Sentry ALL IN ONE COMMAND
in fact, some CI/CD providers use it, the only difference here is it will be running on your local machine and using your internet
9. Use Code Review Bots to help you do code reviews faster
Code reviews plugins are on Github, I used them before, they sped up the process, made some minimum of how the PR should look like, and they made us a little more productive, so why not try them?
10. Use tools like SonarQube and Linters
SonarQube is a great tool to catch smells fast and early on, it will help you deal with just that, it does a great job in telling you where your code is weak or not well written or maybe not designed well, it works as a second eye in the codebase and tells you what you should be careful about
Another great tool are linters, linters are things which enforce teams to write code in a style that all the team agrees on, through a bunch of rules set up in a YAML file, be sure to check it out, you will love it
11. Using POEditor for Localization
POEditor is a great way to achieve easy localization in any project, it allows you to sync localization between iOS, Android, and Web applications, it's free, easy and automates the translation in a good way
12. Setup Loggers early on
Setting up loggers is really important in identifying bugs and unexpected behaviors, it will help you on the long run if you set them up early and help you catch if there is something off either early in development, in testing, or on production, it's better than shooting in the dark when customers are reporting issues
13. Setting up Bug-reporting early on
Bug-reporting SaaSs will definitely help you track down bugs and squish them faster, you should use those in mobile apps as well as backend apps to ease up the search for the solution, they also provide useful information like videos of how did the bug started, screenshots of the user's bug, the user can draw on the screenshot marking how the bug occurred, and so on
14. Never underestimate Analytics setup
Setting up Analytics is probably one of the most important tips on this list, even if you are doing a freelance job and the client didn't ask you to set it up for him, you indeed should, even if it's for you, knowing more about how do users use your app, some numbers about their interactions and a bunch of that stuff, will definitely give you visibility, and you should always suggest that to your clients
some of the analytics tools I love are:
15. Setting up Smartlook
Smartlook is a brilliant debugging tool that allows you to see how did the user interact with your app by recording their session, it works for mobile apps as well as web applications, it can save you a lifetime of guessing why do users exit in the checkout flow when the main reason it could be something like, the checkout button is not clickable for some reason