Are 3rd Party Contributions For New Features To The Website/App Accepted?

  • 1
  • Idea
  • Updated 1 month ago
  • Not Planned
I've noticed that when users request some basic features that a lot of people upvote, we very frequently get this response from the Goodbudget team: "that is a great idea, but it is not currently on our roadmap". And many of these requests are several years old. On the posts, the team usually says these are good ideas but don't give any reason for why they wouldn't be implemented (such as security, usability, etc.), so it makes me think the only reason these aren't on the roadmap is because the Goodbudget dev team is too busy and don't have time to prioritize them.

If that is the case, can you please allow code contributions from 3rd party developers who are willing to voluntarily add these features (without charging money; they do it because they use Goodbudget and want these features). A lot of these requested features would be fairly simple to implement, so it's so frustrating to me (and many others) to just wait for years for a highly-requested feature just to lose hope when the Goodbudget team provides us a subpar workaround and closes the issue. Many of us would be happy to volunteer a little of our time to implement many of these easy features that are currently getting neglected.
Photo of krispyokreme


  • 8 Posts
  • 4 Reply Likes
  • frustrated

Posted 1 month ago

  • 1
Photo of Chi-En Yu

Chi-En Yu, Official Rep

  • 514 Posts
  • 36 Reply Likes

Hi krispyokreme,

We appreciate you offering to support Goodbudget by contributing code -- that's very generous!  At the heart of your post, it sounds like the pace of development is too slow for you, and you also don’t understand why certain features have not been built.  I’ll respond on each of those points in order here (1) 3rd party code contributions, (2) pace of development, and (3) prioritization choices.

Code contributions.  Unfortunately, we don't plan to start open-sourcing the Goodbudget code or begin accepting third-party contributions. Our preference is to keep our development in house.  Part of that is because, even if we chose to have third-party contributions of code to our base, that wouldn't necessarily get features out faster.  We’d still need folks on the rest of our team to evaluate which features fit our product vision, design the customer experience of each feature and the product as a whole, test and fix the code, project manage the work, develop marketing, write help content, and support folks day-to-day who are using the features. So it makes sense to keep our projects in our office so we can all focus together and integrate our work with each other more easily.

Pace of development.  While we’d love to have a faster pace of development (both as the team that runs Goodbudget and as Goodbudget users ourselves), we do choose to live within a few financial boundaries that affect our pace.  As you can imagine, if we had more money, we could and would hire more staff for development and other skill sets in order to speed up our pace.  Several of the financial boundaries we’ve chosen are directly related to you all as our users.  We offer a Free Forever version, price our paid version reasonably, and refuse advertisements of any kind.  To us, these choices are extremely important.  We want to make a budgeting tool like ours available to anyone who’s interested, regardless of ability to pay, so we’ve offered a Free Forever version for the nearly 10 years we’ve existed.  For those who are looking for more features, we’ve chosen a price point that’s proven to be accessible to a wide swath of people.  And finally, we have declined all requests by other companies to advertise to our users through in-app ads or elsewhere.  To us, it seems counter-intuitive to create a budgeting tool that simultaneously invites you to spend more money on things you might not need.  These choices do have direct financial implications that limit our pace of development; and even so, we gladly choose them because we feel it’s good for our customers and right for us as a business.

And thank you for recognizing that our team is busy – we are never lacking for things to do!  In our experience, developing and maintaining an app using our team’s process and style takes a lot of time. Between the three platforms we support (iPhone, Android and the web), we're always working on something.

Prioritization choices.  Because we're a small team, we do have to prioritize what we work on more carefully. We consider lots of different factors when we're deciding what to work on. We think about things like -- how much does this feature improve people's overall budgeting experience, how many people will be impacted by the feature, how much effort will it take to build, how popular is it, how would we support it in the long run etc. Prioritizing means that we'll say "no" to some features so that we can say "yes" to others.  We want to be transparent about what we are working on, so we make that information available at I apologize that our repeating "Great idea, but we're not working on it right now," makes it sounds like there’s no reason not to do it.  We tend to focus on 1-2 top priorities at a time, and many good ideas do indeed get de-prioritized so that we can focus on those top priorities.  Our current foci are Debt-related features and Courses, which we’ve chosen because of the very large number of people that they affect.  We spent years listening carefully to folks both to choose these foci and to develop the features we’re offering in these areas.  Debt-related features affect over 40% of our user base at a fundamental usability level, and Courses will support everyone’s financial journeys beyond the software tool, from brand-new budgeters to seasoned money managers.  Of course, we do set aside time to work on smaller enhancements, bugfixes, and maintenance too; but the bulk of our time tends to go toward the top 1-2 priorities.

We continue to listen to all Goodbudget users, and that's why the forums, among other places, serve as a platform for Goodbudgeters to let us know what's important to them. We also keep our ears tuned to our email conversations and all the other places people connect with us so that we can develop Goodbudget in such a way that as many folks as possible benefit from the time we put in to Goodbudget.

We hope this makes sense! And thanks again for posting.

Chi-En and the Goodbudget team
Photo of krispyokreme


  • 8 Posts
  • 4 Reply Likes
Hi Chi-En,

Thank you for taking the time to write such a thoughtful response. As a developer myself, I completely understand that there are a lot of constraints that necessitate aggressive prioritization and force many good features to languish in a backlog forever. I started this post because I thought it couldn't hurt to at least ask whether Goodbudget is open to outside development, but I also understand why you would say no.

While it is frustrating to me when I see highly wanted features not being developed, I do love a lot of things about Goodbudget (perhaps that is why I'm passionate enough to get frustrated in the first place, rather than just simply give up on the app), so I will continue to use it and support your ongoing efforts to improve it. And even though the response is often "we are not working on this", I do appreciate that Goodbudget at least actively responds to every forum post (which is a lot more than what many other app development companies do!). I think ensuring that the voice of the customer is always heard is the right approach to running any business, so thank you for that.