Budget overruns can and do happen on digital product development projects. We have a few tips to share if you’re wondering how to plan a web development project that won’t leave you broke due to unexpected fees and hidden costs.

Have you ever been shocked by a phone or energy bill that was higher than expected? Hidden costs and unexpected fees are frustrating, especially if you’re a business owner.

When you engage in a web development project, you are more likely than not to encounter problems or delays that are sometimes hard to pinpoint. It’s also not uncommon for these projects to go over budget. Sometimes the reason is out of your hands, but other times, this can easily be prevented by acting at the right time and making smart decisions. 

During my more than 15 years of experience working with WordPress, I was met with a wide range of projects – some good, some bad, and some downright ugly. In this article, I’ll pinpoint the usual suspects that often raise the overall costs of a web development project and share my advice on avoiding them. Let’s delve into how to plan a web development project so that you avoid headaches, unwelcome surprises, and unexpected costs.

Let’s illustrate this with an imaginary project. Say your company produces high-quality speakers you have spent years developing and perfecting. You want a website to showcase your product and attract potential customers and investors. 

Considering your business goals, a simple website that provides basic information about the product, like countless others, may not be enough. You desire something custom that distinguishes your product from the competition and catches people’s attention. After some research, you are set on the idea that your website should offer e-commerce functionality and provide an in-depth comparison of your speakers with your competitors.

This type of project requires more advanced web development and potentially includes some hurdles along the way.

Putting your ideas down onto paper, and turning your website ideas into a reality, can seem like a daunting task. Here’s a short list of things to remember when building your brand, product, or service website. Of course, this list isn’t exhaustive, but these are some of the most important things to consider for any web development project.

Sometimes, you may come across agencies that offer cheaper services or know individuals who claim to “make websites”. While it may seem like an attractive option, I assure you that this type of engagement will cost you more in the long run. 

This approach may be suitable if starting on a limited budget. However, implementing any changes becomes time-consuming as your company grows and evolves. Solo developers or small agencies may not have the necessary resources to support your growing company. They also might work with a “let’s make this fast and fix it later” mindset, which can lead to website crashes, code problems, legacy issues, and more.

To make sure you choose your future development partner wisely, we’ve prepared a list of questions to help you select.

One of the key factors that can determine the success or failure of your project is the technology stack used to build your website. Sometimes, companies opt for trendy or cutting-edge technologies without fully understanding their implications. While it may seem exciting to use the latest tools, it can lead to compatibility issues, limited developer expertise, and increased development time and costs.

It’s essential to thoroughly research the technology options available and choose ones that align with your business requirements and long-term goals. Ensure that you and your development team clearly understand the technology choices and their potential limitations. Consider factors such as scalability, security, ease of maintenance, and community support. This is also an excellent time to research the YAGNI (You Aren’t Gonna Need It) principle. Trust me, you will thank me later.

A common pitfall in your role as a client is not providing a comprehensive and detailed project brief to the development/design team. Without a clear roadmap and understanding of your expectations, the chances of miscommunication and divergent results increase significantly.

A good project brief should include:

However, if you’re worried you won’t be able to come up with all the details yourself, any good agency will know how to help you figure these things out early on. At Infinum, we prefer to kick off projects with product discovery workshops, in which we build the plan and project outline together. 

Good agencies will always be there to support you. After all, it’s part of the service you’re paying for. Of course, it’s important to remember that you must bring expertise to the table about your brand or product so that the product strategy we map out matches your business goals and ultimately brings you value.

While you may have a clear vision for your website, it’s crucial to listen to the advice and recommendations of the agency you’ve hired. As experts in their field, they can provide valuable insights and suggestions that can enhance your project’s success.

Engage in open and transparent communication with your development team. Be receptive to their feedback and ideas, and work collaboratively to find the best solutions for your project. Sometimes, clients can be rigid in their demands, but balancing your vision and the agency’s expertise is essential.

For example, a feature will be finished in approximately 30 days. If your agency proposes a minor alteration to the design and functionality that could reduce the time to 10 days, it is advisable to consider that option. You have chosen the agency based on their references and expertise, and you can trust that they wouldn’t suggest a change unless it is the best course of action. Remember, the development team wants your project to succeed just as much as you do, so fostering a cooperative working relationship will lead to better results.

