Moniqo isn’t planned out in a boardroom. It’s shaped in public, one GitHub issue and one Discussions thread at a time, by the people who actually use it to manage their money.
That’s not a marketing line — it’s a practical description of how the product gets built. And it’s worth explaining why that matters, because community-driven software tends to end up better than software built behind closed doors. Real usage surfaces bugs that internal testing never catches. Feature ideas come from people solving actual budgeting problems, not from guesses about what users might want. And because the whole process happens in the open, you can watch it happen instead of just hoping something you asked for eventually shows up.
Here’s how that actually works, from an issue you file to a feature you use.
Why Moniqo Is Built in the Open
Moniqo is open source. The full codebase, the issue tracker, and the discussions that shape the roadmap all live at github.com/moniqohq/moniqo, where anyone can read them.
That’s more than a philosophical stance. It means anyone can inspect how their financial data is actually handled instead of taking a privacy policy’s word for it. It means the roadmap isn’t a mystery — you can see what’s being worked on, what’s been rejected, and why. For a personal finance tool built around zero-based budgeting and envelope budgeting, where trust matters more than it does for most software categories, that visibility is the whole point.
Being open also changes the feedback loop itself. In a closed product, a feature request goes into a form and disappears. At Moniqo, it becomes a GitHub issue that other users can find, comment on, and upvote — and you can watch it move from “reported” to “shipped.”
How User Feedback Becomes Product Decisions
Most product decisions at Moniqo start as GitHub issues. When someone files a bug report or feature request, it enters the same queue the core team reviews regularly — there’s no separate, quieter backlog for “real” priorities. A well-explained issue, with context, screenshots, and a clear description of the problem, routinely makes it onto the roadmap.
The improved CSV import in v0.4.0 is a good example of the whole pipeline in action. It started with community bug reports: users’ bank exports weren’t importing cleanly, and each report included the specific format that was failing. Rather than the core team trying to guess at every bank’s export quirks, contributors who actually used those banks submitted pull requests adding native support for their formats. The feature that shipped was built by the people who hit the problem firsthand.
That’s the pattern repeated across most of Moniqo’s changelog: someone reports a real problem, the conversation happens in the open, and the fix often comes from someone other than the core team.
GitHub Issues and Feature Requests
GitHub Issues is Moniqo’s product backlog — not a support inbox that feeds into a separate internal tracker, but the actual list the team works from.
If you have an idea for a feature, browse existing feature requests tagged with the enhancement label before filing a new one — it’s the fastest way to see what’s already been proposed and add your voice (and use case) to it.
If nothing matches, open a new issue. The requests that get picked up quickest tend to share a few things in common:
- A clear description of the problem, not just the desired feature
- A concrete use case — what were you trying to do when you hit this?
- Screenshots or examples where relevant
Vague requests (“it would be nice to have more customization”) are much harder to act on than specific ones (“I can’t split a transaction across two envelopes when a purchase covers groceries and household supplies”).
Community Discussions and Idea Sharing
Not every idea is ready to be a formal feature request yet. That’s what GitHub Discussions is for — a space for “what if Moniqo could…” conversations, open questions, and half-formed ideas that haven’t been scoped out.
Discussions often turn into issues once an idea gets enough interest from other users. Someone floats a concept, a few people chime in with their own version of the same need, and the shape of an actual feature starts to emerge — at which point it’s ready to become a tracked issue.
It’s also where people help each other with budgeting workflow questions that have nothing to do with the product roadmap. That peer support is its own kind of contribution: it means fewer questions land solely on the maintainers, and it builds a community that sustains itself.
Bug Reports and How They Improve Reliability
Bug reports are some of the highest-value contributions a community can make. No internal test suite fully captures the range of real bank formats, operating systems, and budgeting habits that thousands of users bring to the app — that only surfaces once real people are using it.
A good bug report includes steps to reproduce the issue, what you expected to happen, what actually happened, and your Moniqo version. That’s usually enough for a maintainer to confirm the problem quickly rather than going back and forth asking for details.
From there, the loop is straightforward: reported, confirmed, fixed, released — and the person who reported it gets a changelog entry to point to. Over time, that loop is a big part of why open source apps tend to feel more reliable the longer they’ve been in the wild: every edge case a user finds gets fixed once, for everyone.
Contributions Beyond Code
There’s a common assumption that contributing to open source means writing code. At Moniqo, that’s just one path among several.
Documentation, Design, and Translation
Documentation gaps are usually found by users actually following the user guide step by step — not by the team re-reading their own docs. If a step is missing, unclear, or out of date, flagging it (or fixing it directly) is a genuinely high-impact contribution.
Design and UX feedback shapes real interface decisions too. Budgeting apps live or die on whether the day-to-day experience of tracking envelopes feels effortless or like a chore, and that’s easier to judge from outside the team than from inside it.
Translation and localization work opens Moniqo up to users who don’t work comfortably in English — a meaningful way to contribute without touching a line of application code.
Testing and Answering Questions
Trying out pre-release builds and reporting what breaks catches problems before they reach everyone else. And answering another user’s question in Discussions or on an issue thread is its own quiet form of contribution — it moves things forward without requiring a pull request at all.
The contribution guide covers all of these paths, not just the code-focused one.
How Moniqo Prioritizes Community Suggestions
Not every suggestion can be built, and it’s worth being honest about how prioritization actually works rather than pretending everything makes the cut.
A few things weigh into what gets picked up: how many users a change would affect, whether it fits Moniqo’s core approach to zero-based and envelope budgeting rather than pulling the app in a different direction, how complex it is to implement well, and how much maintainer time is realistically available. Requests that don’t move forward aren’t ignored — they stay open, visible, and open to being revisited if circumstances change (more interest, more contributor bandwidth, a cleaner way to implement them).
The good first issue label is one visible piece of that triage process: it’s a curated set of approachable tasks specifically set aside for first-time contributors, rather than the whole backlog dumped on newcomers at once.
Ways to Get Involved
You don’t need to be ready to write code to start. A reasonable path, roughly in order of how much time it takes:
- Star or watch the repository to keep an eye on what’s shipping.
- Join Discussions and share an idea, a question, or just your budgeting setup.
- File a detailed issue the next time you hit a bug or think of a missing feature.
- Try a
good first issueif you want to contribute code — the contribution guide walks through setup. - Help with docs, design, or translation if code isn’t your thing — these contributions matter just as much.
No contribution is too small to be worth making.
Frequently Asked Questions
Is Moniqo really free and open source? Yes. The full source code is available at github.com/moniqohq/moniqo under its open source license, and anyone can read, use, or contribute to it.
How do I request a feature for Moniqo? Check the existing feature requests first, then open a new GitHub issue with a clear description of the problem and your use case if nothing matches.
Can I contribute to Moniqo if I don’t know how to code? Yes — documentation, design feedback, translations, testing, and answering questions in Discussions are all genuine contributions that don’t require writing code.
Where can I report a bug in Moniqo? File an issue on GitHub with steps to reproduce the problem, what you expected, and what actually happened.
How does Moniqo decide which features to build next? Priority depends on how many users a change affects, whether it fits Moniqo’s budgeting approach, how complex it is to build, and available maintainer time — the process happens in the open, on the issue tracker itself.
What is a “good first issue” in the Moniqo repo? It’s a label the team applies to tasks that are approachable for first-time contributors, curated specifically to make it easier to make a first pull request.
Built With, Not Just For
None of this works without the people who take the time to file a clear bug report, describe a feature they actually need, or answer another user’s question in Discussions. That’s the honest version of how Moniqo gets better: slowly, in public, through a lot of small contributions that add up — the same kind of small, consistent habits behind tips that actually help you spend smarter.
If you’ve got an idea, a bug, or just a question, Discussions is open. We’re grateful for everyone who’s part of building this.