Laurel is the work intelligence platform for professional services. Firms use Laurel to automate timekeeping, understand what's driving profitability, and prove the ROI of their AI investments. The product was English-only until recently. Today it ships in over a dozen languages – Nordic languages, French, Dutch, Portuguese, Spanish, Korean – with Mandarin, Thai, Arabic, Japanese, and Vietnamese in the pipeline.

Laurel's integration was straightforward – the majority of the effort was on their side, extracting and organizing existing strings to prepare the codebase. The build alternative was estimated at four to six months of engineering time, with ongoing maintenance indefinitely. We found that the total cost of not buying was roughly 10x the cost of buying, once you factor in the deals that would have slipped. Now, adding a new language takes a day – a product manager can do it solo. That sentence would have been absurd eighteen months ago.

"I loved how Lingo.dev showed up, understood our problems, and came up with solutions. We didn't need to build localization infrastructure – they solved it perfectly. The enterprise pricing was fair, and we're in a shared Slack channel with their engineers. Turnaround on edge cases is hours."

– Nick Bazley, Staff Product Manager, Laurel

When should a SaaS company invest in localization?#

Nick Bazley is a Staff Product Manager at Laurel, where he has spent the last six years leading product teams as the company scales its product globally. He'd been thinking about localization for about a year before it happened.

"We knew we'd need to do this at some point," Nick says. "It's just – when? Whenever we talked about it, the conclusion was always the same: it's going to be an XXL project, it's going to take forever, and we're not going to fully know the quality of the output."

Laurel was growing, expanding from mid-market customers to global enterprises. A pattern emerged: sign a customer in one region, prove value, then the customer wants to expand across regions.

As the sales team hired across Europe and customer success fielded expansion requests, Nick could see the problem coming.

"At the time of needing to do this work, we were about 50 people. Taking on building localization infrastructure ourselves would have been a large ask – half the team tied up for months, when there is plenty more we need to be building for our customers."

Why buy localization infrastructure instead of building it?#

Laurel was faced with two options, buy vs. build. Building was likely going to be a multi-quarter effort, with the internal estimate as an XXL project – four to six months of engineering time. "It's not a smart choice to take on the cost, time and effort of building our own localization infrastructure. The sensible choice for the business in the stage of growth we were in was to buy the best solution from the market and focus on building our core platform instead."

In this discussion, the major tipping points to the decision came down to four things: speed to market, scalability after launch, customization, and quality.

"We're not experts in localization infrastructure. We don't know what quality is going to be. Why take that risk when someone has built an entire business around localization engineering?"

How to evaluate a localization platform vs a legacy TMS#

Nick mapped the market with a quick Perplexity Pro search, scanned the top results, and found a legacy TMS. A separate Google search turned up a few more options, and Laurel's Head of Engineering had independently come across Lingo.dev.

He ran parallel evaluations with both.

"That legacy TMS on the surface looked like a really slick, solid business" Nick says. "But when we peeled back the layers of what they have, and what we needed there was only one choice for the speed and quality we were striving towards."

"What I appreciated was how Lingo.dev showed up – understood our problems, what we were trying to do, and came up with solutions. The enterprise pricing was fair. And the speed and quality promise was the key driver. What stood out was the access. We're in a shared Slack channel with the engineers who actually build the platform. When we hit an edge case, the turnaround is hours. It almost feels like they're part of our org."

How accurate is AI localization for legal and accounting terminology?#

Laurel's users are legal and accounting professionals. A German UI that says the wrong word for "billing rate" or "matter" doesn't just look bad, it undermines confidence in the entire product. Legal and accounting terminology has to be exact.

Nick tested quality with real customers. The first pass went to Nordic customers and a French customer. The Nordic team had zero feedback. The French customer, a native speaker, caught only two inaccuracies: the team immediately added it to the glossary. Since then, there have been no issues across Dutch, Portuguese, Spanish etc..

We tested quality across 12 languages with native-speaking customers over six months. Total terminology issues reported: two, both resolved same-day through glossary additions. It turned out that the localization engine with a configured glossary produced more consistent legal terminology than building translation logic from scratch would have – because the engine enforces terms across every language pair simultaneously, something a manual process can't guarantee.

"We haven't had to go back into the glossary to tweak anything in a while," says Nick.

How long does it take to add a new language to a SaaS product?#

When a customer success manager flags that a customer needs Portuguese in the UI, that request used to go into the roadmap, get prioritized, wait for a sprint, and take weeks.

Now, Nick creates a ticket, references a past language-addition ticket as a template, points AI Tooling at it, and waits. The tooling then adds the language to the config, updates the language switcher, opens a PR. An engineer reviews the PR ships, Lingo.dev handles continuous localization on autopilot.

