Guide On How To Reduce Your App Costs With The Right Frontend

Photo of Mateusz Lisowski

Mateusz Lisowski

Mar 1, 2019 • 10 min read

The cost of your application is probably one of the crucial things you’re considering during the planning stage. Sometimes small tweaks can decrease the overall cost of the application if you make the right decision.

There is always space for improvements and it’s always a good time to make a change for the better. I'll try to give you some details about which things you should have in mind whenever you build your frontend, what should be avoided, and what you can do to make the development process cheaper.

What makes up the cost of an application?

To understand problem we need to analyze the reasons. It's no surprise that the cost of your frontend is just development time multiplied by the hourly rate. The article could end here, but this is not the reason why some projects are expensive and others are cheap. So I’ll try to walk you through the factors which depend on the time spent by developers on building app.

  • Amount and complexity of functionalities - Less effort is required for a simple app containing authentication and a few other common features than for a complex finance app integrated with several external APIs. Combining both can require a lot of work.
  • Amount of business logic inside - Before creating an application, developers mostly have little or no knowledge about the industry in which their app will operate. They must understand the business context, the requirements for functionalities, the desires of the client, and transform everything into code. It's a hard process and it involves a lot of consultations about details.
  • Architecture - I don’t want to deeply analyze which architecture is better because there is no good and universal answer. We must keep in mind that multiple developers will work on the project and chosen architecture should be clear for everyone. In a longer perspective taking care of this is rewarding. With a good architecture, finding data in the app is easier and it doesn’t require the devs to explore it for every single feature.
  • Documentation - Information about the project, such as tips how to set it up locally, the patterns used, solutions, and many other things. Sometimes it’s marginalized, especially when there is pressure to develop the product fast. In a wider perspective, neglecting documentation will probably cause chaos and will be more time consuming. Every time developer encounters some problem with the project, he's being distracted from the actual work.
  • Complexity of the code - How much logic is inside one module/component and how (if at all) it is split into smaller chunks of code. It also could mean how much effort a developer needs to put in to add/refactor a functionality. Overcomplexity can cause extreme situations when a relatively easy task is hard to complete. It’s a rare situation when the same developers are in the project from beginning till the end. Whenever a new person joins, he could be frightened by the complexity and his productivity would be very poor for a long time. It can also force you to hire or assign more experienced developers.
  • Used technologies - Depending on what you choose, it can speed up or slow down your development. You need to keep in mind two areas in particular: what technologies would be the most suitable for your project and what your developers already know. Combining both would be the best, but sometimes developers need to learn new technologies which cause problems they didn’t faced before.
  • How long a project takes - The predicted duration enforces a change bin approach with regards to the process of developing an application. Long term projects need to be well configured, managed, and documented to be inclusive for developers who will work on this project. If not, big problems may arise.
  • Developers - The most important point. Some people think that an experienced developer could be replaced by a few less experienced programmers who will work for a lower salary. But in practice this almost always causes problems and needs to be refactored by another team. Did you know that developers spend most of their time on code refactoring?

The factors mentioned above can decrease/increase the time your frontend developers spend on tasks. Being aware of them and taking care of them in the correct way can ensure you will be satisfied with your savings. But there is most important question. What you can do as a frontend developer to reduce app cost?

Take care of your architecture

Don't be afraid to hire tech lead who will choose the best technologies and tools for your project. The wrong tool can cost you a lot of extra work or even require a migration to another technology which can meet your requirements.

Build an intuitive project structure

It should be granular, consistent, correctly split into folders, and easy to extend. Whenever we build a project, we need to think of how it will look for not only in weeks, but in years.

Project Structure 1

In the above example, the project structure (Vue, Typescript, Vuex, Vue-router) has four main subfolders in the src directory:

  • components - contains UI elements in separate folders

  • static - contains data which doesn’t change (for example list of panes to display and iterate over)

  • store - contains Vuex logic and is split into folders of modules

  • views - contains Vue-router pages

Other configuration files are not included in these folders. This kind of structure is easy to understand and extend.

Update the README file

