How to do great work on a reduced budget

Right. Let’s discuss the elephant in the room here. Yup, we’re talking budgets.

Looking back at our projects over the past year, there’s a familiar, disheartening refrain that echoes through many of them : “The budgets are tight on this one…”.

Now unless you’re living under a rock, you’ll know that the economic turmoil both overseas and at home has really put things into a spin lately. Everybody is feeling it, across industries. For many of our clients it means they’ve got less to spend, and the budgets they do have need to be stretched further than ever before.

There’s still reason to be hopeful, however. Experience is life’s great teacher, and through the years we’ve developed strategies to help us continue delivering great outcomes, even on those stretched budgets.

In this article we’ll discuss some of what has worked for us, and hopefully they might work on your own projects.

Prioritise what really matters.

When aspirations exceed the budget, it is to rethink the scope of what we’re delivering. We never want to go straight in cutting costs that will impact quality. Instead, we ask if there’s something to be done about quantity.

Quite often when a client initially supplies a brief, it comes in the form of a long list of bullet-point requirements. Now, I know first hand how easy it is to get carried away when writing a requirements spec. It can be especially easy to overdo it on excess features when ‘helped’ by an overzealous AI agent. What ought to be a simple product spec can become a wish list of endless‘nice-to-have features. Ones that blow the budget out of the water.

There’s absolutely no harm in capturing neat ideas and enhancements. It’s an important part of building the long-term roadmap for a product. The problem comes when the requirements for an initial delivery aren’t prioritised effectively. It’s important we have the full reasoning behind why a requirement ended up in the spec, so we can judge the priority.

• Is it fundamental? Is this requirement integral to the primary user journey, or is it doing something extra?
• What’s the background? Was this the product of research, or just a cool idea someone had?
• What’s the return on investment? Is it linked to a direct business need, or are we simply copying a competitor or rebuilding from a previous version to maintain parity?

There’s a requirements prioritisation exercise we like to do at the start of any project. It involves stakeholders individually ranking the importance of the product’s various requirements, and giving a justification to each ranking. It’s essentially an elaborate game of higher-or-lower. We sometimes even get a combination of internal decision makers and user testers to do this activity.

What we often find is that, when looking at the results aggregate, many requirements originally considered ‘must haves’ in the brief aren’t actually valued that highly, and tumble down to the bottom of the list. That’s because the perceived importance of a requirement can be influenced by how exciting it sounded when raised in a boardroom, or by how vocally one person requested it.

Start taking a disciplined approach to requirements prioritisation, allowing priorities to be formed based on direct business benefit and actual consumer demand. Once you’ve done this, rescoping to remove out-of-budget features becomes a much easier conversation. It supplies the evidence to push back on features that could easily be left for a post-launch release.

Do less, but do it better.

Every requirement we add to a product carries a hidden price tag that extends beyond the initial design and development. If we add unnecessary scope now, it also means taking on higher operational costs later on, and after launch too.

• Technical debt. Every feature we add means more QA and testing work, with further opportunities for bugs and edge cases.
• Complexity. These extras bloat the codebase and the design system, making future updates tricker.
• Content dependencies. Most additions need to be supported with content, increasing the demands on content creators and curators.

Reducing scope isn’t all about making sacrifices. Streamlining the product ultimately leads to a cleaner, more intuitive interface that also performs better from a performance and load times point of view. When users aren’t forced to navigate loads of clutter or complex feature interplay, the cognitive load drops dramatically. We all breathe a collective sigh of relief…

With sufficient headspace we can really focus on the little details and delighters, creating a much more polished experience instead of feeling stretched and cutting corners. If we prioritise effectively, then the features we choose to drop are rarely missed by users, and what’s left will be fantastic.

Embrace reuse.

Reusing designs and code between projects used to feel like a taboo admission. After all, we’re being paid to build something brand new, and not to copy-and-paste our old work… Right?!

Well, in a world of design patterns and best practices it’s often unnecessary to keep reinventing the wheel when it comes to more straightforward elements.

Basic things like a text-and-image layout, a filterable gallery, or a donation form are so commonplace in our projects. We’ve built literally hundreds of them, and it must be said they rarely end up being that different. At this point, we usually know exactly the best approach for these kinds of website elements from a usability and performance point of view.

