# The profitable startup DevFeed: [The profitable startup]() Original publisher: [Read original article]() Published: 2025-02-21T16:46:55Z Content type: opinion Language: en Sources: [Linear]() Topics: [Business, Industry, Usability, User Experience, User Research, Web Strategy](), [Self-organizing Team]() Tags: [funding](), [startup](), [startups](), [team]() ## AI overview The author argues that software startups can pursue profitability while continuing to grow by keeping teams focused, hiring deliberately, managing costs, and building products customers will pay for. The article presents Linear's experience and recommends measuring revenue per employee, assessing market risk, and hiring against specific needs. Profitability, the author says, gives founders more control over growth and fundraising choices. ## Source excerpt For years, startups have been taught to prioritize growth over everything else. Profitability was seen as unambitious or even wrong - something to worry about when you hit scale. Why focus on profits when money and valuations were easy to come by? But that thinking was always flawed. Profitability isn't unambitious; it's controlling your own destiny. It means you don't have to rely on investors for survival. It means you can focus on your unaltered vision and mission. And it means you as a founder decide the pace of growth. And once you experience it, it's hard to imagine doing things any other way. Paul Graham famously wrote about "ramen profitability" - the point where a founding team could survive without external funding. He argued this made startups more attractive to investors, showing they could get customers to pay, were serious about building valuable products, and were disciplined with expenses. Graham wrote his essay in 2009. I'd argue that we now live in a world where it's not just easier to get ramen profitable, but traditionally profitable - while also growing fast. At Linear we didn't set out to be profitable but kind of stumbled into it. We believed that to win this market we really needed to build a superior tool. The best way we knew how to do that was to keep the team small and focused. And when we launched after a year in private beta, almost all of our 100 beta users converted to paid customers. To our surprise, we realized it wouldn't take that long to become profitable if we kept the costs in check. Twelve months after launch, we hit profitability, and we've stayed profitable ever since. I don't know why hiring massive teams ever became the norm. In my own experience, small teams always delivered better quality, and faster. Maybe it's fear of missing out if you don't grow the team fast. Maybe it's investors whispering that your team is "understaffed compared to benchmarks." Being understaffed compared to benchmarks almost always should be a so