Building a Laravel web app, mobile app, or both can be daunting. Architecture, strategy, planning, resources, testing, and delivery should be a part of the project. One problem we have noticed is that often all the thinking when developing an application goes into the application itself. There needs to be more planning for long-term costs and resourcing. Some areas that would be good to consider are. Platform fees, Hosting/cloud fees, Subscription API fees. Patching costs, and Maintenance and expansion.

Budgeting Laravel development costsThese areas, and more, can contribute to the long-term costs of owning this application. Even though it may be a low priority when planning the project, stakeholders, product owners, or relevant staff should spend time on this topic.

Let's break down how some of these costs can add up.

Starting with platform fees is simple. One recent project we built includes the following:

  • AWS hosting

  • Mailgun

  • Stripe

  • Plaid

  • Coinbase

  • Google Drive

  • And more

While each of these is likely not a huge cost, it can add up. Also, some of these services can get expensive depending on the user count, server load, or general site traffic.

One example of where costs can increase significantly is in AWS hosting fees. AWS is affordable at the outset, but traffic or application usage increases can push those costs up quickly.

The next area of costs to consider is maintenance and patching.

We generally consider maintenance to be random bugs or small feature changes. As user counts grow or users become increasingly diverse, you may find outlier issues that were unaddressed during the initial development of your web or mobile application.

One example of this challenge is: let's say all of your users are in the US. You are happily rolling along, and your application is doing great. But then someone signs up from Europe. How are you going to transact with the Euro? Do you have enough privacy built-in for GDPR laws? These are simple examples of how unplanned changes in the user base can contribute to a change that needs to happen. Depending on your Laravel application's build, you may need a simple fix to handle payment processing internationally. We would consider it a new feature if it is a significant development effort.

Patching is usually related to the libraries your application uses. Maybe a vulnerability was found in one of them. There may be a new version of PHP, or iOS/Android put out a new version. Sometimes these new versions can create breaking changes, and other times it is a simple update that works just fine with your codebase.

Patching is usually straightforward, but it is something to consider because you want to avoid a vulnerability or something breaking. One of the most important things to consider is "who is keeping an eye out?" if a library releases an update. What if an iOS update is released? Who reads the update notes to ensure there is no impact on your mobile application, or if there is an impact, what is the process to identify it and resolve it promptly?

What about new features and expanding?

So we built your Laravel and mobile apps, and it's been six months. Now all of your users are asking for this one specific feature. Or your product owner or a stakeholder has something they want to add.

New features are part of any long-term software application plan. The requests come in from all sides, and it is essential to consider a few things:

  • Will this feature make more money because more users will come?

  • Could we upcharge for this feature?

  • What is the cost of implementing this feature?

  • Will this feature require any additional staffing or support?

The knowledge that features will be needed down the road can help keep your budget in a good place.

Does your application require staff?

Some applications offer live chat, while others require someone to respond to support emails, approve users, or handle a process. The time cost for people to deal with software application support is something to be considered when budgeting for the project.

These costs can even creep up when you don't expect them. One example is a client we had that ran a web application connected to a mobile app. One of the company employees had to do a small weekly task that took a couple of hours. Upon review, we found that resolving the issue would only take a simple code change.

Staff costs for web applications are often minimal if the platform is well-written. But keeping an eye on things never hurts.

In closing

Building Laravel web applications and mobile apps that rely on the web can be a great process. But, awareness of long-term costs and budgeting considerations can help save the bottom line later.

Lets Talk