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.

How it evolved

How it evolved

So in my first blog, I explained how Costs to Expect all began – as an all-consuming social experiment to track how much it costs to raise children to the age of 18.

As I said, in the beginning hubby kept a very crude excel spreadsheet which literally recorded what the expense was and its value. I soon got used to the question, “So what did you spend today?!”  At first, it was pretty straightforward as everything we brought for Jack was directly attributable to him – for example nappies, milk and clothes. If I brought any of these things in our monthly shop, I simply pulled them out as his expenses.

Things became a little more complex as Jack grew older and began eating and using the general household shopping. We periodically reviewed our shopping and allocated a percentage to him. For example, when he was two and eating the same us, we allocated 10% of our shopping to him. Now, at the age of eight, his percentage has increased to 23% – I dread to imagine our shopping bill as he hits the teenage years and we have another hungry lad coming up behind him!

We’ve had many discussions / debates about what we should include and what should be discounted.  For example, we haven’t included a share of our utility bills as we figured these would be more or less the same without the children. However, we have included an allocation for our summer holidays when it has been somewhere we might not have gone if it wasn’t for the boys – typically for us a week at Center Parcs which is family focused. We’ve sometimes disagreed over what to include and/or the percentage and the question we always ask ourselves and each other is, “Would we have brought this / done this if we didn’t have the boys?” Most of the time, this solves it one way or another.

What I should say is that we absolutely recognise that every family and their budget is different and that’s why when we built the first version of the app, we decided to categorise the expenses into “Essential” and “Non-Essential” costs. We define essential costs as “The costs that we see as absolutely necessary in raising a child and in essence, keeping them healthy and alive” – pretty obvious I’d say.  The non-essential costs are explained as, “The optional costs of raising a child and those which spark lively debate between Mummy and Daddy”.(!) And boy, have there been plenty of those!  So in truth, the essential costs are the minimal amount needed to raise a child, with the optional costs varying between families and combined, they offer a rough guide to the overall cost of raising a child. 

An interesting debate that we had was around the cost of childcare and how we catagorised it. For many families with two working parents, we recognise that this would be regarded as an essential costs. However, we decided to allocate it as a non-essential cost, mainly because I wasn’t working but having some childcare support helped me in managing my condition (read more here), particularly when Dean was in demanding contracts which kept him away from home.

Another interesting point in the experiment came along with the arrival of our second little boy, Niall. We pondered the question, did it really cost £250K to raise each child? Surely the second should be slightly cheaper because of all the things you brought the first time round which could be reused? This led us to build in what we call “Partial Transfers” – where we transfer 50% of the cost for anything that has been used again from Jack to Niall. As Niall is only two, we’re yet to see the impact of this but it is on my list of upcoming blogs.

I hope this gives an insight into the project and how it has developed; there will be more to come as well as blogs about how the project has grown and our vision for the Costs to Expect service.

How it all started

When I first met hubby, I was blissfully unaware of just how his mind worked.  As I got to know him, I realised that his career in web development was the perfect fit for how his brain worked. He questions absolutely everything; likes to find a solution to every problem and refuses to accept things at face value. There aren’t many hours in the day when I can’t see the clogs in his brain turning!

When our thoughts turned towards starting a family, my instinct was to start choosing names, cooing over scan photos and eventually, telling our happy news to friends and family; hubby’s instinct was to set those brain clogs spinning.

He’d heard about the research which suggested that it costs almost £250k to raise a child to the age of 21. Hubby being hubby, he couldn’t accept that could be true. Who had that kind of money? Who had it once, let alone twice, three or even more times over? How did they come up with that figure? I wonder if you can guess where I’m going with this?!

Yep, you guessed it. Hubby wanted to disprove this figure and decided we were going to embark on an 18 year social experiment to do so – yes, we were going to record every single expense for our son Jack, who was born in June 2013.

At first, I thought it was a flash-in-the-pan idea and that he’d get bored pretty quickly. How wrong was I?! Initially everything we spent got rather crudely recorded on a spreadsheet which hubby edited after each shopping trip. I soon got used to holding on to my receipts!

But then things got serious. In between his day job of contracting, hubby began building Version 1 of the app to record the expenses. This first version was very simple and just replaced the spreadsheet that we’d been keeping. However, as time went on, more detail was added and I soon found I had a part-time job in recording  everything we were spending.

However, as time rolled on and hubby developed the app, adding more features, I began to realise this wasn’t just about recording our expenses for our, by now, two boys. Hubby had a vision for a data management system and our social experiment was providing him with a vast amount of data which he could use to test and develop  what he’d already mapped out in his head.

Though I have very little understanding of the development side of things, I began to understand the vision hubby had as I watched the app develop. It suddenly dawned on me what it was capable of and indeed, I’ve been able to contribute a few ideas of my own, much to hubby’s annoyance!

Now I’ve explained how it began, I’ll be sharing more information about the project and the app’s features in coming blogs.  In the meantime, please follow us @coststoexpect and let us know if you’d like access to our beta app!

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.