→ cat runtime_manifest
language: PHP 8.x
database: MySQL / MariaDB
frontend: HTML5 + CSS3 + vanilla_js
server: Apache (.htaccess)
package_manager: none
✓ zero build step, zero runtime dependencies
// stack
Our site runs on almost nothing.
Two separate stacks are described here: what powers this website, and what we typically deliver into yours. The first is decided and public. The second is the one that matters for your build.
What runs webnuvexa.com
This site is deliberately dependency-light. Not because the studio cannot use modern tooling - it is because most of it is not needed here, and every moving part is something that can fail at three in the morning.
| Layer | Choice | Reason |
|---|---|---|
| PHP | 8.x | Runs the whole site. Mature, boring, extremely well understood by whoever maintains it next. |
| Database | MySQL / MariaDB | Relational, backed up, restorable. Chosen because a stranger can maintain it. |
| Markup | HTML5 | Semantic structure first. Nothing clever to unwind. |
| Styling | CSS3 | One stylesheet, custom properties for tokens, no build step. |
| Behaviour | Vanilla JavaScript | Only what needs JS. Every kilobyte that does not ship is a kilobyte that cannot break. |
| Server | Apache + .htaccess | Routing, canonical URLs, caching and security headers in configuration you can read. |
What this site does not use
A short list of things you will not find in this codebase, and the reasoning. Every exclusion has a cost, and the cost is speed of iteration for large teams. On a site this size, that is the right trade.
| Category | Not used here | Why that is a choice, not a gap |
|---|---|---|
| Frameworks | React, Next.js, Vue, Angular, Svelte | Every one of them is fine. Each adds a build toolchain, a dependency tree and a class of failure that outlives the people who introduced it. |
| Language | TypeScript | For a site of this size the compile step and config surface cost more than the type safety returns. |
| Backend runtime | Node backend | A second runtime and a second deployment target to monitor for a site that does not need either. |
| Frameworks (PHP) | Laravel, Symfony, WordPress | Each brings a large surface, an update treadmill and, in the WordPress case, a security maintenance burden by default. |
| CSS tooling | Tailwind, Vite, Webpack | A build pipeline for one stylesheet is a build pipeline that can fail in production. |
| Infrastructure | Docker, Redis, MongoDB, PostgreSQL | Containers and extra datastores are justified at a scale this site does not have. |
Read this as a statement about this website, not about what we build for clients. A product with a real team and a real roadmap has different needs, and needs different tools.
Fewer failure modes
No dependency tree means no supply-chain surface, no build pipeline to break, and no lock-in to unwind when the next person maintains it.
Performance is structural
No framework runtime to hydrate and no client bundle to parse. The speed of this site comes from what is absent, not from optimisation work applied afterwards.
Maintenance survives us
A stack of files that a competent PHP developer can read is portable. That is a genuine commercial benefit to whoever owns it, and it is worth more over five years than any framework advantage.
Honest about the trade
This approach does not scale to a large product team, and we do not pretend otherwise. Client builds get modern tooling precisely because they need to scale with a team.
What we typically deliver
The stack we build client products on. It is a strong default, not a house religion: where a project argues for something else on the record, we use that instead and say why.
| Layer | Typical choice | Why it earns its place |
|---|---|---|
| Framework | Next.js 16 | Server components and streaming, one deploy target instead of a separate API host to keep in sync |
| Language | TypeScript | Typed contracts end to end, so a schema change fails at build time rather than in production |
| UI layer | Tailwind + shadcn/ui | Accessible primitives you own in your repository, so a design system can evolve without a vendor in the loop |
| Data platform | Supabase (Postgres + pgvector) | Relational integrity and vector search in one database, which keeps retrieval work out of a second system |
| Payments | Stripe | Subscriptions, tax, invoicing and disputes handled by the platform with the widest integration support |
| Hosting | Vercel | Branch preview deploys for review and edge delivery without us hand-rolling a deployment pipeline |
| Analytics and errors | PostHog + Sentry | Product analytics plus error and performance tracing, so a regression is diagnosable rather than arguable |
| AI integration | MCP (Model Context Protocol) | Standard way to expose internal tools to models. Public project telemetry, 2026: roughly 97-110M monthly downloads and 5,800+ servers, under Linux Foundation governance |
Typical, not exclusive. If your project argues for a different choice, the decision gets made on the merits and written into the scope.
Every line above is a default we can defend, not a rule we impose. The reasons matter more than the names: they are all about keeping the number of moving parts low, keeping failures diagnosable, and keeping the product yours rather than a vendor’s.
How a stack actually gets chosen
The default is not the point. The point is that the decision is made explicitly, written into the scope, and recorded for whoever maintains the product next.
Constraints before preferences
Team skills, hosting you already pay for, regulatory obligations, data residency, and who maintains this in two years. Preferences come after constraints.
Operational cost, not licence cost
A free tool that needs a specialist to operate it is not free. Every option is costed for hosting, maintenance and the expertise required to debug it at 2am.
Boring over clever
Newly fashionable technology carries an availability risk that its enthusiasts do not mention. Where novelty buys nothing, we take the well-worn option.
Escape routes
The stack is chosen partly for how badly it can be replaced. Data in an open format, logic in portable code, and no single vendor holding the only copy of anything.
Written down and handed over
The decision, the alternatives rejected and the reasons end up in the handover documentation. Decisions that only live in a chat log do not survive a staff change.
One ecosystem note worth making
Where AI tooling is part of a client build, the integration standard matters more than the vendor, because it decides how much of your system an assistant can reach.
Model Context Protocol
MCP is the open protocol for connecting language models to tools and data sources. We build against it where a client needs an assistant to act inside their systems rather than just talk about them.
Why it is worth knowing about
Public project telemetry for 2026 puts MCP in the region of 97 to 110 million monthly downloads with more than 5,800 servers, under Linux Foundation governance. Third-party ecosystem figures, not a WebNuvexa measurement.
Adoption does not mean security
An open protocol has thousands of implementations and a long tail of careless ones. Exposing internal tools to a model needs real access control, scoped credentials and audit logging. Protocol support is not a security review, and we do not perform those.
What we do about it
Least-privilege scopes per tool, credentials that are short-lived and revocable, an audit trail of tool calls, and an approval step for anything that writes. See our security page for the full split of responsibilities.
Ask about the stack
Tell us what you are building and what it has to integrate with. We will tell you what we would use and why, including when we would choose something else.