When Low-Code Hit the Ceiling, We Built Our Own Ladder

What we built on Power Platform

Low-code platforms are everywhere in enterprise software right now, and for good reason. They let developers and non-developers alike turn an idea into a working business system without a large IT footprint. That pitch is genuinely appealing, and for a while, it worked for us.

But software development is more than the product it delivers. This is the story of how our team moved from Microsoft Power Platform to an open-source stack, and what I learned as a junior engineer in the middle of it.

During my first month at Future Analytics, I was handed Power Pages and asked to build a client web application. It wasn't my first time on a low-code platform, but it was still a real challenge. The client wanted to view their Power BI reports inside a web app and wanted us to keep adding product features over time.

Power Pages got us there. I built the authentication flow, embedded the Power BI reports, and assembled features using Azure Functions, Microsoft Dataverse, and Power Automate. Before I knew it, we shipped the first version to the client.

I want to be fair about this: it worked. For getting a functioning, authenticated, report-serving application in front of a client quickly, the platform did its job.

Where it started to break down

The first thing I noticed was that “low-code” didn't mean “less work.” I still had to configure everything by hand, research which Power Platform service solved which problem, and learn an Application Lifecycle Management model specific to that ecosystem. The learning curve didn't disappear; it just moved somewhere less transferable.

The harder problems came as the client's product grew:

Testing barely existed. There was no meaningful way to unit-test a component or assert that a calculation still produced the right number after a change. Regressions surfaced when someone noticed them.

Collaboration was painful. Power Platform artifacts can be pulled into source control, and Microsoft has real ALM tooling for it. But the diffs are low-signal, merge conflicts on generated files are close to unresolvable in practice, and a single deployment to one environment took almost an hour because of the app's size. Code review—the actual practice of one engineer reading and improving another's work—never really took hold.

And eventually, we hit a ceiling. As we moved from displaying reports to building genuine product features around them, we kept running into the platform's boundaries rather than our own. At some point the question stopped being “how do we do this in Power Platform?” and became “should we be doing this in Power Platform at all?”

That's the realization I'd pass on to anyone in the same position: the problem was never that low-code was bad. It was that we had outgrown what it was designed to do.

What we rebuilt

We researched an architecture that fit the client's goals, then rebuilt the application from the data layer up.

The data side turned out to matter more than the UI. We built ingestion pipelines with dlt pulling from the client's data sources, landing into ClickHouse, a columnar analytics database. dbt transforms that raw data through 456 models with 39 data tests attached. On top sits Cube, an open-source semantic layer—104 schema files that define every measure once, so a metric means the same thing everywhere it appears.

That last part is the piece I underestimated. Defining a measure in exactly one place, and having every app consume that same definition, solved a class of “why do these two numbers disagree?” problems we used to chase manually.

The application layer is Next.js and React in TypeScript, with:

• Tailwind CSS and shadcn/ui for the interface
• Recharts for charts, with custom drill-through
• NextAuth.js and bcryptjs for authentication
• Vitest and Testing Library for unit and component tests
• Playwright for end-to-end tests
• Nx to manage the monorepo

What actually changed

The difference shows up in numbers I can point at.

We now have 403 unit and component test files in the main app and 95 in the second, plus 14 Playwright end-to-end specs across both. Every pull request runs lint, typecheck, build, and the full affected test suite before anyone can merge. A broken calculation fails CI, not a client demo.

The reuse story surprised me most. When we built a second application—a portal for one of the client's machine partners—it shared 29 of its 30 dependencies with the first. The foundation was already there. The first commit on that second app landed about four weeks after the first app moved into our monorepo.

Between the two apps we're now running 104 pages, 146 API routes, and 367 components, maintained by our team across more than 4,000 commits. None of that would have been reviewable, testable, or safely parallelizable on our old setup.

What it cost us

I don't want to write the version of this post where open source solves everything, because that isn't what happened.

We took on operational work Microsoft used to do for us. Kubernetes, Terraform, database backups, container image promotion between environments—all of that is ours now.

We rebuilt things we used to get free. Dataverse gave us row-level security out of the box. We now implement access control ourselves, in code we have to keep correct.

Dependencies need tending. Thirty-seven packages on fast-moving major versions means somebody owns upgrades and security patches. That's a permanent, recurring cost.

And we didn't fully escape our vendor. We still use GitHub for CI/CD and Azure for hosting. Our authentication still touches Microsoft Entra, and one of our ingestion pipelines reads from Outlook. We left the Power Platform—we did not leave the Microsoft ecosystem, and I think it's more honest to say so than to claim a clean break.

What we actually traded was a capability ceiling for an operational cost. For the product we were building, that was the right trade. It won't be for everyone.

What I took from it

Software engineering is something to be creative about. It pushes you to research and analyze, and to bring judgment not just to the product you ship but to the architecture underneath it.

Software development is more than the product it provides. It also tells the story of how it was made. Every film needs screenwriters, producers, and directors; every application needs an architecture, a test suite, a deployment path, and someone willing to argue about all three.

That's the part I didn't expect to enjoy. Eight months in, the most interesting problem I've worked on wasn't a feature—it was deciding what to build it on.