Why I Rebuilt Our Entire Platform on Microservices — and What Breaking a Monolith Actually Looks Like

Why I Rebuilt Our Entire Platform — and What That Actually Takes

When we started DnXT Solutions, the goal was simple: build the best regulatory operations platform for life sciences. Like many startups, we began with what was practical and fast — one large application, deployed as a single piece. It worked. It got us our first few customers, then five, then ten. For a while it was perfectly adequate, and it let us focus on features and on making customers successful.

As we grew, the cracks showed. What began as minor annoyances became genuine threats to our growth and, more importantly, to our customers’ trust. At around fifteen customers, with submission volumes climbing, the platform began to strain. One customer starting a heavy publishing job could slow document management down for everybody else. Any update, even a small fix, meant scheduled downtime for all customers at once. The moment that settled it was realising a fault in one part of the platform could take down the whole thing — every one of our life sciences clients, potentially in the middle of a submission.

So I made the call to rebuild. Not a tidy-up, but breaking the platform into independent parts, each doing one job. It was the right decision. It was also harder, messier and more complex than any article had prepared me for. This is not really a story about technology; it is a story about hard choices, trade-offs, and what it actually takes to build something resilient in a regulated industry.

The Decision: When One Big System Becomes the Bottleneck

In the early days, one application was a joy. Everything was in one place. Adding a feature meant changing related things together and releasing them together. It was fast and efficient for a small team, and it let us respond quickly to customers — which is what matters most early on.

As customers grew and used the platform harder, the limits became obvious. Picture a global top-20 pharmaceutical company uploading thousands of documents for a submission while a mid-size biopharma is finalising a critical publishing job. In one shared system, those two demanding jobs compete for exactly the same resources.

• No way to grow one part alone. One customer’s publishing job would visibly slow another customer’s document browsing. That is not acceptable. We needed to be able to add capacity where it was needed, not everywhere at once.
• Every update meant downtime for everyone. However small the change, the whole thing had to be restarted. In life sciences, where submissions have hard deadlines and customers operate across every time zone, there is no quiet hour when that is harmless.
• One fault could stop everything. A problem in the workflow area could bring down the entire platform. A single point of failure like that is a risk you cannot leave in place.
• Everything got slower to change. Even well organised, the system grew vast. New developers faced a steep climb, and every change carried a growing risk of unintended consequences somewhere else.

The pain was real. Our ability to serve a growing customer base reliably was being limited by decisions we had made years earlier. This was not about technical elegance — it was about business continuity, customer satisfaction, and our reputation in a demanding industry.

“The pain was real. Our ability to serve our growing customer base effectively and reliably was being compromised by decisions we had made years earlier. It wasn’t about technical elegance; it was about business continuity, customer satisfaction, and our reputation in a demanding industry.”

What We Actually Built

Deciding to break things apart was the easy half. The next question was what the pieces should be. We made pragmatic choices based on our team size, our regulatory requirements, and the outcomes we wanted — not on what was fashionable.

We ended up with eight or so independent parts, each owning one area:

• Information — storing and retrieving everything the platform holds
• Sign-in — authentication, permissions and single sign-on
• Customer configuration — the settings specific to each organisation
• Audit trail — capturing a tamper-proof record of every significant action, which 21 CFR Part 11 makes non-negotiable
• Search — indexing documents so they can be found quickly
• Workflow — running approvals, task assignment and the steps of a regulatory process
• Files — secure storage, versioning and retrieval of every document
• AI — the controlled route for classification, extraction and everything else AI does

Four decisions shaped the result:

• Each part is released on its own. A fix to sign-in no longer requires restarting everything, and it cannot affect workflow. This was the single biggest win for reliability.
• We chose managed hosting over the most powerful option. There is a well-known platform for orchestrating this kind of architecture, and we deliberately did not use it. Our team is small, and its complexity was not justified. We picked a managed Azure service that gives us automatic capacity and controlled release of new versions without needing people dedicated to running the infrastructure.
• One database, with each customer strictly separated inside it. Data separation is paramount in a platform serving several life sciences companies. Each customer’s information sits in its own separate space, giving strong separation while letting us operate one database efficiently.
• The parts talk to each other in the simplest way that works. We considered a more sophisticated messaging approach and chose direct request-and-response instead. For our team size and the way our features actually behave, it was simpler to build, simpler to debug, and much easier to follow when a single user action passes through several parts of the platform.

