Increased limit to one hundred budget items

We have published a few new features for the Budget App which are now available – check it out or continue reading to see what we’ve changed.

Increased limit

We use Budget ourselves and our mantra is that if it isn’t suitable for our needs, then it isn’t likely to be suitable for anyone else. We received feedback concerning the limit and got close to hitting it ourselves. We don’t want to think about reaching the limit again so we’ve increased the limit to one hundred budget items.

Account identifiers

If you track multiple accounts, there is an important piece of information missing from the Budget overview – the account an expense relates to. Space is at a premium on the Budget Overview; we can’t add the name of the account in addition to everything else as it will end up looking too busy. To solve this, we now allow you to set a colour for each account. Each expense will now include a small icon in the relevant colour so you can identity the account related to the expense.


We have made a couple of minor changes to the design of the projection sections – primarily for mobile users. This area of the Budget overview is very much work in progress and we are figuring out to use the extra space for tablet and desktop users.

Other changes

We have tweaked the expense bars to show a larger differentiation for smaller value expenses. Under £5 will now display differently to under £25.

We have made a couple of minor content changes and update the included env.example file for any developers who may want to host their own version of Budget.

On the way

We have several features in the works, feedback has been incredible and by using it ourselves, we are able to see where the usability falls down.

  • We are going to add a search to the Budget overview
  • We are going to add a “transfer” option – more on this soon.
  • We are going to add the ability to act on multiple budget items at once. Again, more on this soon.

Budget beta fixes and new features

We have published a couple of fixes for the Budget beta both of which relate to editing an expense.

Account / Target account

When you edit an expense, the “account” and “target account” fields will now be set to the correct value. Previously, the first value was always selected.

One-off expenses

Editing a one-off expense and changing the “due date” could cause the expense to disappear. The expense still existed; it just wouldn’t be shown because of a data issue relating to its end date. We have corrected all one-off expenses and they will display again.

New features

We have a couple of fixes on the way:

  • We are going to make the app easier to use for people who have multiple projection accounts.
  • We are going to increase the limit for expense items. A freelance user informed us that they need to use one-off expenses and the limit of 35 isn’t friendly for that type of usage so we are going to set the limit to one hundred.

First beta update

We have released an update to Budget which includes the first batch of changes raised by our beta users.

Please review the below and let us know if there is anything we have missed. Our goal is to make Budget as easy to use as possible and all the lessons we learn with Budget will make Budget Pro better.

Locked in the demo

Users who opted to load the demo felt locked in once the demo had loaded; there was no obvious way to return to the beginning and create your own Budget. Our thought process was based around the user “adopting” the demo and using it as the starting point for their own Budget. We have added a button which always shows next to “Adopt” which takes the user to the reset page so they can reset their App and start afresh.


We had added four more currencies to the App – Candian, Australian and New Zealand Dollar and the India Rupee. We will add additional currencies upon request – just let us know if there are currencies you’d like included.

Hello fellow developers!

The Budget App is open source. We reviewed the README and have updated the installation instructions to ease setup and we have added some helpful values into the .env.example file.

You can set up your own instance of Budget or even submit suggestions via GitHub. All contributions welcome and very much appreciated.

API – v2.24.0 & Progress Update

This release continues to clean up the API and correct some of the design issues introduced during the addition of new item types. Forecasting and budgeting will be making their way to the API soon, it makes sense to simplify some of the unnecessary abstractions that crept in. The forecasting and budgeting system will not behave in the same way as traditional expenses so it doesn’t make sense to try and adapt the system I had, rather allow there to be differences between all the item types.

There are 11 development stories (more will be created) and the rest of the tests to write, the API will then be ready to ship, well, the soft release will be ready. The API is not officially ready until the documentation has been moved away from Postman and budgeting forecasting support exists, either way it will be a massive milestone for us.

After that, I move towards getting the App to the same stage, soft release. When the App and API are at the same milestone, development begins on forecasting and budgeting, there might be a small intermission whilst I build another app but that can be thought of a proof of concept for the budgeting.

