Hitting reset: how Laura Roeder restructured MeetEdgar for profitability

Executive overview

A multi-million dollar SaaS can carry a team far larger than its revenue trajectory justifies. After years of flat MRR and a failed reinvestment year, Laura Roeder let go of MeetEdgar's entire full-time team and rebuilt with freelancers — reducing operating hours by 90% while lifting profit margin to 60%.

The core tension: headcount feels like a proxy for seriousness, but for a stable self-serve SaaS the software delivers value, not the people.

Match team structure to what the business actually needs today, not to what a fast-growth company would need.

Why headcount gets out of control

• Early fast growth (1M ARR in 11 months, doubled next year) justified hiring at pace — but growth stalled while the team did not shrink
• A cultural script equates team size with legitimacy: "how big is your team" is a status signal
• Attributing revenue to non-sales roles — especially engineers — is nearly impossible in a self-serve model
• Roles added for specific projects became permanent even after the project was done (e.g. a full-time marketing data analyst)
• Busy work accrues: customer service Q&A calls, educational webinars, none of which correlated with reduced churn

The failed reinvestment year

• 2020: reinvested all profit margin back into the business — hundreds of thousands more than prior years, plus PPP funds
• Priorities: expanded engineering team, launched Pinterest integration, additional marketing support
• Result: MRR ended 2020 slightly lower than it started
• Conclusion: the structure of the team, not the level of investment, was the problem

The reset decision

• Key question: what team does this business need to stay flat, not to grow?
• SaaS is unique — customers pay for software, not people; the delivery is automated; human effort is maintenance, not product
• At stable state, most roles either disappear or shrink to part-time
• The decision was made while the business was healthy, not in crisis — this made generous severance (3 months) possible
• Open financials with the team meant the announcement was a shock, but not a total surprise

Before vs. after team structure

Before (March 2021):

• Product: 1 product owner/designer, 3 full-time devs, 1 part-time dev, 1 part-time QA
• Customer service: 2 full-time, 1 split CS/QA
• Marketing: 1 full-time manager + freelancers
• Operations: president, HR/ops assistant, full-time in-house finance
• Total: ~1,840 hours/month; profit margin 0%; owner pay 10%; MRR growth 0%

After:

• Development: 1 freelance developer, 20 hrs/week (maintenance and bug fixes)
• Customer service: 1 freelancer, 10 hrs/week; 1 cross-trained backup from another business
• Marketing: small content agency updating existing blog posts (500+ posts); SEO on existing content outperforms new production
• Operations: freelance bookkeeper (monthly); freelance project manager for ad hoc tasks
• Total: ~170 hours/month; profit margin 60%; owner pay 10%; MRR growth 0%

What changed — and what didn't

• Revenue outcome: identical — flat MRR, same ARR base
• Operating hours: 90% reduction
• Profit margin: 7× increase
• Growth did not improve — that was expected and accepted
• The structure is now honest about the business's actual state

Lessons and Q&A highlights

• On product stagnation: Expected. A dev agency is trained up and can be engaged if feature investment is needed — flexibility traded for familiarity with the codebase
• On selling: Likely within a year; the lean structure is attractive to acquirers who want to apply their own growth playbook
• On what killed growth: Twitter banned repeated content (MeetEdgar's core feature); copycat tools eroded uniqueness; expansion revenue was never built in
• On team reaction: Mostly positive; several employees had privately wanted to leave but didn't want to disrupt the culture; one strongly negative reaction
• On PaperBell (new SaaS): Built freelancer-heavy from day one; same content/SEO playbook, but no full-time hires — hiring full-time only when a role is clearly indispensable
• On engineering priorities: Code base was heavily refactored but lacked the right balance of refactoring vs. competitive feature work