Technology that makes websites and software faster, safer, and maintainable for years.
Next.js, React, and TypeScript on the frontend. .NET and Node on the backend. Azure, CI/CD, and observability in operation. LLM integration, RAG, and guardrails for AI. Every choice is reasoned — not fashionable.
- Next.js · React · TypeScript
- .NET · ASP.NET Core · Node · PostgreSQL
- Azure · Docker · GitHub Actions · observability
- LLM · RAG · vector DBs · evaluation · guardrails
Stack decisions are business decisions — not matters of taste.
The choice of technology decides how fast your website loads, how safe your data is, how easily your team evolves the system — and how expensive it still is in five years. We treat stack choice as an architecture question: documented, justified, reversible. This page shows the tools we use to build websites, web apps, desktop and mobile apps, and AI integrations — and why.
Who this technology page is for.
We write here for readers who evaluate stack decisions, not just read marketing. If you carry one of these roles, you will find concrete answers.
CTOs and tech leads
You assess whether our stack fits your engineering team: hiring, existing systems, build pipelines, and long-term maintainability. You want to understand why we have committed to what.
Heads of digital / product
You own a product or platform and need a partner who not only builds “cool” but still ships maintainable code two years later — with paths your team can take over.
Leadership with a technical bar
You know the consequences of bad stack choices: high maintenance cost, hard hiring, fragile systems. You want a partner who takes those costs seriously.
Internal engineering teams
You want external modules to fit cleanly into your repository, be documented, and follow your coding standards. We deliver architecture and code your team can carry forward.
Typical stack problems — and how we avoid them.
Most stack problems are not caused by the wrong tools but by missing decisions. Here is what we see most often — and how we handle it.
Logo wall instead of architecture
Stacks presented as a collection of fashionable logos do not stay maintainable. We define a clear architectural centre (Next.js + TypeScript + .NET or Node + PostgreSQL) and add only what is genuinely needed.
Hidden lock-in
Platforms that start easy become expensive as soon as you want to scale (custom CMS, proprietary builders, opaque hosting). We prefer stack pieces with a clear exit strategy.
Hiring dead-ends
Exotic languages or frameworks leave the project stuck for staffing after launch. We choose technologies (Next.js, React, TypeScript, .NET, Node, PostgreSQL) where hiring is realistic.
Security and compliance treated too late
GDPR, data residency, role/permission models, audit trails — we resolve these in the architecture phase, not in an audit just before launch.
AI without a data strategy
LLMs get bolted on without anyone saying what data goes in, what may come out, how quality is evaluated, and who is responsible. We build AI integrations with data classification, evaluation, and guardrails — not as a tech demo.
Performance and SEO problems after launch
Bad hydration, missing image optimisation, oversized bundles — usually the result of missing architecture decisions. We set performance and SEO budgets from the start and enforce them in CI.
The p24.co stack at a glance.
Six building blocks that fit together. Each block is replaceable when a reasoned argument exists — but not out of fashion.
Web frontend · Next.js, React, TypeScript
Next.js (App Router) with React and TypeScript as the default for websites and web-app frontends. SSR/SSG for SEO, semantic HTML, WCAG-AA-aligned components, clearly defined tokens, and a design system. Performance budgets against Core Web Vitals, images via next/image, explicit caching strategy. Astro on the table when content dominates and JS load must be minimal.
Backend · .NET / Node, APIs, DB, auth, roles
.NET / ASP.NET Core when domain logic, longevity, and Windows/enterprise integration matter. Node (TypeScript) when frontend and backend live close together or a small service is enough. PostgreSQL as the default DB, migrations in the repo, REST or GraphQL depending on consumers. Auth via established providers (e.g. Azure AD, Auth0, custom OIDC), roles and permissions modelled explicitly.
Cloud & DevOps · Azure, Docker, CI/CD, observability
Azure as the default cloud (with a clear EU region setup), Docker for reproducible containers, GitHub Actions for CI/CD with quality gates (tests, linting, typecheck, bundle size). Multiple environments (dev/stage/prod), infrastructure-as-code where it pays off, logs/metrics/tracing via established tools, documented backup and restore strategy.
AI stack · LLM integration, RAG, evaluation, guardrails
OpenAI- and compatible LLM APIs as the standard path, local/EU options for sensitive data. RAG with vector DBs (e.g. pgvector, Qdrant) for company knowledge. An evaluation suite (gold set, regression, error classes) instead of gut feeling. Guardrails (prompt filters, output validation, rate limits, logging) and explicit data flows: what goes out, what stays in.
Mobile & desktop · PWA, React Native, .NET / WPF
PWA for web apps that should feel app-like without app-store overhead. React Native when real native features or store presence are required. .NET / WPF for Windows desktop software in enterprise contexts or specialised applications. We pick the channel by use case, not by trend.
Architecture principles · maintainability, security, cost
Domain-oriented modularisation, clear layering between UI, application logic, and persistence. Tests as a contract (unit for logic, integration and E2E for critical paths). Security model documented explicitly (auth, roles, secrets, backups). Cost as an architecture factor: we avoid setups that become disproportionately expensive on success.
Supporting artefacts
Architecture Decision Records (ADRs), diagrams for data flows and auth, documented deployments, performance and SEO budgets, test and backup strategy. After launch, handover-able to your team or another partner — stack choice without lock-in.
How we decide stack and architecture questions.
We follow a set of decision criteria so that stack choices come from your business context, not from fashion.
- 01
1. Clarify use case and lifespan
DiscoveryBefore talking tools: how long should this system live? Who maintains it after launch? Which loads and data volumes do we expect? These questions decide more than any stack trend.
output → Requirements & lifespan profile - 02
2. Check hiring and team reality
Architecture phaseWhich languages and frameworks does your internal team know? How hard is it to hire? We prefer stack pieces with a deep talent pool — not exotics without a hiring path.
output → Hiring & maintenance risk assessment - 03
3. Set the security and compliance frame
Architecture phaseGDPR, data residency, roles and permissions, audit trails, backups, secrets management — before we write code. We define a security and data flow plan that shapes the architecture.
output → Security & data flow plan - 04
4. Set a performance and SEO budget
Design system & buildWe define Core Web Vitals targets, bundle sizes, response times, and SEO assumptions. These budgets are monitored in CI — not first measured in the audit.
output → Performance & SEO budget - 05
5. Architecture Decision Record for every significant choice
OngoingEvery significant stack choice gets a short written record: context, alternatives, decision, consequences. So it stays traceable why something is the way it is — even two years later, even when p24.co is no longer in the project.
output → ADRs in the repository - 06
6. AI integration with data classification and evaluation
AI architectureBefore the first LLM call: which data may enter? Which answers are acceptable? How do we evaluate quality? We build a gold set, guardrails, and logging paths — not just prompts.
output → AI data flow plan · evaluation suite - 07
7. Operations and handover plan
Before launchBefore going live: who operates the system? Who rotates secrets? Who watches logs and backups? We deliver an operations plan and a hand-off plan so stack ownership is unambiguous.
output → Operations & hand-off plan
Architecture principles we apply consistently.
These are not slides — they show up in our repositories, architecture diagrams, and CI configurations.
Maintainability over cleverness
Readable, established code beats elegant tricks. We build so a developer can carry the project in three years without us.
Modularity with clear boundaries
Domain-oriented modules with explicit interfaces. UI, application logic, and persistence stay cleanly separated — tests become reliable as a result.
Security as default, not add-on
Auth flows, secrets management, data flow classification, logging, and backups are part of the minimum delivery. Thinking about security only after launch is too late.
Performance and SEO as engineering discipline
Core Web Vitals, semantic HTML, technical SEO, accessibility (WCAG AA) — we treat these as functional requirements, not marketing add-ons.
Hiring path as architecture criterion
We choose stack pieces with a deep talent pool. That keeps your project independent of individuals.
Cost as an architecture factor
We build setups that scale on success without becoming disproportionately expensive. Cloud choice, caching strategy, and data model are designed alongside the budget.
How we carry technology responsibility.
You work directly with the founder and a small engineering crew — no architecture layer that paints slides while others write code. We name risks early, write decisions down, and deliver a stack you can carry on yourself.
- 01You talk to engineering directly — not to sales talking about engineering.
- 02Architecture decisions live in ADRs — not in someone’s head.
- 03We say “no” to unnecessary lock-in, exotic tools, and hype-driven choices.
- 04Stack choice and security model are visible in the repository — not only in slides.
- 05We communicate in German, English, or Russian — whichever is natural for your team.
- 06After launch, your team gets everything it needs to carry the stack on its own.
Frequently asked questions about stack and architecture.
Why Next.js as the default for websites and frontends?
Next.js (App Router) covers SSR, SSG, and ISR, has strong defaults for SEO and performance, a large ecosystem, and a very broad talent pool. For content pages SEO behaviour is solid, for web-app frontends the component and data-flow architecture is clean. For purely static content with minimal JS we consider Astro.
Why .NET on the backend — not Node everywhere?
.NET / ASP.NET Core is strong at domain modelling, longevity, and integration with Windows/enterprise environments where many of our clients live. We use Node (TypeScript) when frontend and backend live close together or when a lightweight service is enough. Both options are established and maintainable.
Which database do you typically choose?
PostgreSQL as the default — relational, robust, mature, and with pgvector also usable for AI use cases. For specific needs (full-text search at scale, high-volume vector search, time series) we add specialised stores deliberately.
How do you handle auth, roles, and GDPR?
Auth via established providers (e.g. Azure AD, Auth0, custom OIDC), roles and permissions explicitly modelled and visible in code, not buried in UI. For GDPR we clarify data residency (often Azure West Europe), processing agreements, logging with personal data, deletion concepts, and audit trails. These land in the architecture document, not first in the audit.
How is your cloud and DevOps setup built?
Azure as the default cloud with a clear EU region setup, Docker for reproducible containers, GitHub Actions for CI/CD including tests, linting, typecheck, and bundle budgets. Multiple environments (dev/stage/prod), documented deployments, logs/metrics/tracing, backup and restore plan. If you already use AWS or GCP, we adapt — cloud is not an end in itself.
How do you integrate AI / LLMs safely?
Before the first LLM call we define: which data may go in, which answers are acceptable, how quality is measured. We build RAG over company knowledge, an evaluation suite (gold set, regression tests), guardrails (prompt filters, output validation, rate limits), and logging. For sensitive data we evaluate EU/local LLM options.
When does a PWA make sense, when React Native, when .NET desktop?
PWA when the experience stays close to the web, fast updates matter, and store presence is not required. React Native when real native features, offline behaviour, or store presence are required. .NET / WPF when Windows integration, long-lived specialised applications, or enterprise deployment dominate. We pick by use case and user behaviour, not by trend.
How do you make sure the stack stays maintainable without you?
Three things: established technologies with a deep talent pool, documented architecture decisions (ADRs), and a structured hand-off with maintenance guide, architecture documentation, and reproducible deployments. You can run the system with your own team — or with another partner.
Can you step into an existing stack?
Yes. If you already use Next.js, React, .NET, Node, PostgreSQL, Azure, or comparable technologies, our work plugs in directly. For legacy systems we start with an architecture audit and propose an incremental modernisation path — no big-bang rewrites.
What if you don’t have a technology we need in your stack?
Then we say so openly. We don’t take projects just to take them. If another partner technically fits better (e.g. deep iOS-native expertise, very specialised industry software), we recommend that honestly — and may support only in the architecture phase.
Related services and topics
Let’s assess your architecture honestly.
Tell us briefly what you run today and what you plan next. In a first conversation we’ll sort where the stack is solid, where the risks sit, and which next steps actually help you. Direct from the founder, no sales layer.