What you should know before creating an app

This is a rather lightweight article that serves as a reminder for developers and project managers who are looking to create an app. It’s also a prelude to heavier subjects like tech debt. What seem to be inconvenient to do at first - no matter the size - will eventually grow to become an unintended problem. So, it's best to know what to expect from the get-go, plan ahead, and nip it in the bud before it becomes too big to solve.

Get your budget approvals upfront

In any large organisation where Finance is a dedicated business function, you will need to get budget approvals for any service you would like to purchase.

It's best to be familiar with the policies and procedures in your organisation when it comes to budget approval e.g. signatories, their budget authorisation levels, how long before a business case can be approved, and for Finance to process the request and finally issue the purchase order.

The last thing you want is to have everything completely set up on your machine, but access to your cloud environment is not ready because the paperwork is stuck somewhere.

Don’t create any account using a personal email address

In any project, it's never a good idea to use a personal email address to create an account with services such as AWS or Google Cloud. Account ownership would be an issue to contend with after the individual leaves the company.

Instead, create a separate email address and name it 'admin@yourcompany.com' or 'system.admin@yourcompany.com'. Assign this email as the ‘account owner’ moving forward.

Use only this email to create accounts with service providers e.g. iOS and Android developer accounts, email, SMS or hosting providers at the beginning of a project (not right before deployment) as they take time to get activated and running.

Once you have activated your accounts, you may add yourself and provide the team individual access as administrator or other user roles based on your requirements, but never as the owner of the account. You might be surprised just how helpful this is when you start expanding your team.

Don’t overcommit if you're not sure

I definitely encourage developers to explore and learn on the job. However, when you are time-bound by a project, it all boils down to how much time you have before you need to deliver something.

If you have only a couple of weeks to create a feature from scratch, then, it's probably best to be conservative about using a completely new framework or one that you can only comfortably use with the luxury of time. On the other hand, if you are given sufficient time, make the best use of it.

Many developers jump at a chance of trying out new tools, spending days and weeks figuring out how they work, at the expense of actual build time. In most cases, timelines get derailed due to incidents that are unaccounted for yet avoidable in the first place.

While it's easy to be enticed by the latest tools and tech, the more sensible approach would be to utilise the time to set some standards in the tools used, carefully list technical requirements, and convert them into code that you can manage.

Set up dynamic environment variables from the get-go

This is a mistake that many developers make. Instead of setting up environment variables from the get-go, they end up hard coding variables like database passwords or other ‘secrets’ that they do not intend to commit to GitHub (imagine how it must look when people see hints of your own password on GitHub).

Though hard coding these variables may seem like the easiest approach at first to test your build on the fly and on the framework of your choosing, it's one to backfire during deployment. Often, developers find themselves scouring thousands of lines of code, searching for where they might have hardcoded their password or username.

Hence, always set up your variables beforehand because you'll thank yourself later. If you find yourself having to repeat certain steps, automate that part of your development process.

Automate your development process ASAP

If you do not automate your deployment early on, you risk running into a whole lot of problems that you have to deal with after the app is launched. It is realistic to expect feature enhancements and bug fixes post-launch, and the system should be ready to deploy them as quickly as possible without holding up too much of your developers' time. The closest example is automating your environment variables (which you should have already set up by now) during CI/CD.

Spend if you need to - as early as after the planning stage - on all necessary hardware and tools you know you will need at some point in the project. Don’t wait to start renting your servers, and spend that extra $10 if you have to.

In fact, the earlier you start automating your deployment, the sooner you can get more things done. You don’t necessarily have to wait for your system to be perfect to start automating it. You can start automating your deployment as soon as you create a ‘hello world’ boilerplate.

Final thoughts

Throughout my career as a software engineer, I've witnessed too many delayed launches and service interruptions that cost businesses millions of dollars due to tech debt. When scenarios like this happen, it's rarely easy to identify the single point of failure in a pile of code. Engineers would then rely on what is at best guesswork to solve the issue - temporarily.

This article is the first of many to come because it is at this point where you can start to influence the course of your project. It is here where you can begin to avoid potential problems in the first place. As a rule of thumb, the sooner you automate your development processes, the sooner you can deliver features and start testing.