When it comes to investing effort (and therefore budget), we now pick our battles more carefully. By re-using a shared component library for more straightforward features, we can save time that can be re-invested in the truly unique and exciting parts of the product.

Whereas we used to be bashful about this, we’re now very happy when old work finds a new life. After all, we’re reusing things because we’re happy with them – and the time we win back from this kind of busywork can be reinvested into the little details and unique elements that truly make each project special and unique.

Lean into efficiency tools.

In this age of AI, it should come as no surprise that we’re readily embracing tools that can improve our productivity. This isn’t necessarily about having machines do our skilled work. It’s more about reducing the need to do repetitive, thoughtless tasks. Instead we can focus more on problem solving, and the added value that really benefits from an experienced designer or developer’s brain.

Tools like Claude and Copilot can instantly complete the more routine parts of development, and spot errors far quicker than a human could during a manual code review. These assistants drastically reduce the billable hours lost to the more tedious work that once occupied a big part of our project. It frees our team up to focus on what matters.

A very important disclaimer here. Our approach to using AI tools always needs to be measured, and put under constant scrutiny in the interest of both the environment and the quality of our work. We allow these tools to assist with setup and routine tasks, but never to completely drive the process. This subject is easily a whole post in itself, but it would be silly not to bring up the budget savings these tools can give us.

Efficiency tools were here long before AI was a thing, and having more traditional templates and boilerplates at the ready is also crucial. A lot of our underlying website code is shared between projects, so it pays to have repositories and component libraries readily available for adaptation. The more we do, and the more our process improves, the easier it becomes to start a new project.

Streamline your decision makers.

In our experience, one of the biggest ways to blow a project budget is to involve too many stakeholders in the process.

Although it’s very noble to want everyone involved, there are other ways to get folks engaged – and they don’t necessarily involve making them a decision maker. Going back to our point about priorities, it’s unlikely that everyone in your organisation is fully aligned on the goals of your project. Instead, we’ve got to seek the best possible compromise. Not everyone will be happy with the outcome, but our clients need to be able to accept this and move on from it.

Inviting too many people to feed back will result in the design process going round in circles, and progress getting blocked whilst we attempt conflict resolution. All of this drains time and energy out of the project. Instead, engage stakeholders during the initial onboarding workshops by all means – but stick to a small group of empowered decision makers.

‘Empowered’ is a keyword here. There’s nothing worse than getting weeks into a design process, only to have a senior stakeholder take a look at the work for the first time, and perform the dreaded swoop-and-poop. Having to rework things, especially in the late stages, costs a lot of money – and is another big reason for budgets to inflate.

Allow for flexibility in timings.

Every project’s delivery rests on three interconnected pillars: Budget, Scope, and Timings. You can’t change one without changing the others.

• Budget : How much can we spend? Often, this one is the most rigid.
• Scope : How many features are we delivering?
• Timings : When does it need to be delivered by?

We’ve already talked about dialling down the project scope. But what about the expectations for timings? While pushing a deadline back doesn’t reduce the total number of hours needed to complete the work, having the luxury of scheduling these hours at our convenience means we can often offer discounts to our rates.

After all, if we’d otherwise be experiencing a period of downtime, then it’s much better to have saved up some project work that isn’t as time pressured for these situations. Having more flexibility in the deadlines can be another way to potentially do more with less, when it comes to budgets.

When it just isn’t realistic, try something else.

As an agency, sometimes we just need to accept when a budget isn’t compatible with our ways of working. And that’s okay.

The great thing about web development is that there are so many different ways to approach building a product. An organisation with even the tiniest budget can still put something live, if they’re prepared to be a bit flexible in their aproach.

At Pixelfridge, we specialise in building custom sites using WordPress. Even if we employed all of the different measures we’ve described in this post, we still can’t deliver a fully-fledged and custom site on too small a budget. If it would compromise our process or the quality standards of our delivery, then it’s a deal-breaker for us.

If a client comes to us with a prohibitive budget, we’ll still help them how we can… But it may come with the suggestion of a different approach. For example, rather than building a fully custom website, why not adapt an off-the-shelf theme that does 80% of what you need it to? Or, rather than building WordPress, why not use a no-code builder like Webflow?

If the budgets are restrictive, then sometimes we just need to try something else. After all, in these cases the end often justifies the means – and having something is sure better than nothing!