Why We Build ModularPlatform as a Stable Foundation, Not a PoC

Most products I have worked on started as a proof of concept. Someone needed to show quickly that an idea worked, so a small app was thrown together to do that. And then it was not thrown away. It went into production, the first customer came, then the second, and suddenly that PoC was being chased for years. Technical debt, outages, vendor lock-in that nobody consciously signed up for.

ModularPlatform grew out of what I kept seeing fail. We build it the other way around: first a clean, production-ready foundation, then functionality on top. It is an internal SolutionBox project and it is still in progress — I write "we are building", not "we have finished". But I want to explain why we do it this way, because the reason comes from experience, not from marketing.

What kept breaking in my hands

I will start with a story, because it makes the rest make sense.

At TrafinOil I worked on e-invoicing for KSeF — the Polish government system for electronic invoices. It is asynchronous, rate-limited, occasionally unavailable, and has its own state. When you integrate it naively, you get a fire-and-forget pipeline: send the invoice, hope it arrived, move on. That is exactly what was there before. We forensically recovered 15,141 documents that the silent pipeline had lost. Nobody knew, because nothing reported an error — the documents were simply never stored anywhere.

I rewrote it as a long-running stateful workflow: idempotent submission, retry with exponential backoff, rate limiting, reconciliation, UPO confirmation, audit log. Today it is verified in production on more than 40,000 documents, 100% delivered. The difference between the two versions is not that the second one is "better written". The difference is that durability, idempotence, and observability were there from the start, not patched in after an incident.

I saw the same thing elsewhere from a different angle. Atlas Copco had a SAP data pipeline where a single SQL script had grown to 15,000 lines and the runtime had stretched to several days. Refactoring to an event-driven approach on Azure Functions cut it to ~4 hours from the EU and brought that SQL down to 3,000 lines — 80% less. Again: the bottleneck was not in the language or the framework, but in the fact that the foundation was built ad hoc and nobody designed it for what was coming.

That is the problem ModularPlatform addresses. When a company starts every product from scratch, it repeatedly builds the same infrastructure: multitenancy, payments, messaging, observability. And every time it builds it in a hurry, because the customer wants to see a feature, not an outbox pattern. So every time it ends up with the same fragile start.

What "stable foundation" actually means

A stable foundation is not an adjective. It is a list of decisions made before the first business feature is written. Here is what we build into ModularPlatform and why.

Clean dependencies, enforced mechanically. A modular monolith only makes sense when modules genuinely do not reach into each other's internals. Most "modular" codebases promise this in the documentation and then nobody enforces it — within six months it becomes a tangle. We enforce it with ArchUnitNET tests: when someone introduces a forbidden dependency between modules, the build fails, not production a year later. A boundary enforced by a test holds. A boundary enforced by goodwill does not.

Durable messaging from day one. Communication between modules and with the outside world runs through Wolverine — outbox, inbox, sagas. That is exactly the machinery I had to bolt on manually to KSeF after the incident. When you have it from day one, no message silently disappears between "saved to DB" and "forwarded on". Those two operations either both happen, or neither does.

Multitenancy and data isolation. Tenant isolation via Postgres row-level security. That means the separation of customer data is not guarded by application code that can have bugs, but by the database itself. When a developer makes a mistake and forgets a tenant filter in a query, RLS still will not let them see another tenant's data. This is exactly the kind of thing that gets deferred to "we'll fix it later" in a PoC and later becomes a security incident.

Security and GDPR by default. Crypto-shred deletion for GDPR — when a customer has the right to be forgotten, we delete the key and the data becomes unreadable, rather than hunting down copies across backups. Audit log and isolation go hand in hand with this. You cannot credibly bolt this on later; either it is in the foundation or it is not.

Payments. Stripe integration in the foundation, because a paid product needs billing and most teams discover this only once they already have a customer and no billing system.

Self-healing and multi-machine operation. The foundation is designed to run multi-machine and to recover itself after a node failure, not to require someone to restart it manually at three in the morning.

Observability from the start, not after the first outage. Structured events on state transitions, so you can see what is happening and where. This is the lesson from KSeF written into the foundation: a silent LogWarning without an alert is debt, not monitoring. A pipeline that lost 15,141 documents is expensive mainly because nobody saw it in time.

The frontend runs on Next.js 15 and React 19; the backend is a .NET modular monolith. Monolith by design — for read-heavy applications, a clean modular monolith with enforced boundaries is usually more sensible than microservices, which add operational complexity that most products do not need.

Why this saves clients time and money

This is not an academic exercise in code cleanliness. It has three concrete consequences for anyone who hires us.

Faster time-to-market. A new product does not start by building multitenancy, payments, messaging, and observability. That already exists and is tested. You start straight with what is unique about the product. That is weeks to months that do not have to be spent on infrastructure that everyone needs anyway.

No vendor lock-in. The source code stays with the client. ModularPlatform is not a SaaS that clients lock themselves into and pay for forever. It is a foundation on which their product is built, and that product is theirs. If they decide to continue on their own or with a different team, they have normal .NET code in their hands, not a black box.

Lower cost of catch-up. This is the least visible line item and the most expensive one. When a product launches from PoC to production without a proper foundation, the cost is not immediate. It arrives a year later, in the form of outages, data losses, security incidents, and refactors that cut across the entire application. I paid that bill in other people's projects often enough to want to spare clients from it.

I do not want to oversell this. ModularPlatform is internal and in progress — we are still working on it and some parts are further along than others. It is not a finished product with a clickable demo. But the philosophy behind it is proven in real projects where I saw what happens when it is missing: lost documents, multi-day runtimes, security deferred to "later".

Most teams ship a PoC without a foundation and spend a year catching up. We go the other way. Foundation first, then everything else. Not because it is more elegant, but because I have seen enough times what the other approach costs.