My development plan

Man starting a development process which ideally is back up by a development plan

In this blog post I discuss my development plan for Budget and Budget Pro as well as the pros and cons for each option I could take.

Why two individual apps?

From the start I always planned on their being two versions of our Budgeting App, Budget and Budget Pro. The relevant questions are: How will be achieved? What development plan makes the most sense?

A little background first

Budget is a free and open-source budgeting App powered by the Costs to Expect API. Budget Pro is the commercial offering aimed at users with more complex budgeting requirements and later, Businesses.

Now, The Options

There are three ways to end up with two related Apps.

  1. Start with the simpler App, duplicate, and add features.
  2. Start with the more complex App, duplicate, and remove features
  3. Build two independent apps

There are pros and cons for each option, a major one for the first two being they share a code base. This can also be a negative from a security point of view, but we aren’t discussing that in this blog post.

Why not duplicate and add features?

My major problem with developing this way is the assumption you are only adding features. If you simpler and more complex version are only different due to a couple of features, this can work. However, when those features become architectural, the flaws to this approach soon become apparent.

Budget is a single user App and there is only one budget whereas in Budget Pro, there can be multiple budgets and budgets can be shared among users. These are core architectural differences, I could hack the budget service and add a wrapper for sharing, multi-currency, and multiple budgets but everything quickly starts to breakdown.

Why not duplicate and remove features?

This option is cheap, the simpler version of the App is clearly the ‘real’ version with code removed, it doesn’t sit well with me and is not something I would ever be comfortable doing.

Why two Apps?

As discussed above, the architecture for Budget and Budget Pro is different. Budget Pro will be multiuser, support multiple currencies and support multiple budgets in addition to many other features.

The budget “service” in Budget works well but it was designed knowing the requirements, at the time we were still deciding what Budget Pro would include. We can add features to the “service” but I tend to find that adding features after often results in your well-designed service starting to feel a little hacky.

When you add on that one App is open source and the other won’t be, it starts to become obvious which development plan makes more sense, especially when you discount the first two :).

Any Benefits?

So, are there any benefits to writing two Apps rather than one? Well, yes, yes there are, I’m glad you asked.

There are three major benefits, speed of release, improved architecture, and the ability to learn from mistakes.

Speed of release

The simpler App will be the quickest to build, as such you can get something to market sooner. Yes, this benefit is shared with Option 1 but you are always going to end up with architecture issues and feel the urge to strip out the code for the simpler App when the more complex version has been written and had the architecture fixed.

Improved Architecture

Each App will have been designed knowing what it needs to do so in theory, you will end up with the best architecture for each App. This is not a given of course, none of us are perfect but you are much more likely to get there following the development plan I am for Budget and Budget Pro.

Learn from mistakes

This is a newly discovered benefit, not something I originally considered. During the beta of Budget, we learned a lot from our first users, building two Apps means we can make use of those learnings and ideally not have to deal with them the second time and more importantly, release a much higher quality App.

Any Negatives?

So, what are the negatives, well, for one, there are two distinct code bases and two, the time required – it will take longer to write two independent Apps than building one and a half*.

Two code bases

It will always be harder to maintain two code bases, rather than one code base and a few extra features. There is no way around that point, however, it is a negative I am comfortable with as it allows me to try different things. Budget uses Bootstrap, Budget pro uses Tailwind, I would have been less likely to try Tailwind if the two Apps shared a code base.

Is the development plan working?

I think so yes, I’m still early in the development of Budget Pro but I’m enjoying the freedom. When I’m working on Budget Pro, I don’t need to worry about any of the baggage in Budget (it will get its own) and am free to design my new systems. I don’t have to worry about adapting or changing how something works and the unintended issues that come with that.

I’ll be able to give a more complete answer when I release the beta of Budget Pro. However, I’ve enough experience to know that I’m making the right choice.

* There is a possibility that this is not entirely true, if you opted for Option2, it is possible you will take so long to build the fully featured version you never get to release and therefore never get to the cut down version.

Budget – Official Release

Budget - The Official Release

Late last year, I released Budget, a free open-source App powered by the Costs to Expect API, with a beta tag. After bringing the Wife on board to help, we started to respond to feedback and polish the App. We wanted as much feedback as possible before the official release which is now ready.

Beta Release

We spent quite a while testing the App before releasing it with the beta label. However it is always amazing just how many issues appear when the public at large start using your stuff.

We ended up pushing seven small updates, each improving the UX and UI of the App that extra little bit. All these improvements will make it into Budget Pro (the subscription version of Budget) and eventually all my other Apps. After 25 years of web development, I still admit I have a lot to learn and am always happy when I do learn something new.

I’ve released several Apps over the last two years. However none have been as polished as Budget and I have to say I am proud of what I’ve created and keen to start focusing on Budget Pro, the commercial offering of Budget.

I have a blog post coming soon explaining why there are going to be two versions of Budget and why they are going to be created in the way they are. The short story is, I’ve always intended for the Apps to be separate, and I think the approach I’m taking will ensure that they can each shine in their own way.

The Next Chapter

This is the start of a new chapter and I’m keen to see where it goes, only time will tell.

We learned so much during the last two months, hopefully we can benefit from the new knowledge as we approach the beta release of Budget Pro. Budget Pro is much more complicated than Budget so I’m sure we will discover an entire new set of issues which hopefully our beta users will be able to help us resolve.