From .NET Enterprise Systems to a Global SaaS: What Transferred and What Didn't

The instinct that transferred directly: layer separation

I've written before about how I structure .NET backends with strict layer separation — Domain, Application, Infrastructure, Presentation, dependencies always pointing inward. That instinct transferred to Contractly Pro without modification. A SaaS serving freelancers in ten languages across multiple countries has just as much reason to keep business rules independent of infrastructure as an insurance claims system does — arguably more, because the infrastructure (payment providers, e-signature vendors, tax rules per country) is guaranteed to keep changing as the product grows into new markets.

When I added a second payment provider for a specific region, the change touched exactly one project in the solution. That's not a coincidence — it's the direct payoff of keeping Infrastructure as the only layer allowed to know about a specific vendor's SDK.

The instinct that had to change: speed of iteration

Enterprise systems optimize for correctness and stability over speed of change, because the cost of a mistake — an insurance claim processed incorrectly, a compliance breach — is severe, and the user base is captive (employees use the internal tool because it's the internal tool). A SaaS with freelancers who can cancel their subscription and switch to a competitor within minutes has a completely different risk profile. Being slow to ship a fix or a requested feature is its own kind of failure.

That meant deliberately relaxing some enterprise habits: fewer approval gates before a change ships, smaller and more frequent releases instead of large quarterly ones, and accepting that some polish gets added after a feature ships to real users rather than before. The architectural rigor stayed. The release process got dramatically faster.

What multi-country, multi-language actually demands

Enterprise software I built was usually single-tenant or single-market — one insurer, one set of business rules, one country's regulations. Contractly Pro supports 10 languages and has to adapt to different countries' contract and invoicing norms from day one. That pushed a few decisions that wouldn't have mattered in my previous work:

• Locale and currency formatting live at the edges (Presentation), never assumed inside Domain logic
• Compliance rules (like mandatory invoice fields) are modeled as pluggable per-country policies, not hardcoded conditionals scattered through the codebase
• Every piece of user-facing text is externalized for translation from the first commit, not retrofitted later

"The architecture patterns that kept a single insurer's claims system maintainable are the same ones that let a solo founder support ten languages without the codebase collapsing under its own conditionals."

The real lesson

Good architecture isn't industry-specific. The discipline that kept enterprise systems maintainable — clear boundaries, dependencies pointing one direction, infrastructure kept firmly out of business logic — is exactly what let one person build and maintain a product serving freelancers across multiple countries without drowning in complexity. What changed wasn't the principles. It was how fast I was willing to move on top of them.

Try Contractly Pro free →