When embarking on a significant project like building a new website, it’s wise not to invest all your resources at once. Instead, together with the project team, devise a plan for an iterative approach and break your project into manageable phases. This allows you to assess the progress, receive feedback, and make adjustments before moving on to the next phase.

This approach also enables you to validate the project’s direction and make necessary course corrections early in the process. It also minimizes the risk of pouring substantial resources into a project that might not yield the desired results.

Typically, it’s not the primary features that deplete your project funds – since you probably planned them beforehand – but the concealed details you or your agency overlooked during the initial estimate. Selecting your agency carefully will likely eliminate the need to be concerned about this, but conducting your research beforehand is always a good idea.

At Infinum, we understand the significance of well-executed projects and their impact on your company’s financial health. Here’s how we ensure project success:

Creating a great product takes time. By conducting thorough research and choosing your agency wisely, you can avoid the pitfalls of low-cost, inexperienced options. If you are serious about your business, avoid rushing to the finish line.

We’ve identified some of the most common issues on web development projects and what you can do to anticipate and prevent them. Thorough research, prioritizing clear project briefs, open communication, and incremental development ensure better alignment with your team, reduce misunderstandings, allow for timely adjustments, and in the end, save you money. 

No one likes hidden fees and unexpected costs. If you want to ensure you don’t break the bank with your next web development project but rather invest wisely – drop us a line, and let’s talk.

Ever since the REST API was included in the core of WordPress, there’s been a lot of talk about using it for decoupled WordPress (sometimes known as headless WordPress). In this article, we’ll delve a little deeper into this topic, explaining what decoupled WordPress actually is and how it should be used with (or without) WordPress REST API. We’ll also reveal some interesting surprises we’ve encountered while trying to implement it.

In its original form, WordPress is a full-fledged content management system (CMS). It comes equipped with a working admin interface for content entering and editing the frontend that displays it. It also includes a backend system written in PHP with various APIs that handle database interaction, user authentication, routing, and more.

On the other hand, decoupled WordPress uses WordPress as a sort of a model and controller bundled together that handles data manipulation, and database interaction, while REST API Controller provides a way to interact with the view layer using various API endpoints. In addition to MVC separation, we can (for security reasons or speed improvements) place the JS App on a separate server like in the schema below:

REST API was bundled into the WordPress core since version 4.4. However, endpoints for posts, comments, terms, users, meta, and settings appeared later in version 4.7.

What WordPress REST API allows you to do is to interact with your WordPress installation remotely by sending and receiving JSON objects.

The ideal use case for this is a simple single-page application. Another advantage of REST API is that you can use any popular view framework or library to display your frontend. For example, React, Vue, Angular are just a few options in a sea of popular view libraries and frameworks.

Thanks to this feature, you can have the backend part on one server, which can be optimized for server-side tasks (faster disk, optimized database interactions, etc.). Then, your front is served from another server, giving you a good separation of concerns.

We wanted to determine how to use WordPress REST API for building a simple website with React on the frontend. We were testing whether we’d get better performance when decoupling the front from the backend. In our case, we didn’t really need all the REST API functionality, such as editing, creating and deleting posts or uploading media files. We wanted to retain the CMS ability so our colleagues in marketing, who usually add and edit content, wouldn’t have to ping developers to update the site.

We first encountered the strange WordPress lagging REST API on a client site, where we used the custom endpoints to get the list of locations on a Google map, alongside other meta information created using the Advanced Custom Fields Pro plugin. It turned out that the time to first byte (TTFB), which is used as an indication of the responsiveness of a web server or other network resource, was more than 3 seconds.

After investigating, we realized the default REST API calls were actually really slow, especially when we “burdened” the site with additional plugins.

As an initial test case, we created a default WordPress installation with version 4.9.4, using Varying Vagrant Vagrants running on PHP 7.0.27 and MySQL 15.1 (Distrib 10.1.31-MariaDB). Using Twenty Seventeen theme, without any pages and only sample posts, the postman app gave a loading time of 47 ms for a response size of 2.16 KB. This isn’t bad—but in the real world, you won’t have only one post on your site. So we added some more default posts, importing them from the wordpress.org Theme Review Teams repository.

In this case, the load times increased to 161 ms, and the response size was 41.63 KB. The timings in Chrome were a bit slower with 261 ms, and the TTFB was 173.76 ms. That was for just ten posts.

We were curious to see how adding additional plugins would influence the response times. The plugins we used, in no order of relevance, were:

