Ledgerline is a fintech company in Australia running its platform on a TypeScript backend. Over time, that backend had grown into a single monolith, which made it harder to ship features, scale individual parts of the system, and keep deployments low-risk on a live financial platform. Ledgerline came to Bacancy to break the monolith into microservices and add new platform features, all within a delivery deadline already agreed with its stakeholders. There was a catch: as the code and the new features grew, type-checking slowed the build, and slow builds drag on every change an engineer makes. Bacancy modernized the backend by splitting the monolith into independent TypeScript microservices and adopting tsgo, the TypeScript Native Preview, to speed up type-checking on the remaining work. The engagement covered the service split, the move to faster type-checking, and keeping production output unchanged on the proven toolchain, so the platform gained speed and structure without taking on new risk.
Monolith split into independent TypeScript microservices
tsgo adopted for fast type-checking in development
New platform features delivered under the deadline
Production output kept on the proven toolchain
Ledgerline's backend had grown into one large TypeScript monolith, where every change touched shared code. Teams couldn't ship or scale parts of the system independently, and any deploy carried risk across the whole platform. For a live fintech platform handling financial data, a disruptive cutover was never an option, so the work had to happen while the platform kept running.
As the codebase and new features grew, type-checking became the slow step in the build. A slow build taxes every change an engineer makes: each edit waits longer for feedback, and that delay compounds across a whole team working toward a deadline. The standard tsc type-check simply couldn't keep pace with the growing code, and each new service only added more for it to check.
As a fintech platform, Ledgerline can't trade correctness for speed. Type-safety had to stay strict end to end, because a type error in financial code can mean money handled wrong. tsgo is fast, but TypeScript 7's emit and decorator support are not production-ready yet, so leaning on it for everything would have meant shipping output the team couldn't fully trust.
The full effort, the service split, the new features, and the build speedup, had to land within a deadline Ledgerline had already promised its own stakeholders. Adopting a preview-stage tool under that kind of pressure is its own risk: tsgo updates daily, and an unexpected change to the preview could break CI at the worst possible moment, with no slack in the schedule to absorb it.
Our backend developers split the monolith into independent Node.js microservices, with each service owning a clear domain and deploying on its own. We did this incrementally, so the live platform stayed up throughout. Teams can now ship and scale one service without touching the rest, failures stay contained to a single service instead of rippling across the platform, and each deploy carries far less risk than it did against the monolith.
Our TypeScript developers adopted tsgo, the TypeScript Native Preview, for type-checking on the remaining work, where it runs faster than tsc. The build loop sped up, and engineers started seeing type errors sooner after each change instead of waiting on a lagging check. Faster feedback meant the team could iterate quickly on the service split and the new features at the same time, without the type-check holding up every commit.
We kept emit and bundling on the existing esbuild toolchain and used tsgo only for type-checking. This kept the production output identical to what the team had already proven in production, so the build got faster without introducing any new runtime risk. Type-safety stayed strict throughout, because the change made the checker faster rather than looser. In short, the platform gained speed in the build without changing a single byte of what actually ships.
We pinned the tsgo preview version in CI, so daily updates to the preview couldn’t break the pipeline mid-sprint and the the team decided when to pull a newer version after vetting it against the build first. Builds stayed predictable, with no surprise breakages eating into the timeline. Strict type-safety held the whole way through, the modernization and the new features both shipped on deadline, and the codebase is now positioned to adopt TypeScript 7 fully as it matures.
TypeScript Microservices Architecture
Fast Type-Checking with tsgo
Unchanged Production Output
Strict Type-Safety Maintained
04
Mar 2026 – May 2026
Type-checking sped up across the build loop
Faster feedback on every code change
Modernization and features shipped on time
Type-safety kept strict across all services
Production output kept on proven toolchain
Positioned to adopt TypeScript 7 fully
| Type-Checking | tsgo |
| Runtime | Node.js |
| Build & Emit | esbuild |
| Architecture | Microservices |
| Database | PostgreSQL |
| Project & Issue Tracking | JiraConfluence |
Get access to an experienced team of developers and engineers from Bacancy, handpicked to ace your goals. Kickstart within 48 hours, no-risk trial.
Years of Business Experience
Happy Customers
Countries with Happy Customers
Agile Enabled Employees