I have tagged v1.00.0 of Budget, it has now entered the beta period.
The beta period will last for two months and this is a real beta; the product is feature complete. We aren’t adding any new features over the next two months, it is for bug fixes and UI/UX changes based on feedback.
For the next two months I have a freelance project so my days are going to dedicated to that and I’ll work on beta feedback during the evenings and weekends.
This year I’ve released three apps under the Costs to Expect name: two game scorers for Yahtzee and Yatzy and now Budget, a budgeting tool. Budget is a free app and next year the paid version will be released which, for now, I have imaginatively named, Budget Pro.
Budget Pro will be the first paid product under the Costs to Expect name and I have at least three more planned: an expenses tool, a data manipulation tool, and an importer/exporter.
Getting to this point has been a long journey. The first version of the Costs to Expect API was released in late 2018 and later that year we released our App (now redundant). The original idea was to have one App which handled all the distinctive features we wanted to support. However, as we added features, the App got increasingly complicated. Earlier this year I decided to ditch the monolith idea and build smaller, more focused Apps. To say that this change of direction paid off would be an understatement.
The first smaller app was the Yahtzee game scorer. After just two weeks, the app was complete and I was shocked at how simple it had been to create in comparison to the monolith I’d been supporting for two years. Next came the Yatzy game scorer which is just the Scandinavian version of the game. Having already developed Yahtzee, it was simple to create as the only difference was the scoring page.
Budget was next on my list. This had been planned for years and was one of the original reasons behind creating the API in the first place (Budget Pro not Budget). I took a copy of the Yahtzee App and got to work. Two months later, Budget is ready and now in beta.
To say I’m pleased would be understating things. With Budget ready, I’m more than halfway towards having my first paid product out there. If I had kept the old monolith around, I’m certain I wouldn’t be where I am now.
Budget Pro will be ready in the first half of 2023 and after writing these three smaller Apps, I’m confident of my estimate. There is always the chance that I’ll regret this decision later, but I doubt it as I have two options: one API and complex App or one API and many smaller more focused Apps – I’ll take the second option any day of the week.
This month I released a Yahtzee game scorer and a Yatzy game scorer, both a simple Apps which use the Costs to Expect API, they are a little bit of fun and allowed me to test some ideas.
As per a lot of the Apps in the Costs to Expect service, the game scorers are Open Source, you are free to play around with them.
I have shipped lots of updates in the last few weeks and learned a lot about the new user experience, with something as simple as the scorers it is very easy to focus on the initial experience for new users.
The lessons I have learned are already starting to improve Budget, the next App in the Costs to Expect service.
Budget is not a simple App like Yahtzee, it is going to be quite involved, no ETA yet but I would like to have a Beta out well before the end of the year, it very much depends on how much time I have outside of freelance work and contracts.
This is a minor update to an earlier post; the setup is simpler than previously.
- Download and extract the dart-sass release you are going to use, at the time of this post I opted for
- Open your
.bashrc file in WSL –
export PATH="/path/to/dart-sass:$PATH" to the end of the file, in my case
To test everything is working, open WSL and enter
sass --version; you should see the version number.
It isn’t unusual for me to release at least one new update a week for the Costs to Expect API and website. I find it significantly easier to manage and test with small iterative releases. As the only developer on this project, anything that makes my life simpler is a plus.
Occasionally a release has to touch a substantial part of the Costs to Expect API, v2.02.0 is an example of that. I need to review every section of code relating to
I intended to split the development work for multiple item types across two versions, v2.00.0 and v2.02.0. The database gets upgraded, and then I hit the code and expose the feature.
In planning, I appear to have overlooked summary routes. Rather than extend the design I developed to incorporate
item summary routes; it makes sense to modify it slightly, given the ‘new’ requirements. If I soldiered on and upgraded the
item summary routes, I suspect I would want to refactor them in a few weeks. Rather than face that situation, I feel it makes sense to go back to the drawing board and ensure I develop a design that will work going forward.
Post-release of v2.02.0, I will rework the current design, refactor as necessary and then add support for multiple item types to the
item summary routes.
I gave myself one to two weeks to develop support for multiple item types. It turns out, two weeks is probably about right given the increased (actual) scope.