Since January 2026, we have been developing several in-house SaaS products on a shared .NET platform and are responsible for the architecture, implementation and operation. The focus is on a shared technical foundation, reusable components and operation in Azure, so that different product ideas can be built on the same platform. These include specialist functions for threat intelligence, verification processes around GitHub profiles and W3C Verifiable Credentials, as well as games server hosting with billing.
Initial situation
This project is an in-house initiative by ballmüller solutions. The starting point was the task of developing and operating several in-house SaaS products not as isolated stand-alone solutions, but on a shared platform. To make this possible, recurring topics such as authentication, wallet, billing, event processing, marketing automation, analytics and operation in Azure had to be designed so they could be used across products.
At the same time, very different specialist domains needed to be mapped on the same foundation: AI decoy personas for threat intelligence, checks of GitHub profiles with the issuance of W3C Verifiable Credentials, as well as games server hosting with billing and additional functions.
Solution
We built the IT architecture, implementation and operation of several in-house SaaS products on a shared .NET platform. This includes around 57 in-house NuGet packages as reusable building blocks. NuGet packages are internal software components that allow shared functions to be used consistently across multiple applications.
On the platform, we implemented the specialist solutions and integrated central services: authentication with Entra ID and passkeys, wallet and event sourcing, AI-supported marketing automation, analytics, a shared Azure Front Door and infrastructure as code with Bicep. Infrastructure as code means that cloud resources are defined in descriptive templates and provisioned in a traceable way. The project has been running from January 2026 to the present day and is being delivered by 1 person. Parts of the implementation include web development, database development and operation in Azure.
Result
What was delivered was a shared platform for several in-house SaaS products together with their operation in Azure. On this basis, Active Defense, Acquispect and EphemeralHost were created, each with its own different specialist requirements.
The project timeframe runs from January 2026 to the present day. The duration is still open, as the initiative is ongoing. The project is being delivered with a team size of 1.
Technology
.NET 10 and .NET Aspire are used as the foundation of the platform. Microsoft Orleans, Eventuous and FastEndpoints are used for the application architecture and implementation of business logic. Blazor WebAssembly and Blazor Server are used for browser-based user interfaces.
For operation, we use Azure Container Apps, Azure SQL, Azure Front Door and Key Vault. Azure SQL is a managed database service in the Microsoft Cloud. Key Vault is used for the secure storage of sensitive values and keys. Bicep is used for infrastructure as code, and Azure DevOps for the development and deployment process.
In addition, Azure OpenAI is used for AI functions, Stripe for billing, and Entra ID and External ID for authentication and identity management.
Why SaaS platform development is often worthwhile
SaaS platform development makes particular sense when several products or product variants are to be built on shared foundations. Instead of planning, developing and operating each system separately, a technical foundation is created on which recurring functions are built only once. These typically include sign-in, user and permissions management, billing, multi-tenancy, logging, reporting, notifications and operation in the cloud.
The advantage of this approach lies less in any single function than in the structure of the overall initiative. If shared components are cleanly separated, new products can be delivered more consistently. Decisions on security, deployment, data storage or monitoring then do not have to be made separately for each individual product, but can be prepared at a higher level. That reduces coordination effort and makes further development easier.
A clear architecture is crucial for projects like these. Architecture means how a system is divided into specialist and technical components and how those components interact. Otherwise, hidden dependencies can quickly arise, especially on platforms: a change in identity management affects user interfaces, integrations and billing; a new data source changes analytics and permissions; an additional tenant creates requirements for isolation and support processes.
A typical setup therefore consists of shared platform services and specialist modules separated from them. Platform services are technical core functions used jointly by multiple applications. Specialist modules, by contrast, represent the logic of a specific product. This separation helps keep responsibilities clear and makes changes more predictable.
Operations should also be considered from the outset. A platform is not only a development question, but also an operating model. This includes reproducible environments, traceable releases, protection of sensitive data, central logs and an incident concept. Reproducible means that an environment can be provisioned again and again with the same settings.
Anyone planning a similar initiative should therefore first identify the common ground between the products: what is genuinely suitable for the platform, what remains product-specific, which interfaces will be needed long term, and which operational tasks must be reliably covered from day one. For an initial indication of scope, the cost calculator or a project check can help.
How to structure SaaS platform development sensibly
For SaaS platform development, it is advisable to follow a process with clearly separated steps. First, the business goals, target groups, product boundaries and shared platform topics are clarified. This is not only about functions, but also about roles, tenants, data flows, billing, interfaces and later operation. Multi-tenancy means that several customers or organisations can use the same system without their data being mixed.
The next step is to create a business and technical concept. Here, the core processes are described, the responsibilities of the platform and specialist modules are separated, and the key data objects are defined. Decisions are also made on which user interfaces are required, which systems need to be connected, and how authentication, permissions and logging should be structured. Logging means that important processes are recorded in a traceable way.
This is followed by implementation in sensible stages of expansion. In platform projects especially, it is helpful to first establish the foundations on which later product functions will build. These typically include identity management, cloud provisioning, shared data and event models, basic API structures and a robust development process. APIs are defined interfaces through which systems exchange data and functions.
Regular business feedback is important. Platform projects often fail not because of missing technology, but because of unclear decisions: which function belongs in the shared foundation, and which only in one product? How far does standardisation make sense, and where would it unnecessarily constrain a specialist topic? These questions should be decided continuously and documented.
Before going live, quality assurance and operational review are needed. This includes testing core processes, checking permissions, observability in live operation and clear procedures for errors, changes and support. Observability means that the behaviour of a system can be understood through logs, metrics and alerts.
In our work, we typically structure projects like this into getting to know each other, concept and design, development, quality assurance and go-live, followed by support and further development. If you would like to prepare a similar project, you can use a non-binding initial consultation to sort out goals, risks and sensible scope at an early stage.
Typical pitfalls with platforms, data and operations
In projects of this kind, the biggest risks often lie at the boundaries between business logic, platform and operations. One frequent pitfall is generalising too early. If every conceivable product variant is taken into account from the start, the result is often overly abstract components that are hard to understand and expensive to maintain. On the other hand, defining things too narrowly is also problematic, because the same functions then end up being rebuilt in several different products.
Identities, permissions and tenants are particularly sensitive. Even small ambiguities in role models or access rules lead to a great deal of corrective work later on. Role models describe which user groups may see or carry out which functions. These rules should therefore be documented early as business decisions and not just implemented implicitly in the technology.
Another critical point is interfaces and data flows. If external systems are connected, formats, error scenarios, timing behaviour and responsibilities must be clarified properly. Interfaces often look straightforward at first in a project, but later create major effort when feedback is missing, data is incomplete or external requirements change. In event-driven architectures in particular, it is important to define which information is stored in a binding way and how corrections remain traceable. Event-driven means that changes and processes are handled and passed on as individual events.
Live operation also requires clear decisions. This includes deployment, secrets management, monitoring, incident processes and data backup. Deployment is the controlled rollout of new software versions. Secrets management means the secure handling of credentials, keys and other sensitive information. Without these foundations, a platform that works technically can quickly become a system that is very difficult to manage organisationally.
Last but not least, legal and organisational questions also play a role, such as data protection, retention, traceability of decisions or accessibility requirements. These topics should be identified early and reviewed with the responsible parties; legal assessment should be carried out by lawyers or the data protection officer.
In practice, that means a good platform needs not only good technology, but also clear business boundaries, defined operational responsibility and sound decisions on data, security and interfaces. It is precisely on these points that a sober architectural and project-level comparison is worthwhile at the outset.
Frequently asked questions
Which factors drive the costs of a SaaS platform?
The costs depend mainly on how much shared platform logic is to be built and how different the products built on top of it are. Typical factors are identity management, multi-tenancy, billing, interfaces, data model, user interfaces, cloud operation and quality assurance. Requirements for traceability, logging and security also add effort. For a rough initial indication, the cost calculator or a project check based on an existing description is suitable.
What determines the duration of a project like this?
The duration is determined primarily by the scope of the first stage of expansion. The key question is whether the initial goal is only to create a viable platform core, or whether several specialist modules are to be built in parallel. Coordination routes, available decisions, external interfaces and the depth of quality assurance also have an impact. A staged approach is usually sensible so that foundations, specialist logic and operations do not emerge in an unstructured way side by side.
Should you start with one product or plan the entire platform straight away?
In projects like these, a middle course is usually sensible. The platform should be deliberately designed from the outset, but it should not be created as an abstract construct without any concrete specialist requirement. A proven approach is to build the shared foundation around a clearly defined product or core process. That keeps architectural decisions practical, while central topics such as authentication, roles, data storage and operations are still set up properly from the beginning.
Which risks are often underestimated in SaaS projects?
Permissions concepts, data flows across system boundaries and the effort involved in operation are often underestimated. Recurring topics such as billing, notifications, logging and support also tend to look smaller at the beginning than they turn out to be later. Changes to the interfaces of external services and unclear responsibilities in the event of errors are also critical. That is why business responsibilities, technical boundaries and operational processes should be documented early and reviewed regularly.
What must the ongoing operation of a platform like this provide?
Operations must cover more than pure hosting. They typically include deployments, monitoring, fault analysis, protection of sensitive information, data backup and traceable changes. Monitoring means that outages, malfunctions and anomalies are detected at an early stage. It is also important to define how new functions are rolled out, incidents are handled and dependencies on cloud services or third-party providers are monitored. For productive platforms, this part should be planned from the outset.
