Web apps that do real work — not just look modern.
Customer portals, SaaS MVPs, B2B platforms, internal tools and dashboards — built in Germany, with clean architecture, clear roles, a resilient data layer, and an honest path from MVP to a platform that holds up. Founder-led, from Krefeld.
- Auth · roles · API · DB · CI/CD under one roof
- Next.js · TypeScript · .NET / Node · PostgreSQL · Azure
- Based in Krefeld · Germany & EU · GDPR-aware
A web app is not a bigger website — it is a system.
The moment a website turns into daily work — users logging in, data that must be protected, processes that cannot just go down — the hard questions begin. What roles exist? Who sees what? What will the data model look like in five years? Where does the app run, who patches it, how does it scale, how is it secured? p24.co plans and builds web apps so those questions get answered up front — not two releases too late. The result: a system that holds up after launch, instead of breaking under its own weight.
Typical use cases for a p24.co web app.
We build web apps and platforms for companies who want to solve a concrete problem digitally — not for “digital transformation” as a slogan. These are the cases we see most often:
Customer portal & B2B self-service
Your customers need access to contracts, status, documents, tickets, or orders — secure, fast, without email ping-pong. We build the portal with login, roles, audit trail, and a clean connection to your existing systems.
SaaS MVP & growing platform
You have a product idea meant to run as SaaS in Germany or the EU. We deliver a focused MVP with multi-tenant architecture, a real subscription model, clean auth, and a path the product can grow on — instead of being rewritten after launch.
Internal tools & operational platforms
Your team loses hours every week in spreadsheets, shared inboxes, or a sprawling Access database. We replace that with an internal tool where workflow, roles, permissions, and reporting live in one place — with sharp UX and a clear architecture.
Dashboards & reporting front ends
You have data — in ERP, CRM, database, external APIs — but no front end that turns it into a daily decision tool. We build fast, secure dashboards with role-specific views, not yet another Excel export.
Workflow & process systems
Applications, approvals, onboarding, order handling, case work: we model the workflow as a digital process with responsibility, status, escalation, and an audit view — instead of PDF ping-pong.
Taking over and stabilising an existing platform
You have a web app that someone built years ago and that no one can safely change today. We start with an audit, document where things stand, stabilise architecture and security — and walk you step by step to the platform you actually need.
Why “a website with a login” is not a platform.
We keep seeing the same failure modes in self-built or agency-built web apps. For each one we have a clear technical lever:
No real auth and role model
Login works, but permissions are scattered across if-statements. We define a clean role and permission model, documented and visible in the UI — including multi-tenancy where it matters.
A data model that does not survive growth
Schemas are leftovers from the first sprint, migrations are scary. We design the data model with real business logic in mind and a 12–36 month horizon — with clean migrations and versioning.
API tangled with the UI
The front end calls half-private endpoints that no one dares to touch. We separate the API as its own layer (REST or typed RPC), documented and versionable — the basis for mobile clients, integrations, or a public API.
Security as an afterthought
Token handling unclear, no rate limiting, no useful logs, no audit trail. We bake security in early: auth strategy, secrets management, OWASP hygiene, logging, and monitoring as part of the architecture — not a post-launch chore.
Deployment on “Marcus’s server”
Releases via FTP, no rollback, no staging, no automated tests. We deliver CI/CD with staging, preview environments, automated checks, and reproducible deploys — maintainability is a feature.
No roadmap past MVP
After the first release nobody owns the system, bugs pile up, features stall. We deliver not only the MVP but also the next-12-months path: what comes after launch, in what order, with what risks.
Architecture and building blocks — what you actually get.
A p24.co web app is not a theme with a backend. Every block below is intentionally designed, documented, and handed over:
1. Discovery & architecture sketch
Use cases, user roles, critical workflows, external systems, compliance constraints. Output: a compact architecture sketch, a data-model draft, a justified tech-stack choice — before the first line of code.
2. Front end — UI system & application layer
Next.js (App Router) + React + TypeScript, typed components, a real UI system (tokens, layout primitives, tables, forms, modals). Sharp for power users: keyboard, focus, speed — not a click maze.
3. Backend & business logic
API layer in Next.js route handlers, Node or .NET — depending on the requirement. Clear separation of domain, persistence, and transport. Validation, error model, and logging as architecture, not afterthought.
4. Database & data model
PostgreSQL as the default (Azure, Supabase, or self-hosted), versioned migrations, real relationships, indexes, soft deletes where sensible, audit columns. Additional stores (Redis, object storage, vector DB) where they pull their weight.
5. Authentication, roles & multi-tenancy
Auth on top of established libraries (Auth.js, Azure AD, Keycloak, or a tailored JWT/session implementation), a documented role and permission model, optional multi-tenant strategy, MFA and SSO where needed.
6. Integrations & interfaces
Integration with your ERP, CRM, accounting, mail or industry systems — through official APIs, webhooks, or custom connectors. Transformations are versioned, errors are handled, retries are real.
7. Security, logging & monitoring
OWASP top-10 hardening, secrets management, rate limiting, security headers, CSRF/XSS/SQLi protection, structured logs, health checks, error tracking (e.g. Sentry), alerting on real incidents.
8. CI/CD, hosting & operations
Repository, automated tests, linting, preview deployments, separate staging and production, reproducible releases, a rollback path. Hosting on Vercel, Azure, or comparable EU platforms — GDPR-aware.
9. Documentation & handover
Architecture document, data model, API reference, operations guide, developer onboarding. A new engineer should be productive in days — not weeks.
Process: from MVP to a platform that holds up.
We build web apps in clear phases — an honest MVP first, with a real plan for what comes next. No big-bang projects that deliver nothing for 18 months.
- 01
Discovery & use-case shaping
Week 1–2We sharpen the use cases, identify real users and their jobs, and map external systems and compliance constraints. Output: a prioritised backlog, an MVP scope, and clear non-goals.
output → Use-case brief · scope definition - 02
Architecture & data model
Week 2–3Tech stack, architecture, data model, auth and roles, API outline, hosting plan, security concept. No 80-slide deck — a precise, living architecture document.
output → Architecture document · data model - 03
UI system & clickable prototype
Week 3–4We build key screens as an interactive prototype on a lightweight UI system. Early feedback from real clicks — before the backend is set in stone.
output → UI system · prototype - 04
MVP build (backend + front end)
Week 4–10We build the MVP: database, API, auth, critical workflows, admin area. Daily deploys to staging, weekly demos. You see progress, not just status reports.
output → MVP build · staging environment - 05
Hardening, security & launch QA
Week 10–11OWASP hygiene, performance, privacy, logging, error tracking, backup/restore test, load test on the critical paths, final UX polish and content review.
output → Launch checklist · security note - 06
Launch & platform roadmap
From week 11Go-live, monitoring in place, onboarding material for internal teams. Handover includes a roadmap for the next 3–6 months: what comes next, what later, what never.
output → Live system · platform roadmap
What “good” means for a web app, in practice.
You don’t recognise a good platform by its splash screen — you recognise it by the qualities that hold up in daily work. This is the bar:
Architectural clarity
Domain, API, and UI are cleanly separated. There is no single magic file. New engineers understand the codebase without insider knowledge.
Security by default
Auth is enforced, sessions/JWTs are handled correctly, secrets live outside the repo, logs don’t leak PII, rate limiting is real. OWASP hygiene is the baseline, not a hobby.
Performance & resilience
Critical workflows answer in well under 300 ms server-side under load, front ends feel fast. Failure paths are defined: what happens on a DB outage, an external API failure, a token expiry.
Data integrity
Validation lives on the server, foreign keys are real, transactions wrap what belongs together. Consistency beats convenience. Migrations are reversible, data is backed up and restorable.
Long-term maintainability
Tests cover business logic, not just sunny-day paths. CI catches regressions. Dependencies stay upgradable. The app lives for five-plus years, not just until acceptance.
Observability & operations
Logs are structured, errors go into a tracker, key metrics (login failure rate, 5xx rate, job duration) are visible. You hear about problems before customers do.
Security, privacy, and founder accountability.
A platform stores real business and customer data — it is not a toy. p24.co is run by Dimitri Kronich from Krefeld, Germany. You get a technical counterpart with an EU base who actually owns architecture, security, and privacy — instead of delegating them downward.
- 01Founder-level ownership — a direct line to the person who decides architecture and security.
- 02Based in Krefeld · Germany & EU — GDPR-aware delivery, EU hosting, clear processing grounds.
- 03Auth, roles, encryption, backups, and audit trail as default — not as upsell.
- 04Reproducible releases, documented architecture, a real incident and recovery plan.
- 05A handover designed so another team could keep running your platform — no lock-in.
Frequently asked questions about web app development.
How long does it take to build an MVP web app?
Realistically 8–14 weeks from discovery to launch of a focused MVP — depending on workflow depth, integrations, and compliance scope. We commit to a binding timeline after discovery and the architecture phase.
What does a custom web app or customer portal cost?
A seriously built web-app MVP usually sits in the mid- to upper five-figure euro range; bigger platforms quickly enter six figures. We make scope, assumptions, and risks transparent — no “fixed price” on top of half-defined requirements.
Which technologies do you use for web apps?
Front end: Next.js, React, TypeScript. Backend: Next.js route handlers, Node, or .NET depending on the case. Databases are usually PostgreSQL. Hosting on Vercel, Azure, or comparable EU platforms. Auth via established stacks (Auth.js, Azure AD, Keycloak). Every choice is justified and documented.
Do you build multi-tenant SaaS for Germany and the EU?
Yes. We design tenancy at the data layer (tenant ID), clean auth and permissions, optional per-tenant subdomains, and a real subscription model. Privacy, GDPR, and EU hosting are part of the architecture — not a disclaimer in the footer.
Can you take over an existing web app and stabilise it?
Yes. We start with an architecture and security audit of the existing app, document the status, name the critical risks, and propose a stabilisation path — before we touch the code. No expensive surprises.
What about privacy, GDPR, and hosting in Germany?
We host in the EU by default (Azure West Europe, Vercel EU edge or equivalent), separate personal data cleanly, document processing, and provide the building blocks for data-processing agreements. Privacy lives in the architecture, not in a cookie banner.
Who operates the platform after launch?
On request, we take over operations: monitoring, updates, security patches, ongoing development. Equally, you can take over with your own team after launch — we ship documentation and setup so that path stays real.
Can we start small with an MVP and scale later?
That is exactly our default mode. We pick the stack and architecture so the MVP is useful on its own, but does not need to be rewritten on the first growth step. Roadmap and risk assessment are part of the handover.
Related services and topics
Let’s plan your platform properly.
Tell us briefly what problem the web app should solve, who will use it, and what existing systems it has to touch. You will get an honest, technical view — directly from the founder, without a sales layer and without buzzwords.