Build, buy, or reinvest at $50M-$100M ARR
A milestone should force a choice: build the next capability, buy a team that already has it, or reinvest in retention.
At the ARR milestone, the next capability decision stops being theoretical. You can build it, buy a team that already has it, or reinvest in retention. A milestone should force that choice instead of drifting into feature work.
Monarch gives a clean recent example. On Oct. 1, 2026, Monarch said it had reached $100 million ARR and had acquired MBI, the former HMBradley team. It also reported a member base of more than one million people actively managing their finances on the platform.
The milestone is a decision, not a trophy
After a major ARR threshold, teams often want to spend new revenue on the most visible feature. A better move treats the threshold as a forcing function. You already have a product that people use. The open question is whether the next increment comes from adding a new capability, buying one, or making the current product stickier.
Start with the capability, not the staffing plan. Once the next growth depends on a feature your team has not shipped, estimate how long it takes to reach competence. Include design, data, compliance, integrations, and support. A long answer makes an in-house build a bet that your team can out-learn an existing product team while the market keeps moving.
Write the estimate in months, not vibes. If the number depends on a hire you have not made, a data source you do not control, or a compliance review you have not started, add the delay.
Run the test in three moves. Name the next capability in one sentence, and tie it to a revenue or retention outcome. Estimate time-to-competence for an in-house build, including the infrastructure you would need to support it. Then choose build only when you can close the gap faster than buying, buy when the team already has the product and infrastructure, or reinvest when the next growth is depth in the existing product.
Honesty is the hard part. Most teams can estimate the feature. Fewer can estimate the support load, the data model, the edge cases, and the sales motion that makes the feature believable.
Buying a team can rule out the in-house build
Buying draws the strongest objection: it is expensive, slow, and distracting. That objection holds when the target is a logo, a codebase, or a vague strategic option. It weakens when the target is a team that has already shipped the capability you need. In that case, the purchase is a bet on a present product.
Monarch's MBI acquisition fits that second case. MBI, which began as HMBradley, brings roughly ten years of work across consumer banking, financial infrastructure, and money-management product development. HMBradley's savings product gave customers higher APYs tied to their savings behavior, and the company later created Routines, a trigger-and-action automation system for saving, moving, and organizing funds. Monarch characterized the MBI deal as its first acquisition, with the former HMBradley team forming Monarch Labs to create more financial products and services for Monarch members.
Time-to-competence drives the difference. If the acquired team can start shipping in quarters rather than years, the premium may be cheaper than the delay. Do not buy when you need a team to learn the problem from zero. For a personal finance app at scale, the deal adds a path to more financial products without starting from a blank repository.
Reinvest when the next growth is depth, not breadth
Founders often avoid the third option because it is less dramatic. Reinvest in retention when the next growth comes from making the existing product more useful, more reliable, and more central to the customer's workflow. When your members are already using the product to manage money, the next dollar may buy more value from the same surface area.
Monarch counted the Monarch Plus premium tier among its 2026 growth milestones. A paid tier can turn a broad member base into a deeper revenue relationship without requiring a new product category. It also gives the company a clearer signal about which users are ready for more advanced tools. That signal matters when you are deciding whether to build or buy the next capability.