The result addressed the original problems directly. Capacity can be added exactly where it is needed, so a heavy publishing job no longer slows down document browsing. Updates stopped requiring downtime. And the consequence of any single fault shrank dramatically.

The Hard Parts Nobody Mentions

The vision was clear. Actually getting there was a brutal education, and these are the lessons the diagrams never show.

• Keeping information consistent across separate parts. Easily the hardest problem. When everything lived in one place, a single operation either fully succeeded or fully failed. Once files, information, search and audit are separate, a document upload touches all four — and you have to decide what happens if the third one fails. Elaborate coordination schemes sound good and rarely work in practice: too complex, too slow, too poorly supported. We accepted that some things settle a moment later rather than instantly, and built proper retrying and clean unwinding for anything that fails partway. This is a category of complexity that simply does not exist in one big system.
• Diagnosing problems in production. When everything was one application, you could follow a user’s request through a single log. Now a single request might pass through five separate parts. So we tag every request with a unique reference that travels with it, which lets us reconstruct its entire journey afterwards. Without that, diagnosing anything would be guesswork.
• Managing settings. This sounds trivial and quickly became its own problem. Eight parts, each needing a dozen or more settings — database connections, credentials, addresses, logging levels — across development, testing and production. That is approaching a hundred values, and one typo makes something fail quietly. We moved to managing them centrally, but the early pain of doing it by hand was considerable.
• Team size. This approach usually assumes larger teams, where one team owns one area. We had four developers, so each person ended up owning two or more areas. That meant constant context switching and a heavier load on each person. It built genuine breadth, and it also meant deep expertise in any one area was harder to maintain. Any small team going this route should go in with their eyes open about that.

Lessons for Founders

Having been through it, I have some strong opinions for other founders, particularly in regulated industries:

• Do not break things apart until the pain is real. This is my number one piece of advice. Doing this too early is worse than a well-organised single system. If yours is still serving customers well, and you are not hitting real limits, do not do it because it is fashionable. A well-designed single system scales remarkably far. Break it up when the business pain is undeniable.
• Start with the parts whose demand varies most. Do not attempt everything at once. Find the areas with the most unpredictable load. For us that was AI, which comes in bursts, and file handling, which deals with large uploads. Separating those first taught us what we needed to know without risking everything.
• Get your visibility in place first. I cannot stress this enough. Before separating anything, make sure you can see what is happening — centralised logs, monitoring, and the ability to follow one request across everything it touches. Without that you will be working blind precisely when you can least afford to.
• Keep the pieces large. The temptation is to break things into the smallest possible units. Resist it, especially with a small team. Every separate part brings its own release process, its own settings and its own overhead. Aim for pieces that own a meaningful chunk of the business. It is far easier to split something later than to merge many small things back together.

Doing This in a Regulated World

Life sciences adds a further dimension to every architectural decision. Compliance, and 21 CFR Part 11 in particular, does not care how you build your software. It cares about outcomes.

• Part 11 does not mandate an architecture. It requires robust audit trails, strict access control, data integrity and secure electronic signatures. Having dedicated parts of the platform responsible for audit and for sign-in actually made those easier to build and enforce consistently, because there is exactly one place where each is done.
• Separating customers is not optional. In pharma, keeping one client’s information away from another’s is a fundamental requirement rather than good practice. Giving each customer their own separate space within a shared database was a direct response to that: operational efficiency, with the strong separation regulated customers require.
• Managed hosting was the right trade. Choosing a managed service over the most powerful available option let us get automatic capacity, secure connections and controlled releases without needing a dedicated infrastructure team. For a lean operation delivering enterprise-grade reliability, that is the sweet spot.

The rebuild was transformative. It was not easy, and we learned some hard lessons. But the result is a platform that scales with the demands of the life sciences industry, and the experience has shaped not only how we build our own products but how we advise consulting clients facing the same decision.

See It in Action

Curious how this works in practice? We would be happy to walk you through it and discuss how these principles apply to your own challenges. Contact us today to schedule a conversation.