We make a deliberate bet at BrizoSystem. It is not a bet most software companies are willing to make, and it costs us in ways that are easy to measure. We choose to do less, better, rather than more, adequately.
This is not a story we tell for marketing purposes. It is a constraint we impose on ourselves at the product level — one that shapes every feature decision, every interface choice, and every conversation about what belongs in the roadmap and what does not. And we believe, based on evidence and on principle, that it is the right bet.
Here is why.
What Simplicity Is Not
Before making the case for simplicity, it is worth being precise about what it is not. Simplicity is not a reduced feature set. A product with ten features can be more complex than a product with fifty if those ten features are poorly conceived, poorly named, and poorly connected to the workflow they are meant to support.
Simplicity is not ease of use in a superficial sense — large buttons, cheerful colour schemes, onboarding tours that walk users through a product they will never fully understand. That is the cosmetic layer of simplicity, and it often masks the same underlying complexity that makes software exhausting to use.
And simplicity is not dumbing down. The accounting workflows BrizoConsol supports — multi-entity consolidation, IFRS-compliant group reporting, intercompany eliminations, NCI calculations — are genuinely complex. Simplifying the software does not mean pretending the problem is simpler than it is. It means understanding the problem deeply enough to handle that complexity on behalf of the user, rather than asking the user to handle it themselves.
Real simplicity is the condition in which a capable person can use a product to do a hard thing without the software itself becoming an obstacle. That is the standard we are aiming for. It is harder to build than complexity.
Why Complexity Accumulates and Simplicity Does Not
Left to natural forces, software products become more complex over time. This is not because the people building them want complexity — it is because complexity is the path of least resistance at every individual decision point.
Adding a feature is cheaper than redesigning a workflow to make the feature unnecessary. Exposing a configuration option is faster than making the correct choice by default. Building a new module is easier to justify than removing an existing one that somebody, somewhere, uses. Every individual decision to add rather than refine is reasonable on its own terms. Collectively, they produce a product that nobody designed but everyone has to live with.
Simplicity does not accumulate the same way. It has to be actively maintained — protected against the pressure to add, to expand, to cover every edge case with its own interface element. This is why most software companies, even those that start with simple products, drift toward complexity as they grow. The forces pushing toward addition are constant. The discipline required to resist them requires conviction about what the product is for and who it is for.
Adding a feature is a single decision. Removing one — or never building it in the first place — requires being willing to say no to things that seem reasonable on their own terms.
The Evidence That Simplicity Wins
The argument for simplicity is not just philosophical. It is empirical. The software products that have displaced incumbents across every major category over the past two decades have consistently done so by being simpler, not by being more capable on paper.
Xero displaced older accounting software not by having more features but by being intelligible to business owners who were not accountants. Slack replaced email for internal communication not because it did more but because it removed the friction from the specific kind of communication that teams actually needed. Notion displaced entrenched note-taking and documentation tools not through superior capability but through a model that required less cognitive overhead to get started with.
In each case, the incumbent had more features. In each case, the simpler product won a generation of users — and then won the market.
The pattern holds in B2B software too, even in categories where complexity has historically been treated as a proxy for value. The firms that buy NetSuite or SAP often do so because the procurement process rewards comprehensiveness. The firms that actually use the software day-to-day often do so despite its complexity, not because of it. When a simpler alternative that covers the specific workflow they actually use becomes available at a fraction of the cost and implementation overhead, the switching calculus changes.
What Simplicity Actually Requires to Build
Understanding that simplicity wins is easy. Building it is not. Simple products require more of their builders than complex ones, for a reason that is counterintuitive: the complexity does not disappear — it moves from the user’s experience into the product’s internal design.
When an accounting tool automates intercompany eliminations, the user does not have to think about the journal entries required to remove intragroup revenue and corresponding cost. But the product has to. It has to understand the accounting treatment, handle the edge cases, deal with partial ownership structures, and produce output that would pass a technical review. The work has not been eliminated — it has been absorbed by the software so the user does not have to do it.
This is why deep domain knowledge is a prerequisite for genuine simplicity. A product team that does not understand consolidation accounting in detail cannot simplify it — they can only expose the raw complexity to the user and call it a feature. Building a product that handles the hard parts invisibly requires first understanding the hard parts completely.
It also requires a particular kind of discipline in product decision-making: the willingness to solve a problem correctly, once, rather than offering the user a set of tools to solve it themselves. The temptation to add configurability — to let users decide how eliminations should work, which accounts should map to which categories, what the exchange rate methodology should be — is always present. Resisting it in favour of opinionated, correct defaults is the harder and more valuable choice.
The Bet We Are Making
Building for simplicity means accepting constraints that our competitors do not accept. It means that some prospects will choose a more feature-complete product because their procurement process measures value in module count. It means that some requests from users will be declined because adding them would compromise the coherence of what the product already does. It means that growth will sometimes be slower in the short term because building the right thing carefully takes longer than building the next thing quickly.
We accept these constraints because we believe the alternative is worse — not just for users, but for us as a company. A product that accumulates complexity becomes harder to support, harder to improve, and harder to explain. It attracts users who spend more time managing the software than using it, which means more support load, more churn, and less evidence that the product is creating genuine value. Simplicity is not just a user experience principle. It is a business model.
The bet we are making is that the market for accounting and business software in Singapore and the region will, over time, move toward products that work rather than products that merely exist. That the firms managing multi-entity clients do not want a platform that can theoretically do everything — they want a tool that reliably does the specific thing they need, without requiring a specialist to operate it. That lightweight, focused software built around deep domain expertise will outperform generalised platforms at the specific jobs those platforms were never truly optimised for.
How This Shows Up in How We Build
The commitment to simplicity is not an abstract principle at BrizoSystem. It shows up in specific product decisions that we revisit constantly.
We build opinionated defaults rather than exposing configuration. When BrizoConsol runs intercompany eliminations, it applies the correct accounting treatment by default — it does not ask the user to configure the methodology. When exchange rates are applied in a consolidation, the product follows the standard IAS 21 approach unless there is a specific and documented reason to deviate. The user is not burdened with decisions that have correct answers.
We measure success by first-session completion, not feature coverage. The question we ask when evaluating a new workflow is not “does this work for a power user who has spent three months with the product?” It is “can a competent accountant who has never seen this product complete this task today, without reading documentation?” If the answer is no, the workflow is not finished.
We decline features that belong somewhere else. BrizoConsol is a consolidation platform, not a general accounting tool. It is not trying to replicate what Xero or QuickBooks does — it is trying to do the thing that comes after those tools reach their limit. Staying within that scope is how we keep the product coherent. When users ask for things that fall outside it, we say so directly, and we mean it.
The Standard We Hold Ourselves To
The measure of whether we are living up to our own principle is simple: can someone who is good at their job — accounting, finance, business development — pick up one of our products and do something useful with it today, without becoming a student of the software first?
If the answer is yes, we are building what we set out to build. If the answer is no, that is not the user’s failure. It is ours. And it is the thing we go back and fix.
Simplicity wins because users are not looking for software to admire. They are looking for software that gets out of the way and lets them do the work they are actually good at. That is what we are building. And we believe it is the right bet.