➤ ./webnuvexa --list-stacks
Loading capability inventory...
✓ 11 disciplines loaded
✓ Every entry carries its reason
! Not a list of shipped client engagements
Ready▒
// Technologies
What we work in, and why each one earns its place.
Clients arrive with stacks that already exist. This is an inventory of the technologies we can build in, organised by discipline, with the reasoning attached — because a bare list of logos tells you nothing you can act on.
How To Read This Page
Three things worth being precise about before you scan the tables.
This Is Capability, Not A Client Log
Every entry below is a technology we can build in competently. It is NOT a claim that we have shipped a production system on each one. Anyone listing fifty shipped stacks for a studio this size is not telling the truth. Ask us directly which of these we have real experience with on your particular stack, and we will answer straight.
The Reasoning Is The Point
The third column matters more than the first. A technology earns its place because of what it does for the project, not because it is fashionable. If a row has no defensible reason, it should not be here.
Your Stack Usually Wins
These are defaults we can defend, not a house religion. Where your project argues for something else on the record, we use that instead and write the reasoning into the scope.
The Inventory
Grouped by discipline. Each group states what the technologies are for and the trade-off you are accepting.
Languages
Most projects are one primary language and one scripting language. The rest is dictated by the ecosystem you are joining.
| Language | Where it fits | Why we would reach for it |
|---|---|---|
| TypeScript | Application and API code, front to back | Typed contracts that fail at build time instead of in production, and one language across a full-stack project. |
| Go | Services, indexers, high-throughput workers | Predictable resource use and cheap concurrency. The right default when a service is CPU-bound and simple. |
| Python | Data, ML, integrations, automation | The shortest path from idea to working data pipeline, and the language the ML ecosystem actually lives in. |
| Rust | Performance-critical and chain-adjacent code | Where an encoding, signing or hot path has to be exactly right, and where memory safety is a correctness property. |
| PHP | This site, and content-heavy or commerce back-ends | Mature, cheap to host, and easy for the next person to maintain. The right default for a lot of server-rendered work. |
| Java / Kotlin | Large existing estates, Android | Usually because your system already runs on it. Rewriting a working JVM estate for a preference is not advice. |
| C# / .NET | Microsoft-centric organisations | First-class choice where the client is already standardised on Microsoft, especially internal and line-of-business tooling. |
| Ruby | Existing Rails products and Rails-adjacent work | Rarely a new-build recommendation, frequently a maintenance reality. We maintain it and we would rather not rewrite it. |
| C / C++ | Native integrations, drivers, embedded edges | Where no higher-level language can reach: hardware interfaces, native SDKs, performance-critical inner loops. |
Frontend
The framework is usually your decision, not ours. We work in all of these and have opinions about which suits which constraint.
| Technology | Where it fits | The honest trade-off |
|---|---|---|
| React / Next.js | Most product front-ends and full-stack apps | Largest talent pool and ecosystem. Costs a build toolchain and a dependency surface we then have to own. |
| Vue / Nuxt | Product teams that prefer a lighter runtime and an integrated meta-framework | Genuinely less machinery than React for a comparable result. Smaller hiring pool. |
| Angular | Large enterprise applications with long lives | Heavy ceremony, strong conventions and built-in discipline. Justified at scale, costly for small products. |
| Svelte / SvelteKit | Interaction-heavy interfaces where bundle size matters | Very little runtime. Smaller ecosystem, so more of the ecosystem work lands on us. |
| Astro | Content-led sites where most pages should ship almost no JavaScript | Islands architecture. The right answer for documentation and marketing sites, the wrong one for an application. |
| Remix / React Router | Server-rendered React where routing and loaders are the core problem | Converging back into React Router. Sensible if your team already standardised on it. |
| Tailwind / SCSS | Styling | Either is fine. We match whatever design system you have rather than converting you for preference. |
| Storybook | Component libraries and design-system maintenance | The component is the interface for designers and engineers. Worth the setup on anything with a shared UI. |
| GSAP / Lottie / Three.js | Motion, explainer animation, 3D | Motion with a purpose. We build to prefers-reduced-motion by default rather than bolting it on. |
APIs And Integration
The integration layer is where most products are actually won or lost. It gets the most attention in our scoping.
| Technology | Where it fits | Why it earns its place |
|---|---|---|
| REST / OpenAPI | Public and partner HTTP APIs | The contract is the deliverable. A published spec your partners can generate clients from removes an entire class of support calls. |
| GraphQL | Aggregating several data sources for one consumer | Genuinely better for many-to-many reads. Often the wrong tool for a single-resource CRUD API. |
| gRPC | Internal service-to-service calls on known networks | Strong contracts and efficient binary transport where both ends are ours to control. Not a partner-facing API. |
| WebSockets / SSE | Live updates: order books, job progress, notifications | The right shape for a genuinely live surface. We pair it with a reconnect and backoff strategy, not just a socket. |
| Webhooks | Outbound event delivery to third parties | Signed, retried, replayable and idempotent. The signing and replay tooling is the work; the POST is trivial. |
| OAuth 2.1 / OIDC / SAML / SCIM | Authentication and directory integration | Enterprise buyers evaluate your SSO before they evaluate your product. SAML still arrives constantly. |
Web3 And Blockchain
Integration engineering against chains that already exist. We write no audit reports, hold no keys, and design no tokens. See /web3-development/ for the full scope.
| Technology | Where it fits | Boundary we hold |
|---|---|---|
| Solidity / Vyper | Contracts on EVM chains | We build against contracts, and we write contract code where it is genuinely ours to own. |
| Rust (Anchor / CosmWasm) | Solana programs and Wasm chains | Chosen when the chain dictates the language, or where a signing or encoding path must be exactly right. |
| Cairo (Starknet) | Starknet contracts and applications | A separate codebase and a separate verification model, not a configuration change. |
| Move (Aptos / Sui) | Aptos and Sui contracts | Different object model and address scheme. The language follows the chain. |
| viem / ethers.js / Web3.js | Chain clients, always behind one adapter | Keeping chain specifics behind a single interface is what makes adding a fourth chain days of work. |
| Foundry / Hardhat | Contract testing, fuzzing, deployment | We run these on our own code. They are not an audit and we never present them as one. |
| Bitcoin / Lightning | Asset and payment rails | UTXO model, script constraints, and no general compute environment. A genuinely different engineering problem. |
| CosmWasm / Substrate / WebAssembly | Cosmos-family chains and Wasm runtimes | A Rust toolchain compiled to WebAssembly and a chain architecture with its own concepts. A separate codebase, not a setting. |
| Hyperledger Fabric | Permissioned enterprise consortium chains | Governance-heavy, permissioned, and enterprise-approached. Different commercial engagement from a public-chain build, and scoped separately. |
Data
The datastore follows the query patterns and the consistency guarantees you actually need. It is not a fashion choice.
| Technology | Where it fits | Why it earns its place |
|---|---|---|
| PostgreSQL | The default relational store, including with pgvector | Relational integrity plus vector search in one system, which keeps retrieval work out of a second datastore. |
| MySQL / MariaDB | Existing estates and this site | Utterly boring and maintainable by whoever comes next. A feature, not a limitation. |
| MongoDB | Schema-flexible documents, event and content shapes | Right when the document shape genuinely varies. Wrong when the invariants are relational. |
| Redis | Caching, rate limiting, queues, sessions | Cheap and fast. We treat it as disposable derived state, never as the system of record. |
| Supabase | Postgres with auth, storage and edge functions | A lot of capability quickly, which is exactly why the parts you rely on should be pinned deliberately. |
| Prisma / Drizzle | Typed data access in TypeScript projects | Schema-as-source-of-truth and generated types, so a column rename fails at compile time. |
| Elasticsearch / OpenSearch | Full-text search, faceting, log search | When Postgres full-text genuinely stops being enough. Usually a later, deliberate phase. |
| Algolia | Hosted search with typo tolerance and ranking | Fast to ship, paid per search. Worth it when search quality is the product, not a feature. |
Infrastructure And Delivery
Where the product runs, how it gets there, and who can roll it back at 3am. This is a fixed-fee phase, not an afterthought.
| Technology | Where it fits | Why it earns its place |
|---|---|---|
| AWS | The broadest and most mature cloud, and our default | The most services, the most documentation and the most people who already know it. Hard to beat for reach. |
| Google Cloud | Data-heavy and ML-heavy products | Genuinely better for large-scale data processing and model training workloads, and BigQuery earns its cost there. |
| Azure | Microsoft-standardised enterprises | Frequently the only acceptable answer where identity, licensing and procurement are Microsoft-centric. |
| Cloudflare | DNS, CDN, WAF and edge caching | Cheap, fast and effective at absorbing traffic and hostile requests before they reach your origin. |
| Vercel / Netlify | Frontend hosting with preview deploys | Branch previews make design review cheap. Not a fit for a stateful long-running service. |
| Docker / Kubernetes | Containerisation and orchestration at scale | Justified by real scale and real constraints. Below that it is a second platform to operate for no benefit. |
| Terraform | Infrastructure as code | The only defensible way to recreate an environment. Cloud consoles are not a deployment process. |
| Ansible | Configuration management for existing estates | Idempotent, low-ceremony server configuration. Often a better fit than forcing everything into Terraform. |
| GitHub Actions / Jenkins | CI and CD | GitHub Actions for most projects. Jenkins where an existing self-hosted pipeline and its plugins are already load-bearing. |
Observability
Instrumentation is written with the feature, not bolted on after the first unexplained incident.
| Technology | Where it fits | Why it earns its place |
|---|---|---|
| Prometheus / Grafana | Metrics, dashboards, alerting | Open and composable. The right answer when you want to own the telemetry you are paged by. |
| OpenTelemetry | Vendor-neutral traces, metrics and logs | Instrument once and keep the option to change backend. Cheaper than being locked in later. |
| Sentry | Error tracking and performance tracing | Turns "it is broken somewhere" into a stack trace with the request that caused it. |
| Datadog | Managed observability across logs, metrics and traces | Excellent and expensive. Justifiable when engineering time is scarcer than the bill. |
| Structured logging | Everywhere | The least glamorous and most valuable. Log lines that can be queried beat dashboards nobody trusts. |
Testing And Quality
Test strategy is decided per project, because the right ratio of unit to integration to end-to-end depends entirely on what breaks expensively.
| Technology | Where it fits | Why it earns its place |
|---|---|---|
| PHPUnit | PHP server-side code | The standard. Fast, and it keeps a large PHP codebase changeable. |
| Playwright / Cypress | End-to-end browser coverage | The tests that catch the regressions users actually report, kept few enough that people trust them. |
| Vitest / Jest | TypeScript and JavaScript unit tests | Fast feedback in the ecosystem where most front-end regressions originate. |
| k6 | Load and performance testing | Scripted load tests with thresholds, so "it is fast" becomes a number rather than an opinion. |
| Contract and schema tests | Service and API boundaries | Catches the class of breakage where two services each changed and neither broke on its own. |
Commerce And Payments
Money movement is where integrations get expensive if they are designed late. These are the ones we plug into.
| Technology | Where it fits | Boundary we hold |
|---|---|---|
| Stripe | Subscriptions, invoicing, tax, disputes | Our default for new payment work: the widest integration support and the best-documented disputes tooling. |
| PayPal | PayPal wallets and marketplaces | Still a requirement for a large share of consumers. Treated as an additional path, not the primary one. |
| Square | In-person and SMB payment acceptance | Straightforward. Appropriate where a physical presence is part of the business. |
| Adyen / Worldpay | Enterprise acquiring and marketplace splits | What enterprise and marketplace buyers ask for. Complex, and worth quoting properly rather than improvising. |
| Shopify / WooCommerce / Magento / BigCommerce | Storefront platforms | Headless integrations, custom checkout logic and the connector layer between them. We build inside the platform rather than around it. |
Messaging, CRM And Content
The integrations that decide whether a launch reaches anyone, and whether a team can operate the thing they built.
| Technology | Where it fits | Why it earns its place |
|---|---|---|
| Twilio | SMS, voice, WhatsApp | The default for transactional messaging. Voice is a genuinely separate integration and we scope it separately. |
| SendGrid / Postmark | Transactional email | SendGrid for volume and deliverability tooling, Postmark where strict transactional semantics matter more than price. |
| HubSpot / Salesforce | CRM | Marketing and sales systems your team already uses. Integration quality is usually the whole project. |
| Klaviyo / Mailchimp | Lifecycle and broadcast email | Segmentation, flows and consent handling, wired to real events rather than nightly exports. |
| Sanity / Contentful | Structured headless CMS | Good for content teams who need editorial control without a deploy. A real operational dependency, not just an API. |
Authentication And Security Engineering
The engineering controls we build. None of these are certifications: we implement what your assessors require and they issue the findings.
| Control | What we build | What we do not do |
|---|---|---|
| Passkeys / WebAuthn | Passkey enrolment, recovery flows and fallback paths | Nothing. We build the feature. |
| 2FA / MFA (TOTP, WebAuthn, push) | Enrolment, step-up authentication and admin lockout policy | Nothing. We build the feature. We do not operate it for you. |
| OAuth 2.1 / OIDC / SAML | SSO for enterprise customers, SCIM provisioning | We are not an identity provider. |
| Encryption and secrets | AES at rest, TLS in transit, KMS integration, rotation design | We do not hold long-lived signing keys or production secrets. |
| Hardening and evidence | Dependency scanning, secure headers, access reviews, documentation for assessors | We perform no penetration test, SOC 2 audit or ISO certification, and issue no attestation of any kind. |
What This Page Does Not Claim
Stated plainly so you are not left inferring it from the tables above.
No Certifications Or Attestations
WebNuvexa holds no SOC 2 report, no ISO certification, no PCI attestation, no penetration test results, no smart contract audit reports, and issues no security attestation of any kind. We implement the controls your assessors require; qualified third parties issue the findings.
No Rankings Or Awards
We are not on any awards list and we do not claim industry recognition. If a credential matters to your procurement, ask for it directly and we will tell you plainly that we do not have it.
No Benchmarks We Did Not Run
We do not publish performance numbers we have not measured on your workload. Speed claims in a proposal are meaningless without the shape of the traffic.
No Depth Claimed From Breadth
Working knowledge of many technologies is not deep expertise in all of them. On any project we will tell you which parts of this inventory we are genuinely strong in and which we would want a specialist alongside us for.
Where This Connects
The stack behind this website, the method for choosing yours, and the services these technologies get used in.
/stack/
The stack running this website, what we deliberately do not use on it, and the default deliverable stack we hand to clients.
/methodology/
How a stack actually gets chosen: constraints before preferences, operational cost rather than licence cost, and written decisions that survive a staff change.
/web3-development/
The full scope and boundaries for chain and smart-contract engineering, including what we will not do and why.
/industries/
Which of these technologies get applied depends on the sector. The vertical pages map them to the constraints that actually decide the design.
Working in a stack on this list?
Tell us what it is, what it does and what is annoying about it. You will get an honest read on whether we are the right team for it, including if the answer is that we are not.