We encountered some interesting results. The postman app now gave the load time of 1970 ms for 41.9 KB of response size. Chrome’s load time was 1.25 s (TTFB was 1.25 s, content was downloaded in 3.96 ms). Just to retrieve a simple list of posts. No taxonomy, no user data, no additional meta fields.

Why were response times so long? For one, accessing REST API on the default WordPress will load the entire WordPress to serve the endpoints, even though it’s not used—and the more plugins you add, the worse things get. The default REST controller WP_REST_Controller is a really big class that does a lot more than necessary when building a simple web page. It handles routes registering, permission checks, creating and deleting items, etc.

One workaround could be to create a custom REST controller, which will only serve the content and handle permissions and authorization. Unfortunately, we haven’t tested if this would have any impact on the performance.

Another workaround we implemented was to load only the bare minimum of WordPress and store our data in a transient, from which we’ll fetch using a custom page.

Transient API is used to store certain data in the options table in your database for a specific period of time. You can set an expiration time for a transient. After this date, the transient will be deleted from the database, or you can store it permanently and use post save or update hooks to manually delete and recreate it. It is a powerful tool WordPress uses to cache things, such as plugin versions, theme versions, and other data. Here is one of the major advantages of transients: When using a caching plugin, transients will be stored in memory, and when requested, data will be pulled from it instead of querying a database to fetch it—which is even faster. In addition to being really fast, it can hold up to 4GB of data in it; and 4GB JSON string is really, really a lot.

To load the bare minimum necessary for WordPress to work, you need to add just one line—either in your wp-config.php file or, better yet, in a custom file you’ll use in your plugin or in your theme:

A quick look in the wp-settings.php reveals that if this constant is set to true, most of the WordPress won’t be loaded. Any additional WordPress functionality would have to be added manually, but it pays off.

What we created was a file called wp-config-simple.php that looks like this:

This in turn only calls the initial wp-load.php file necessary for pages and posts. Then we can include other files needed for other WordPress functionalities.

The complete solution to this is a plugin called Decoupled JSON content.

This plugin will cache the pages and posts in a transient, and its JSON content can then be fetched by accessing a file that will serve this JSON. For instance, the pagehttp://local.wordpress.test/wp-content/plugins/decoupled-json-content/page/rest-routes/page.php?slug=blog&type=page will give you the following JSON:

Aside from default post/pages routes, there are also custom menus routes and several hooks, which can be used to extend the functionality of the plugin: Add custom post types, override various post formats, change custom fields and more.

The way to use this in an app would be to fetch the data using the above URL, changing the slug and the type based on what you need to fetch, and store it in your application state (using Redux, or better yet MobX in case of React). Whenever data is needed, it can be pulled from the store. However, it’s important to take extra care to ensure new data is being fetched when the content changes on the WordPress side. This concerns the JS App, which we will cover in another article.

When we accessed the JSON data using the above method, we noticed a drastic decrease in load times. We conducted testing in Chrome, where we could see the total response time and the TTFB separately. We tested response times ten times in a row, first without plugins and then with the plugins added. Also, we tested the response for a list of posts and for a single post.

The results of the test are illustrated in the tables below:

As you can see, there is a drastic difference.

There are some limitations that should be taken into account. For now, you can only retrieve data. Storing and creating isn’t handled by the decoupled content plugin. Also, since the plugin directly calls wp-load.php, it won’t work on non-standard installations of WordPress such as bedrock.

Is WordPress REST ready? Yes and no.

REST API is great because it can be used to create fully-fledged apps—creating, retrieving, updating and deleting the data. The downside is its speed. You’ll either have to create a custom controller, which is something we need to test or sacrifice the speed of your app.

Obviously, creating an app is different than creating a classic website. You probably won’t need all the plugins we installed. But if you just need the data for presentational purposes, caching data and serving it in a custom file seems like the perfect solution at the moment.

You may be wondering, “What’s the point? Couldn’t we just create a regular WordPress theme using good old PHP?” Sure we can. Not only that, but we have an excellent boilerplate that uses object-oriented programming principle, namespacing and autoloading, along with some caching tricks to make a site as performant as possible. But with Gutenberg around the corner, front-end frameworks are getting really popular with the WordPress community, so this is something to keep in mind.

We hope you found this article helpful and interesting. Feel free to comment and share your thoughts.

For more details on the test data check this link.