Stack

Infomerx is not married to a single vendor checklist. The stack below reflects what ships most often today; projects still pick libraries and services based on constraints, team skills, and lifecycle cost.

Default stack vs situational choices

Default (when nothing exotic forces a pivot): SvelteKit + TypeScript on the product surface, pragmatic REST or RPC-style APIs, and Python where batch jobs, automation, or model-adjacent services earn their place. Data-layer choices — relational database, document store, search index, flat files — are driven by the application's access patterns, not a vendor preference.

Situational choices, made deliberately:

• React or Next.js where existing team skills, component libraries, or hiring constraints make them the better long-run pick.
• Elasticsearch / OpenSearch for analytics, full-text search, or aggregation-heavy dashboards — including map- and indicator-heavy Nesta/DAP programme tools.
• PostgreSQL for relational workloads with complex constraints, row-level security, or transactional integrity — including multi-tenant products such as Escriba Finanzas.
• MongoDB where document shape and aggregation caching fit the access pattern.
• S3 for durable blobs, certs and static assets, and pipeline handoff to search indices (e.g. S3↔Elasticsearch sync).
• Redis for caching, sessions, and short-lived queues.
• SQLite for embedded or single-tenant edge deployments.
• MySQL for ETL and warehouse-extraction pipelines where the source system is MySQL-shaped — not a default runtime app database.
• Mapbox or similar when geospatial fidelity matters beyond basemap tiles.
• Workers, WASM, or GPU paths when the browser must carry real-time or heavy numerical work.
• Third-party auth or payment providers when compliance or scope says so.

Beyond named defaults: When a project lands outside the named set — other map providers, other frontend frameworks, other databases — three questions decide fit. Is the underlying problem one this practice has shipped before in another stack? Can the new territory be picked up at responsible speed without the client absorbing the learning curve? Does the engagement timeline allow for that ramp? If yes on all three, the work proceeds; otherwise that gets said up front and a referral is offered where useful. Engineering judgment — API boundaries, validation, performance budgets, accessibility, operational readiness — transfers across stacks more readily than tool lists suggest; framework idioms take a short ramp. Work that genuinely needs a long-tenured specialist in a specific ecosystem is referred rather than taken on.

Frontend and product surface

• SvelteKit with TypeScript for application shells, routing, and SSR or static prerender where it fits.
• Svelte 5 runes for component-heavy UIs; disciplined state boundaries when browsers carry real-time or 3D workloads.
• Accessible HTML patterns, semantic landmarks, and keyboard-first interaction as baseline—not a polish pass.
• React/Next.js is available where team or ecosystem constraints make it the right long-run choice; deliveries follow the same engineering posture, not a different one.

Visualization and geospatial

• Chart and map primitives chosen per project (including Mapbox or similar when the problem needs it).
• Layer and filter UX designed for dense datasets and long sessions, not demo-only happy paths.

Data, APIs, and services

Runtime databases, search indices, object storage, and pipeline stores are listed under Situational choices above (with trade-offs per access pattern). Validation at API boundaries regardless of store.

• Python for ingestion, automation, ML integration, or domain-heavy tooling—wired to the frontend with clear contracts and observability.

If you are validating technical fit, pair this page with capabilities and selected work for evidence, not buzzwords.