If you haven’t described project practices in this file, change this! Every project needs to have a source of truth which could tell other frontend developers about best practices, project configuration, structure, and other stuff to avoid misunderstandings in the team. What should be included here? Everything people ask about. Assume that people may not know about many things and that everything should be described in depth. has examples of good README files.

Document business requirements

It’s not a common approach, but I saw plenty of times when a few guys knew everything and others not much. It's not healthy - knowledge must circulate around the team.

Maximize the quality of your code

There are plenty of tools which could help you to achieve this goal: IDEs (prettiers, code formatters), server CI tools (Travis, Jenkins, code climate), linters (eslint, tslint), precommit/prepush tools which analyze your code and block everything that doesn’t follow project code conventions.

Take care of frontend productivity

Use shortcuts, extensions (IDE and browser), set a daily focus time for developers when they won’t be distracted, automate repetitive processes, minimize distractions, don’t forget about your health - take a short break every hour to freshen your mind and sleep well.

Make code reusable

Be lazy in positive way. Do you see something in your code that could be reused? Don’t hesitate to do it! It saves lots of time.

Think long term

A frenzied pursuit of deadlines can cause the quality of the code to go down. So take care of the quality of your code, do code reviews carefully. Bad quality code is harder to change or debug.

Test your code

It doesn’t mean that more is better. We could test almost everything, but it wouldn’t be the correct approach (except if it's a medical application which mustn't fail). Especially when the requirements are dynamic. Correct testing means that every crucial part of data is covered by tests and is stable. Also, a part of bug fixing should be writing proper test to avoid future problems. Testing also gives you better insight into code and the application.

Follow best practices

There are a plenty rules which could be an article. In short it’s: self-explanatory code, DRY, module patterns, avoid unnecessary comments, clean code from console.logs and unused code/folder/files/resources, use correct code indentation, make the code as good as possible and don’t wait for a refactor (it’s harder to debug and it’s a way to get spaghetti code), use developer tools, ES6/ES7, frameworks, CSS preprocessors and code conventions, organize code in dedicated folders. There are many more techniques to make code leaner and more friendly, which I encourage you to learn.

Use Storybook

An external library which can allow you to store your UI components separately. It helps maintain bigger projects and stay DRY. Whenever I joined projects, I spent too much time finding components which I could use to save my time. This is exactly when Storybook comes to the rescue!

Use Typescript

Typescript is a superset of Javascript which introduces static typing. It has plenty of advantages. Mostly I appreciate the amazing IDE support which gently catches all of your mistakes and forces you to write better code and also is awesome during refactoring. Types inside code is documentation which can speed up your work and save you from logging and debugging. I would also like to point out that Typescript can be introduced into the project gradually, which is a big advantage.

Avoid HDD (Hype Driven Development)

This is a phenomenon where developers choose technologies based on current trends. It especially refers to the frontend world where we have plenty of new technologies and new stuff. Technical decisions have a crucial impact on creating and maintaining a project. Therefore, try to avoid implementing unproven solutions that may hinder your work. Here you can find an amazing article about HDD.

Hype Driven Development



We’ve covered what makes up the cost of an application and what you can do as a Frontend Developer to reduce the cost of your app. Every point refers to an action which can save your time, make your job easier, makes you more satisfied, and protects your project from being inaccessible to new team members. A happy developer who can easily find any data in his project is a productive developer. Remember that it is always a good time to introduce quality changes. I wish you luck with that goal!

Photo by Immo Wegmann on Unsplash

Photo of Mateusz Lisowski

More posts by this author

Mateusz Lisowski

Mateusz is a self-taught developer and an alumnus of Social Work at the University in Białystok. He...
How to build products fast?  We've just answered the question in our Digital Acceleration Editorial  Sign up to get access

We're Netguru!

At Netguru we specialize in designing, building, shipping and scaling beautiful, usable products with blazing-fast efficiency
Let's talk business!

Trusted by:

  • Vector-5
  • Babbel logo
  • Merc logo
  • Ikea logo
  • Volkswagen logo
  • UBS_Home