I build web applications from the interface down to the database: component-based frontends, clean REST APIs and a data model that still holds up years later – as a freelancer, remote across Europe and on-site in North Rhine-Westphalia.
Most trouble in web projects does not happen in the frontend or in the backend, but in between: interfaces nobody documented, data models bent out of shape after the fact, two teams working from different assumptions. Because I build both sides myself, those handovers disappear – the interface is designed where the business logic is written.
As a freelance senior software engineer I have spent more than ten years on business applications for corporations, mid-sized companies and the public sector. In practice that means tax consulting software with C# and Angular, a platform for pharmaceutical groups with Java Spring Boot and React, a mobility platform with Symfony and React, pharmacy software with Laravel. Projects rarely start on a greenfield, and that is exactly what I am set up for.
Which technology is used depends on your landscape, not on my favourite language. If your team maintains Java, it will be Spring Boot. If a .NET backend is already running, I continue inside it. What stays the same either way: a well-considered data model, tests where mistakes get expensive, and delivery through CI/CD instead of manual steps.
Four areas I cover individually or together – depending on where the gap currently is.
Component-based interfaces for business applications: forms with real validation, tables handling large data sets, roles and permissions reflected in the UI. Type-safe with TypeScript, accessible to use, and structured so a new screen later takes days rather than weeks.
Server-side business logic with Java and Spring Boot, C# and .NET, PHP with Symfony or Laravel, or Python with Django. Plus REST interfaces documented through OpenAPI, authentication via Keycloak or OpenID Connect, and error handling that explains in the log what actually went wrong.
A schema that matches the domain instead of one that grew by accident: considered relations, versioned migrations, indexes for the queries that really run in daily use. In existing systems, analysing slow queries is regularly part of the first work package.
Unit and integration tests for business logic, end-to-end tests for the paths your users take every day, linting and code reviews as a fixed part of the work. Delivery runs through GitHub Actions, GitLab CI or Azure DevOps – reproducible and without deployment rituals.
These are the situations I usually step into.
A process currently runs on spreadsheets, e-mails and hallway conversations. It becomes a web application with roles, a traceable history and interfaces to the systems you already have – usable step by step instead of one big bang after a year.
Software has been running for years, but every change takes longer than the last one. I work my way into the existing codebase, cover critical parts with tests and modernise where it makes the biggest difference – without a full rewrite as a precondition.
The team is good, but the roadmap is fuller than the capacity. I take on scoped features or one area, work inside your processes – ticket system, branching model, reviews – and leave behind code that matches your conventions.
Customer or employee portals that bring data together from several sources: databases, business applications, ERP or SAP systems. Integration runs over REST or OData, with clear error handling for the moments when a source system is unavailable.
No rigid process framework, but a sequence that has proven itself across many projects.
I look at what already exists: code, data model, interfaces, deployment. Then I say openly what is solid, what will cost effort and which order delivers the most value first.
Instead of a long concept paper, a thin slice through all layers appears early – from the interface through the API into the database. It lets us validate the architecture while corrections are still cheap.
Development in short cycles with regular demos. Every change goes through a pull request, tests and review, so the current state is always runnable and you do not wait for an acceptance date at the very end.
Automated delivery, documented architecture and decisions, a handover to your team. I stay available for further development, maintenance and questions if you want that.
The choice follows your existing landscape and what your team will be able to maintain afterwards.
Describe briefly what should be built or moved forward – an existing system or something new. I will come back with a first assessment of scope and sequence.