The next four months are going to be full-on, all we can do is see where we are in September and go from there.


  • We have added our first schema files for OPTIONS responses and started working on the tests.
  • We have added tests for category management, found one bug when creating the tests.


  • We have updated our response class for OPTIONS responses, we now allow parameters to be defined for POST requests. One example of where we need this is the create password POST request, password and password_confirmation are required fields, however, token and email are required parameters. Before this update, you had to parse the returned error of read the OPTIONS request description.
  • We have started splitting config files, a config file should be for one purpose.
  • We have spent quite a bit of time reviewing the API structure and refactoring. We have removed unnecessary complexity, renamed classes and methods to describe intent more clearly and removed pointless base classes.
  • We have reworked how allowed values are generated for the different item types, allowed values for fields and parameters have been split, and we have removed all abstraction.
  • We have removed some route validation files which didn’t do anything useful after all the item type work.
  • We have reworked the responses class, removed exception parameters when not necessary, pass in an exception if thrown and now delegated responsibility to the responses class to decide if the exception should be returned in the response.
  • We have upgraded the API to Laravel 9 and PHP 8.1.


  • Options request incorrect for the auth.register endpoint (Test added).
  • Options requests returning response twice.
  • Type corrected in OPTIONS response, authentication status/requirements now a boolean, not a string.
  • Minor correction to the description of two POST endpoints.
  • Corrected a type in the OPTIONS response for the month parameter.
  • Corrected the partial-transfer JSON schema file.
  • Allowed values not showing for category on GET endpoints.
  • Inconsistent usage of the responses helper.
  • Category validator allowed duplicate names due to incorrect params, caught by model.


  • We have removed the ItemType base class and all the child classes.
  • We have removed a redundant validation class and moved the response method into the main response class.

The wrong tests

We aren’t sure how it happened, but we ended up with the feature tests for the Costs to Expect API being a Postman collection. There are over four hundred requests in the test collection and thousands of assertions are run on the responses, somewhere in the region of three thousand.

We like Postman, we use it every day. We use Postman for development and our documentation, public and private. You can view the documentation for the Costs to Expect API at

We have come to the realisation, much too late, that testing is not something we should be doing in Postman. We have started moving/recreating our feature tests, we have opted for local PHPUnit tests.

Recreating our tests will be a slow process, every new release will include tests, however, we are not focusing on just tests. “Why?” you ask. Well, we have tests, they simply aren’t ideal.

We are aiming to have our local tests in place as soon as possible, as much as that is our goal, we must be realistic, we simply can’t justify spending weeks writing new tests when we have a suite of working tests.

Moving to local tests is paying off already. In the latest release, we improved the first-install process for the API and made the code more testable. These improvements are a direct result of moving to local tests.

We have added a section to the README detailing our progress. We don’t want this section to exist in the README for too long so will ensure we add a decent number of useful tests each release.

API – [v2.19.0]

With the impending releases we are making the API more testable and improving the first-install process.


  • We have started transferring our Postman response tests to local feature tests.
  • We have added tests for the Authentication controller.
  • We have started writing tests for the ResourceTypeManage controller.
  • We have updated /auth/forgot-password and /auth/register, both now support a send GET parameter, if defined, no email will be issued.


  • We are tweaking the first install; we have squashed all the migrations and tweaked the Docker setup. We have added an initial-install.sql file, this includes the required data for the API.
  • We have made minor changes to how we return validation errors; we were calling exit and stalling our tests.
  • We have updated the responses for /auth/forgot-password and /auth/register; responses include the required follow-on URIs and parameters.
  • We have updated the README, we have added a Tests section and updated the setup steps.

API – [v2.18.0]

We are working towards releasing the beta for the Costs to Expect App and releasing other apps; we have therefore opened up the registration on the API.


  • We have opened up registration on the API; you can register, login, and use all the expected authentication features.
  • We have added notification emails for registration and forgot password requests.


  • We have switched to Laravel Sanctum and removed all references to Laravel Passport, Sanctum makes more sense for our API.
  • We have updated to Laravel version 8.
  • We have tweaked our Docker setup and removed composer and phpunit.
  • Content updates

App – [v1.21.2]

We had to tweak our sign-in after a change to the Costs to Expect API, the API switched to Sanctum from Passport.


  • Switch to Sanctum on the Costs to Expect API, minor changes required.


  • We have updated our cache invalidation; we will not clear as many cache entries on resource creation.

App – [v1.21.1]

We have made a number of fixes and tweaks, the changes can be seen below.


  • We have added named section links, you will be taken to the relevant data, not the top of a page.
  • We have updated our back-end dependencies.
  • We have added ‘expires’ to the “API Requests” table shown at the bottom on each page.


  • With have fixed a small issue where the menu was not highlighting the active menu item.
  • We have updated the summary layouts for mobile devices; the summary counts have a little more breathing room.
  • We have increased our minimum TTL to 30 days. The one-day TTL was making a mockery of our asynchronous group requests when one or more requests return an empty response.
  • We have corrected an issue with our create resource forms; the ‘effective_date’ field HTML was malformed.
  • When you copy an expense of type ‘allocated-expense’, the effective date is copied.

App – [v1.21.0]

We have switched to using queues to clear cache.


  • We have added migrations for the job and failed jobs table; we are switching to queues.
  • We have switched to queues for cache clearing. Approximately 50% of our clear cache requests will be delayed and processed later; the rest of the clears are synchronous; it depends on where we are sending the user next.
  • We have altered the TTL for API responses; the TTL is defined based on the age of the data in the API response, we use the X-Last-Updated header.


  • Switching to named routes, work in process.
  • Minor tweak to the meta viewport tag.
  • We have reviewed the App and removed a couple of single instance classes and found better homes for some others.