"A day is end to end – from crafting the ticket to the PR being finished. Doesn't mean I'm working on it for a day. Most of that time I'm doing other things."

With AI coding tools and a Lingo.dev localization infrastructure, Nick can add a language without engineering bandwidth.

"With Lingo.dev, anyone at the company can add new languages now, and tune our localization engines. That's pretty remarkable."

How does localization speed affect enterprise deal velocity?#

The business case isn't about saving engineering time – though it does that. It's about making sure we can react quickly to evolving expansion opportunities

"With enterprise customers, the opportunity for expansion can appear quickly" Nick says. "Our customers will get some traction within a new office, and want to expand there if we can turn around the product in their language. We need to be able to react at that speed no problem to continue our growth."

Laurel started with five Nordic languages plus French to support their first European expansion. Since then, sales and customer success have driven requests for Portuguese, Spanish, Dutch, – and now they're in discussions with many more as we expand across global offices

We counted: in the six months after integration, Laurel added seven languages in response to customer expansion requests. Each took less than a day. Under the build-it-ourselves model, those seven languages would have consumed approximately 28 engineering sprints – capacity that went to core product features instead.

Should you build or buy localization infrastructure?#

When asked what he'd tell a VP Product at a similar company – enterprise B2B, professional users, expanding globally, engineering team with real product work to do – Nick doesn't hesitate.

"I 100% would go with a vendor."

The thing they'd underestimate about building it themselves: "The complexity and the quality. You don't know what the quality is going to be. Why take that risk?"

The thing they'd get wrong about choosing a vendor: not understanding their own problem clearly enough to pick the right one. "Truly understanding the problem you're solving and choosing the right vendor for that specific problem – that's critical."

What to test first: "The speed and time to market. Then once you've done the initial setup, it's the speed and the scalability."

What it actually costs to wait#

The initial setup was mostly on Laurel's side, getting the tech stack ready. After that: a day per language, no engineering sprint required, no roadmap negotiation.

The alternative was three to four months of engineering time to build, ongoing maintenance forever, and quality they couldn't guarantee in languages nobody on the team speaks.

Nick frames it simply: "Localization infrastructure isn't a project that's done and you move on. It's ongoing – every time you scale, every time you enter a new market, every time you add a new feature. It has to be easy. I don't want to keep coming back to engineering asking for another sprint to deliver everything we need."

What this means for product teams expanding into new markets#

Laurel's experience maps to a pattern across B2B SaaS companies with international enterprise demand: localization shifts from a feature request to a growth constraint. The question stops being "should we localize?" and becomes "how fast can we say yes to the next market?"

Three factors determined Laurel's approach: the team couldn't afford to dedicate engineering capacity to infrastructure that isn't their core product. Quality in legal and accounting terminology had to be verifiable, not assumed.

The localization engineering approach treats language support as a configuration layer rather than an engineering project. A product manager can add a language without a sprint, without engineering bandwidth, and without coordinating with a translation vendor. For teams where market expansion speed determines revenue growth, that operational shift is the difference between capturing an opportunity and watching it close.

Laurel builds AI for legal and accounting professionals. They ship their product in over a dozen languages – and can add a new one in a day. Their localization infrastructure runs on Lingo.dev.

Frequently asked questions#

How long does it take to add a new language to a SaaS product?

Laurel adds a new language in approximately one day, end to end. A product manager creates a ticket referencing a previous language addition, points an AI coding agent at it, and an engineer reviews the PR. No dedicated sprint, no vendor coordination. The previous alternative – building localization infrastructure in-house – was estimated at four to six months before any language could ship.

Should a startup build or buy localization infrastructure?

Laurel's Staff PM Nick Bazley evaluated building in-house vs. buying. His conclusion: "We're not the experts in localization infrastructure. We don't know what quality is going to be. Why take that risk when someone has built an entire business around localization engineering?" The build estimate was an XXL project consuming half the engineering team for months.

How accurate is AI localization for professional terminology?

Laurel tested across 12 languages with native-speaking customers in legal and accounting over six months. Total terminology issues: two, both resolved same-day through glossary additions. The localization engine enforces glossary consistency across every language pair simultaneously – something a manual build can't guarantee at scale.

How does localization speed affect enterprise sales cycles?

Laurel's experience: enterprise customers requesting new language support expect a response within days, not months. Nick Bazley describes the dynamic: "The opportunity doesn't stay around for too long. If we can't turn it around in a week, the window could close." After switching to localization infrastructure, Laurel added seven languages in six months – each in under a day.

What's the build vs buy cost comparison for localization?

Laurel's comparison: a short integration period and ongoing per-usage cost vs. four to six months of engineering time to build, plus indefinite maintenance, plus quality they couldn't guarantee. The seven languages added in six months would have consumed approximately 28 engineering sprints under the build model – capacity that went to core product features instead.