A company asked us to develop standalone IT sub-projects while also working within an existing team on a full-stack solution. The focus was on Angular development for the frontend, scalable REST APIs, solution design and requirements analysis in a hybrid database environment, and support from the initial architecture sketch through to deployment.
Starting point
A company was looking for support with the independent development of IT sub-projects and with contributing to an existing team. The task covered full-stack work including functional and technical solution design, requirements analysis and implementation in an environment with both relational and document-oriented data storage. This called for experienced input from the initial architecture sketch through to deployment.
Solution
We took on the independent development of IT sub-projects while also contributing within the existing team. Our work ranged from the initial architecture sketch, solution design and requirements analysis in a hybrid database environment to the development of scalable REST APIs and frontends. We also developed test strategies for both backend and frontend. The project ran from July 2024 to September 2025 with a team of 5. In terms of content, the work therefore covered web development as well as interfaces and data storage.
Result
We delivered contributions to IT sub-projects in a full-stack environment, including frontend development, REST APIs, conceptual work in a hybrid database environment, and test strategies for backend and frontend. The engagement included both collaboration within the existing team and independent development work. The project ran from July 2024 to September 2025.
Technology
Angular and DevExtreme were used for the frontend. .NET with C# and REST-based ASP.NET were used for backend and interface development. Entity Framework supported data access. PostgreSQL and MongoDB provided the hybrid database environment combining SQL and NoSQL. Docker, Kubernetes and Helm were used for deployment and the operating environment. Kubernetes is a platform for managing containers, meaning self-contained application units for consistent operation.
Why Angular development is a good fit for applications like these
For browser-based business applications, Angular development is often a suitable foundation when interfaces need to grow in a structured way, different views need to remain consistent, and the application works closely with interfaces. Angular is a framework for building complex web interfaces with clear rules for structure, data flow and reuse. For clients, this is particularly relevant when requirements go beyond a single screen and processes, roles, data views and validations all need to be brought together.
In projects like these, a clearly structured frontend helps prevent new requirements from being added to the application in a disorganised way. This applies, for example, to forms, lists, filters, approvals or business checks. When interfaces are planned in this way, business logic, presentation and API integration can be cleanly separated. API stands for a defined interface through which frontend and backend exchange data. This is especially important when several sub-projects are running in parallel or an existing team is working together with additional contributors.
There is also another factor: business applications often need to bring together data from different sources. In that case, a user interface alone is not enough. What matters is how it works together with the backend and the data layer. A relational system is typically suited to highly structured data and clear relationships, while document-oriented databases handle changing data structures more flexibly. When both are combined sensibly, the result is a hybrid database environment. This is precisely where it helps if the frontend, API and data model are considered together from the outset.
The organisational framework also often speaks in favour of this approach. Anyone wanting to deliver sub-projects independently while also working within existing structures needs architecture decisions that can be followed, interfaces that are easy to understand, and components that can be tested. In this context, testability means functions can be checked in a targeted way before changes go live. For companies and public-sector clients, this reduces coordination effort and makes further development easier.
If you are planning a similar project, it is usually worth looking at requirements, data flows and interface logic at an early stage. For an initial assessment of your project, you can use the project check.
How full-stack projects like these typically proceed
Projects like these do not usually begin with programming, but with a shared understanding of the task. The first step is to clarify which business processes need support, what data already exists, which roles will work with the system and where interfaces to other applications are in place. This early clarification is especially important in full-stack projects because frontend, backend and data storage are closely connected. Full stack means that the work covers all key layers of an application, namely the interface, server-side logic and data access.
This is usually followed by a conceptual phase. During this phase, the architecture is outlined at a high level, responsibilities between components are separated and decisions on interfaces, data models and the operating model are prepared. An architecture defines how the parts of a system work together. This phase often also reveals whether a hybrid database model makes sense, how REST APIs should be structured and what the requirements are for testing and deployment. Deployment refers to the controlled process of bringing an application into its target environment.
Only after that does the actual implementation begin. A typical approach is step-by-step development with regular coordination, where requirements are not all delivered at once but in functionally meaningful sections. Where an existing team structure is already in place, there is the additional need to ensure that new contributions fit with established ways of working, quality standards and technical foundations. Clear agreements on responsibilities and handovers are important for this.
Quality assurance should run in parallel with development. This includes tests for frontend and backend, but also checks on data flows, error scenarios and interface behaviour. Quality assurance does not just mean finding defects; it also means safeguarding requirements so that changes remain manageable. This is a key point, especially in systems with multiple data sources and different interfaces.
Before go-live, operations and maintainability come to the fore. At that stage, the focus is on configuration, delivery, monitoring and the question of how new versions can be released safely. In cases like these, we provide support as needed from development through to hosting and operations. If you would first like only a rough initial assessment of your project, you can also use the cost calculator or request a non-binding initial consultation.
Typical pitfalls with interfaces, data and operations
In projects involving a frontend, REST interfaces and multiple data sources, risks rarely arise in just one place. They often lie at the transitions: between the business process and the interface, between the interface and the API, or between the data model and actual use. REST describes a common approach to web interfaces in which functions are provided via clearly defined endpoints. If these transitions are clarified too late, the result is rework, unclear responsibilities and avoidable coordination loops.
A typical stumbling block is an unclear data model. If it is not decided early on which information belongs in a structured relational database and which should be handled more flexibly in a document-oriented solution, the application logic becomes unnecessarily complex. This affects not only storage, but also search, validation, evaluation and adaptability. It becomes especially critical when business terms are used differently across teams or when the same data differs between multiple locations.
Interfaces are another issue. If APIs are designed only from a technical perspective and not from the point of view of actual workflows, the result is often too many calls, complicated dependencies or error situations that are difficult to understand. For clients, it is therefore important that business requirements and technical structure are considered together. This also includes the question of how existing systems are integrated and how incomplete or contradictory data is handled.
In operations, risks often lie in delivery and in being able to trace changes. Container technologies and orchestration can help here if they standardise operations. A container bundles an application with its runtime environment; orchestration manages many such units in an orderly way. What matters, however, is not the tool alone but a clear process for versions, configuration and error analysis.
Topics such as permissions, logging, data protection and accessibility should also be identified early on. Whether requirements in these areas have been met must, however, be checked in each specific case with the responsible specialist bodies, such as legal advisers or data protection officers. For the technical foundation of such projects, database development, interfaces and data migration are usually just as relevant as cleanly planned frontends and APIs.
Frequently asked questions
What do the effort and costs of a project like this depend on?
The effort is usually shaped by the business complexity, the number and quality of interfaces, the data model, operational requirements and coordination with existing teams. One particularly relevant factor is whether a system is being built from scratch or has to be integrated into an existing architecture. For an initial estimate, the cost calculator is suitable; if you have a description or a specification document, a project check is often the better starting point.
How do you plan the timeline of a full-stack project realistically?
A realistic plan is based on the business scope of the individual tasks, dependencies on third-party systems and the amount of preparatory work already done. In practice, clearly defined deliverables, early decisions on architecture and data storage, and regular coordination are all helpful. Uncertainty often arises not from the programming itself, but from open requirements or late changes. That is why planning should consider technical and organisational points together.
What should collaboration between the client and the development team look like?
A proven approach is collaboration with clear points of contact, short decision-making paths and regular business feedback. It is important not only to collect requirements, but also to prioritise them and describe them in a way that others can follow. When contributing to existing teams, responsibilities and quality standards also need to be aligned early on. This makes it easier to combine independent sub-projects and joint work without knowledge or decisions becoming dependent on individual people.
What risks are typical in Angular development with APIs and multiple data sources?
Typical risks include unclear business terminology, inconsistent data models, interfaces that are difficult to change and missing test concepts. If frontend, backend and data storage are planned separately, they often do not fit together cleanly later on. That is why data flows, error scenarios and responsibilities should be discussed early. For topics such as data protection or accessibility, specialist review by the responsible bodies is also required; technical implementation alone does not replace that review.
What needs to be considered for the later operation of such a system?
Important points are a reliable delivery process, traceable configuration, monitoring and clear arrangements for changes. Equally relevant is how logs, meaning technical records, are used for troubleshooting and operations, and how new versions can be released in a controlled way. In container-based environments, operations and development should work closely together. If you would like to discuss a similar project, a non-binding initial consultation with ballmüller solutions is a sensible next step.
