# Ecorpin — Complete Technical Knowledge Manifest
> Ecorpin is a software engineering company. We design, build, and operate product platforms, cloud infrastructure, and enterprise AI systems for our clients and for our own products, FirmOps and FluxTrace.

Canonical Origin: https://ecorpin.com

## About Ecorpin
We design, build, and operate product platforms, cloud infrastructure, and enterprise AI systems for our clients and for our own products.

### Core Values & Operating Principles
- **You own what we build**: Source code, infrastructure, and models we produce for you are yours. We do not hold work hostage behind a proprietary platform.
- **No unnecessary lock-in**: We prefer open, portable stacks — Kubernetes, PostgreSQL, React, Go, Python — so you can run and hire against them without us in the middle.
- **Engineering over theater**: We ship with tests, types, and observability. Scope and claims stay within what we can actually stand behind.
- **Clear communication**: You see the work as it happens: pull requests, decisions, and trade-offs written down so the next engineer can pick it up.

### Focus Areas
- **Cloud & infrastructure**: Kubernetes, infrastructure as code, and the operational habits that keep environments reproducible.
- **AI & data**: Retrieval, agents, and evaluation pipelines that sit inside real products with real access controls.
- **Distributed systems**: Services, APIs, and data stores designed for the load and consistency the domain actually needs.
- **Product platforms**: Web and mobile applications with typed code, design systems, and CI that teams can keep shipping.

## Solutions & Engineering Practices
### Custom software
URL: https://ecorpin.com/solutions/custom-software
Tagline: Web applications, APIs, and product platforms built to last

We design and build software for teams that need reliable products — from internal tools to customer-facing platforms. Clear architecture, typed code, and automated tests are the default, not extras.

**What We Deliver:**
- Web applications in React, Next.js, and TypeScript
- APIs and service boundaries with clear contracts
- Data models and persistence that fit the domain
- Test suites and CI that catch regressions before they ship

**Problems We Solve:**
- A product that outgrew its first architecture and slows every release
- Internal tools spread across spreadsheets, inboxes, and disconnected apps
- Web and mobile clients that cannot share one source of truth

**Core Stack:** TypeScript, React, Next.js, Go, PostgreSQL, Redis

### Cloud & DevOps
URL: https://ecorpin.com/solutions/cloud-devops
Tagline: Infrastructure you can reason about and operate

We help teams run software on AWS, Google Cloud, and Azure with infrastructure as code, repeatable deployments, and observability that operators actually use.

**What We Deliver:**
- Kubernetes and container platforms sized to the workload
- Terraform / OpenTofu for declarative infrastructure
- GitOps and CI/CD pipelines with staged rollouts
- Metrics, logs, and tracing wired into day-to-day operations

**Problems We Solve:**
- Deployments that depend on one person and a manual checklist
- Cloud bills that grow faster than traffic
- Incidents that are hard to diagnose because logs, metrics, and traces live apart

**Core Stack:** Kubernetes, AWS, Google Cloud, Azure, Terraform, ArgoCD

### AI systems
URL: https://ecorpin.com/solutions/enterprise-ai
Tagline: Practical RAG, agents, and MLOps — not demos

We build AI features that sit inside real products: retrieval over your documents, agent workflows with guardrails, and evaluation so quality is measurable.

**What We Deliver:**
- Retrieval-augmented generation over private corpora
- Agent workflows with citations and access controls
- Private or VPC-hosted inference where data cannot leave
- Evaluation harnesses for retrieval quality and safety

**Problems We Solve:**
- AI features that demo well but cannot be measured in production
- Internal search that ignores who is allowed to see what
- Sensitive data that cannot be sent to a public model API

**Core Stack:** Python, FastAPI, LangChain, pgvector, PyTorch

### Managed SRE
URL: https://ecorpin.com/solutions/managed-it-sre
Tagline: On-call, monitoring, and steady operational improvement

For teams that need extra operational capacity, we provide monitoring, incident response, and the unglamorous work of keeping production healthy.

**What We Deliver:**
- On-call coverage and incident runbooks
- Alerting that pages on symptoms, not noise
- Capacity planning and cost-aware operations
- Post-incident reviews that turn into concrete fixes

**Problems We Solve:**
- On-call that pages on noise and misses real outages
- Incidents that repeat because reviews never become fixes
- A small team without the capacity to run production around the clock

**Core Stack:** Prometheus, Grafana, OpenTelemetry, PagerDuty

### Security engineering
URL: https://ecorpin.com/solutions/cybersecurity
Tagline: Identity, secrets, and secure defaults in the stack

We fold security into how software is built and run — short-lived credentials, least-privilege networks, and practical hardening rather than a checklist after the fact.

**What We Deliver:**
- Secrets management and credential rotation
- Service identity, TLS, and network segmentation
- Authn/authz with SSO, OIDC, and role-based access
- Dependency scanning and secure CI defaults

**Problems We Solve:**
- Long-lived secrets and shared credentials across services
- Access rules scattered across apps instead of enforced in one place
- Security questionnaires that the running system cannot back up

**Core Stack:** Vault, mTLS, OIDC, OPA, Trivy

### AR & WebXR
URL: https://ecorpin.com/solutions/ar-webxr
Tagline: Augmented reality and immersive scenes that run in the browser

We build augmented-reality features and WebXR scenes that run on phones and headsets without app-store installs — product configurators, on-site overlays, and training walkthroughs tied to your real data and access rules.

**What We Deliver:**
- WebXR scenes with AR hit-testing, anchors, and session management
- AR product viewers and configurators with model-viewer or custom Three.js
- Spatial content pipelines: glTF optimization, compression, and CDN delivery
- Device capability detection with graceful 2D fallbacks where AR is unavailable

**Problems We Solve:**
- A product that customers cannot picture until it is installed, built, or delivered
- Field and training workflows that still depend on paper, photos, and callbacks
- Immersive demos that only run on one headset or need an app-store install

**Core Stack:** WebXR, Three.js, model-viewer, WebGL, glTF, TypeScript

## Case Studies & Systems Shipped
### FirmOps (Operations)
URL: https://ecorpin.com/case-studies/firmops
Summary: Ecorpin's operations platform: CRM, invoices, tasks, and monitors on web and mobile, behind one SDK gateway.
**The Problem:**
Client records, invoices, tasks, and website notes lived in separate tools. A public inquiry opened a mail client and never became a record someone could assign. Web admin and mobile could not share one source of truth.
**What Was Shipped:**
Website inquiries used to die in a mail client. Now every one becomes an assignable record in FirmOps — our web admin and Expo app for CRM, invoices, tasks, and monitors, behind one SDK gateway.
**Engineering Approach:**
We treated our own operations as the first customer. Shared data sits behind the SDK, roles stay on the server, and the public site only gets a create-only key. We run it with the same delivery standards we bring to client work: typed code, tests, and predictable operations.
**Technologies:** Node.js, Express, MySQL, Expo, React, Ecorpin SDK
**Key Outcomes:**
- Inquiries: Assignable
- Web + mobile: One gateway
- Public key: Create-only
### FluxTrace (Analytics)
URL: https://ecorpin.com/case-studies/fluxtrace
Tagline: Privacy-focused product analytics
Summary: Cookieless web and product analytics with bot labeling at ingest and anomaly detection.
**The Problem:**
Teams wanted product analytics without cookie banners or stored raw IP addresses, and AI crawlers were inflating the traffic numbers in every dashboard they tried.
**What Was Shipped:**
FluxTrace, Ecorpin's privacy-focused analytics platform: a first-party collector, bot labeling at ingest, plan-gated event acceptance, anomaly detection, and SDKs for Python, PHP, and Ruby.
**Engineering Approach:**
The collector hashes each session into a daily id and drops the raw IP before anything is queued. Bots are labeled at ingest so every later aggregate stays honest, and events outside a plan are acknowledged but never stored. The dashboard, collector, and worker run as separate processes, so a traffic spike never slows the product UI.
**Technologies:** TypeScript, Next.js, Fastify, MySQL, Redis, Python
**Key Outcomes:**
- Cookies: None
- Raw IPs: Never stored
- Bots: Labeled at ingest
### Evolvance EdTech (Education)
URL: https://ecorpin.com/case-studies/evolvance-edtech
Tagline: Workforce training and industry-standard skilling
Summary: Evolvance Solutions' training platform: structured courses, paid enrollment, and certificates for students, instructors, and admins — built with Ecorpin engineering.
**The Problem:**
Evolvance Solutions trains the workforce it deploys — from AI and data science to web development and digital marketing — but courses, enrollment, progress, and certificates lived outside one system its operators could run.
**What Was Shipped:**
Evolvance EdTech: course catalog and paid enrollment, text, video, and PDF lessons grouped into modules, quizzes, assignments, certificates, and separate dashboards for students, instructors, and admins.
**Engineering Approach:**
Roles are enforced on the server for students, instructors, and super admins, with Google sign-in for learners and local accounts for staff. Payments run through Razorpay, lesson content is sanitized on render, and live updates use Socket.IO.
**Technologies:** Node.js, Express, MySQL, Sequelize, Socket.IO, Razorpay
**Key Outcomes:**
- Roles: Three dashboards
- Lessons: Text, video, PDF
- Payments: Razorpay
### Evolvance Classroom (Education)
URL: https://ecorpin.com/case-studies/evolvance-classroom
Tagline: Learning management system
Summary: A learning platform where instructors sell courses, students learn and earn certificates, and admins run the business.
**The Problem:**
Evolvance Solutions needed one platform where instructors publish and sell structured courses, students learn and earn certificates, and operators run the business without stitching tools together.
**What Was Shipped:**
Evolvance Classroom: course catalog and paid enrollment, text, video, and PDF lessons grouped into modules, quizzes, assignments, certificates, and separate dashboards for students, instructors, and admins.
**Engineering Approach:**
Roles are enforced on the server for students, instructors, and super admins, with Google sign-in for learners and local accounts for staff. Payments run through Razorpay, lesson content is sanitized on render, and live updates use Socket.IO.
**Technologies:** Node.js, Express, MySQL, Sequelize, Socket.IO, Razorpay
**Key Outcomes:**
- Roles: Three dashboards
- Lessons: Text, video, PDF
- Payments: Razorpay
### Financial platforms (Financial Services)
URL: https://ecorpin.com/case-studies/financial-platforms
Summary: undefined
**The Problem:**
Ledger and settlement systems start as one database and one release train. Peak volume, audit, and new products then fight over the same tables.
**What Was Shipped:**
**Engineering Approach:**
We decompose along money-movement boundaries — posting versus settlement, products that never share a balance — with explicit contracts between them. An event log is introduced where replay and audit justify it, never by default. Balances derive from one source of truth, and cutovers run through dark reads, shadowed writes, and a reversible switch, so operations stay uneventful.
**Technologies:** Go, PostgreSQL, Kafka, Kubernetes
**Key Outcomes:**
- Boundaries: Money movement
- Cutover: Reversible
- Balances: One source
### Internal knowledge systems (AI & Data)
URL: https://ecorpin.com/case-studies/knowledge-ai
Summary: undefined
**The Problem:**
Teams lose hours searching wikis, tickets, and repositories. Generic chat wrappers answer from documents the asker was never allowed to open.
**What Was Shipped:**
**Engineering Approach:**
We index the sources that matter and retrieve with hybrid search — keywords for identifiers, vectors for phrasing — filtered by the requester's existing identity and roles. Every answer carries citations, and anything the asker cannot open is never retrieved. Retrieval quality and refusal behavior are scored continuously, not demonstrated once.
**Technologies:** Python, FastAPI, pgvector, React
**Key Outcomes:**
- Answers: Cited
- Search: Hybrid
- Access: Role-filtered
### Healthcare data platforms (Healthcare)
URL: https://ecorpin.com/case-studies/healthcare-data
Summary: undefined
**The Problem:**
Clinical data is sensitive and spread across vendors and formats. Care teams still need timely access, so locking everything down is its own failure.
**What Was Shipped:**
**Engineering Approach:**
We design ingestion, encryption, and access around each dataset's actual sensitivity: least-privilege service identities, envelope encryption under managed keys, immutable audit trails, and infrastructure that operations can walk an auditor through line by line. Controls are implemented as code, and diligence starts from what is actually running.
**Technologies:** AWS, Kubernetes, KMS, PostgreSQL
**Key Outcomes:**
- Design: HIPAA-aligned
- Encryption: Envelope + KMS
- Audit trail: Immutable
### Operations & telemetry (Operations)
URL: https://ecorpin.com/case-studies/ops-telemetry
Summary: undefined
**The Problem:**
Fleets, devices, and plants emit more events than a scheduled warehouse job can absorb. When ingest lags, dashboards look calm while the incident is already old.
**What Was Shipped:**
**Engineering Approach:**
We buffer at the edge so network blips stop dropping the last hour, stream into a columnar store operators can query interactively, and page on symptoms the on-call already understands. The warehouse keeps its role in planning and reporting; it simply stops being the only place the truth appears.
**Technologies:** Go, Kafka, ClickHouse, Grafana
**Key Outcomes:**
- Ingest: Edge-buffered
- Store: Columnar
- Paging: Symptom-based
### Commerce platforms (Commerce)
URL: https://ecorpin.com/case-studies/commerce-platforms
Summary: undefined
**The Problem:**
Storefronts and inventory share fate until the first real peak. Slow pages lose conversions, and overselling turns into refunds and chargebacks.
**What Was Shipped:**
**Engineering Approach:**
We separate catalog, checkout, and inventory into independently scalable paths, cache reads at the edge, and enforce stock correctness with real locks where money changes hands. The storefront stays fast under peak without ever displaying stock it cannot honor.
**Technologies:** Next.js, TypeScript, Redis, GraphQL
**Key Outcomes:**
- Paths: Independent
- Catalog reads: Edge-cached
- Stock: Locked at checkout
## Technical Insights & Architecture Guides
### Splitting a ledger monolith without a big-bang rewrite
URL: https://ecorpin.com/insights/splitting-a-ledger-monolith
Published: 2026-09-06 | Topic: Architecture | Read Time: 4 min read

Ledger and settlement systems often start as one database and one release train. Peak load, audit, and new products then collide. This is how we peel domains apart without freezing the business.

#### The usual bind
A ledger that posts, settles, and reports in one process is easy to start. It becomes hard when a new product needs a different posting rule, when audit wants an immutable trail, and when peak volume fights the same tables as overnight close.
A full rewrite sounds clean and rarely is. The business still has to move money while you cut over.

#### Split on money-movement boundaries
We look for seams the domain already has: posting versus settlement, products that do not share a balance, reports that can lag the book. Those become services or modules with explicit contracts, not a forest of shared tables.
Where an event log earns its keep — fan-out, replay, a trail operations can explain — we add one. We do not introduce a bus because it is fashionable.

#### Keep one source of truth for money
Caches, read models, and product APIs can be many. The record of what moved, and the balances that follow from it, stay singular. Dual-writing two books is how you lose money and trust.
Rollouts are staged: dark reads, shadowed writes, then a cutover you can reverse. Operations stay predictable on purpose.

**Code Pattern (ledger-cutover-strategy.ts):**
```typescript
// Pattern: Domain-bounded ledger split with dual verification
interface LedgerCutoverPlan {
  readonly phases: ['dark-reads', 'shadowed-writes', 'reversible-cutover'];
  readonly sourceOfTruth: 'Immutable Event Log (Kafka / CDC)';
  readonly balanceVerification: 'Continuous double-entry invariant assertions';
  readonly rollbackWindow: '< 60 seconds without data loss';
}
```

### RAG that respects who can see what
URL: https://ecorpin.com/insights/rag-that-respects-access
Published: 2026-09-06 | Topic: AI | Read Time: 3 min read

Internal search over wikis, tickets, and code only helps if answers stay inside existing access controls. Generic chat wrappers skip that step and hallucinate on top.

#### The wrapper problem
Teams lose hours hunting across wikis, tickets, and repositories. Dropping a chat box on a dump of those sources looks like progress. It is not, if the model can retrieve a document the asker is not allowed to open.
Hallucinations are a quality problem. Leaking a restricted runbook is an access problem. We treat them separately.

#### Retrieve inside the same rules
We index the sources that matter and retrieve with hybrid search — keywords for identifiers, vectors for phrasing. Filters on the retrieval query reuse the identity and roles you already have, rather than inventing a second permission system for the model.
Answers stay tied to citations. If a chunk cannot be shown, it is not retrieved. The model does not get a secret “for context.”

#### Measure instead of demo
We score retrieval and refusal: did we find the right source, did we stay silent when we should have, did the citation match the claim. A demo that answers everything is usually a system that answers too much.
This is the access-aware RAG approach we use on internal knowledge systems.

**Code Pattern (access-aware-retrieval.ts):**
```typescript
// Pattern: Access-aware hybrid retrieval filter
interface SecureRetrievalQuery {
  readonly userContext: { id: string; roles: string[]; tenantId: string };
  readonly searchFilter: {
    securityLabels: { $in: string[] };
    aclGroups: { $in: string[] };
  };
  readonly hybridWeights: { bm25: 0.4; denseVector: 0.6 };
  readonly citationRequired: true;
}
```

### Pipelines when the warehouse job cannot keep up
URL: https://ecorpin.com/insights/pipelines-beyond-the-warehouse-job
Published: 2026-09-06 | Topic: Data | Read Time: 4 min read

Fleets, devices, and plants produce more events than a nightly warehouse load can absorb. Alerts arrive late or not at all. Streaming and an operator-facing store close that gap.

#### Batch is the wrong clock
A warehouse job that lands every few hours is fine for finance close. It is the wrong clock for a plant, a device fleet, or an operations team that pages on symptoms.
When ingest falls behind, the dashboard still looks calm. The incident is already old.

#### Buffer at the edge, stream the rest
We put a buffer next to the source so a network blip does not drop the last hour. A streaming path carries events into a time-series or columnar store operators can query without waiting for the warehouse model to finish.
The warehouse can still exist. It just stops being the only place the truth shows up.

#### Dashboards that match how the team works
Alerts should page on symptoms the on-call already understands, not on every noisy gauge. Dashboards follow the same runbook language: what is broken, what is delayed, what can wait until morning.
That is the operations and telemetry pattern: pipelines, a store you can query, and views that match the work.

**Code Pattern (telemetry-stream-topology.ts):**
```typescript
// Pattern: Edge-buffered streaming with queryable time-series store
interface TelemetryStreamTopology {
  readonly edgeBuffer: 'Disk-backed ring buffer with automatic catch-up';
  readonly streamBus: 'Kafka partitioned by deviceId / plantZone';
  readonly queryStore: 'ClickHouse columnar table (sub-20ms query latency)';
  readonly alertPipeline: 'P99 detection latency < 1.5s on symptom thresholds';
}
```

### Cookieless ingest with bot discipline
URL: https://ecorpin.com/insights/cookieless-ingest-with-bot-discipline
Published: 2026-10-23 | Topic: Data | Read Time: 4 min read

Product analytics without cookies or stored raw IPs: daily hashed session ids, bot labeling at the edge, and plan-gated acceptance — so dashboards measure people, not scrapers.

#### Drop the raw IP at the edge
The collector hashes project, UTC day, IP, and user agent into a session id, resolves a coarse country and city, then discards the raw address. Nothing downstream — queue, store, or live feed — ever sees it.
The browser keeps a visitor id in local storage, not a cookie. Identification stays first-party: the operator runs the collector and the data stays in their database.

#### Label bots before they pollute the dashboard
AI crawlers and scrapers fetch pages like readers but behave nothing like them. A substring list over the user agent labels them at ingest, and the dashboard can include or exclude them per view.
Labeling early keeps every later aggregate honest. Filtering at query time cannot recover a pipeline that never recorded what was a bot.

#### Gate by plan without lying to the sender
Events a plan does not allow are answered with success and quietly not enqueued. The sender never retries a storm, and the operator never stores what was not paid for.
This is how FluxTrace handles analytics ingest: edge discipline, an honest status code, and storage that matches the entitlement.

**Code Pattern (cookieless-collect-gate.ts):**
```typescript
// Pattern: Cookieless collect gate with edge bot labeling
interface CollectGate {
  readonly sessionId: 'HMAC(projectId, UTC day, IP, userAgent)';
  readonly storeRawIp: false;
  readonly visitorKey: 'localStorage id, never a cookie';
  readonly botLabels: ['GPTBot', 'ClaudeBot', 'CCBot', 'generic bot/spider/crawler'];
  readonly overPlanBehavior: 'HTTP 204 accepted, event not enqueued';
}
```

### Guarded strategy execution for retail trading automation
URL: https://ecorpin.com/insights/guarded-strategy-execution
Published: 2026-10-23 | Topic: Architecture | Read Time: 5 min read

Condition-based buy and sell automation only survives contact with a live broker when evaluation, credential lifecycle, and order placement are separate concerns with explicit risk gates.

#### Evaluate conditions, then decide separately whether to trade
A condition evaluator that only answers true or false over a market snapshot is easy to test: feed it candles and positions, assert the verdict. It never touches the broker, so a test can never move money.
A separate executor takes a true verdict through risk gates — position caps, a daily loss limit, a kill switch — before placing anything. Most blown-up bots fail here: evaluation and execution fused into one function with no place to say no.

#### Treat broker credentials as a lifecycle, not a string
Retail broker API tokens expire — daily, in the small hours — and re-approval is part of the job. The app supports direct tokens, key-plus-secret approval, and key-plus-TOTP so a morning expiry is a routine refresh, not an incident.
Credentials live server-side behind the executor. The frontend never holds broker secrets; it manages strategies while the backend owns the keys.

#### Paper first, with the same gates as live
Paper mode runs the identical evaluate-and-authorize path against a ledger instead of the broker. A strategy that trips the kill switch on paper would have tripped it with money attached.
This is how Strategy Algo engine applies the financial-platforms discipline to retail automation: explicit boundaries, staged rollout, and one source of truth for what moved.

**Code Pattern (strategy-execution-gate.ts):**
```typescript
// Pattern: Evaluate conditions separately from placing orders
interface StrategyExecutionGate {
  readonly evaluate: 'Pure condition check over market snapshot (no side effects)';
  readonly authorize: 'Risk gates: position caps, daily loss limit, kill switch';
  readonly place: 'Broker order only after evaluate AND authorize pass';
  readonly credentialModes: ['access-token', 'api-key-secret', 'api-key-totp'];
  readonly paperVsLive: 'Identical gates, live broker replaced by a ledger';
}
```

### Voice agents over clinical systems without coupling to them
URL: https://ecorpin.com/insights/adapter-isolated-clinical-voice
Published: 2026-10-23 | Topic: AI | Read Time: 4 min read

An AI phone receptionist that books against a practice-management system stays shippable when a narrow adapter isolates the chart, voice is swappable, and only verified destinations ever ring for real.

#### Put the chart behind a port
Voice tools — find, book, confirm, cancel, eligibility — call a small adapter interface, never the chart directly. A local mock mirrors the real field names, so every flow runs end to end with no third-party keys.
Going live swaps one implementation: the same calls hit the real practice-management API. Routes, prompts, and the dashboard never change, because they never knew which side of the port they were on.

#### Swap the voice without touching routes
A tiny provider interface sits between the app and telephony: place calls and send texts through it, and keep a mock that writes scripted transcripts to the database. Without carrier keys the whole product still demos — every call, text, and booking lands in the store.
A demo safety rule is enforced in code, not in a runbook: real calls and texts only ever go to a verified demo number. Every other patient stays simulated, with a transcript written so the dashboard still looks alive.

#### Stream every write to the ops room
Each booking, verification, and message emits an event through an in-process bus, persisted to an events table and streamed to the dashboard over server-sent events. KPIs move while the call is still happening.
That is the healthcare-data discipline applied to voice operations: ingestion, access, and audit designed around the data’s sensitivity.

**Code Pattern (clinical-voice-ports.ts):**
```typescript
// Pattern: Narrow ports around the chart and the voice
interface PMSAdapter {
  readonly findPatient: '(name, phone) => chart record';
  readonly slots: '(provider, day) => bookable times';
  readonly book: '(patient, slot) => appointment with audit entry';
}
interface VoiceProvider {
  readonly placeCall: '(to: VerifiedNumberOnly) => call handle';
  readonly simulate: '(scenario: string) => scripted transcript in DB';
}
```

### Public intake with create-only keys
URL: https://ecorpin.com/insights/public-intake-with-create-only-keys
Published: 2026-10-23 | Topic: Security | Read Time: 3 min read

A marketing site that files structured inquiries into internal operations without exposing them: a scoped gateway, per-IP rate limits, and a mail fallback that admits it is unconfirmed.

#### Scope the browser key to one mutation
The public site ships with a key that can create inquiries and nothing else — no listing, no editing, no access to other resources. Roles stay on the server, where they can be enforced rather than hoped for.
The internal key never enters the browser bundle. Two keys, two trust zones, and a gateway that treats the public one as hostile input with a single allowed verb.

#### Rate-limit the public path, not the internal one
Public-key inquiry creation is throttled per IP while internal SDK traffic keeps its normal limit. Abuse of the form cannot starve the operations the business runs on.
Validation mirrors the split: inline field errors for the visitor, schema validation on every API input server-side. The browser is a convenience, never the enforcer.

#### Admit what the fallback cannot confirm
When the gateway is unreachable, the site falls back to opening a mail draft — and says plainly that receipt is unconfirmed until the visitor sends it. A successful submit, by contrast, confirms receipt and explains the three-step follow-up.
That is the FirmOps pattern we run ourselves: the website writes records, not emails, and every fallback is honest about what it guarantees.

**Code Pattern (scoped-intake-gateway.ts):**
```typescript
// Pattern: Browser-visible key scoped to one mutation
interface ScopedIntakeGateway {
  readonly publicKey: 'Creates contact inquiries. Lists nothing, edits nothing.';
  readonly internalKey: 'Full SDK access, server-side only, never bundled';
  readonly publicLimit: '10 requests per minute per IP (public key only)';
  readonly fallback: 'mailto draft shown as unconfirmed until sent';
}
```

## Technology Stack & Architectural Standards
- **React / Next.js** (frontend): Product UIs, marketing sites, and server-rendered apps. *Engineering note:* Server components, fast hydration, and zero layout shift. Built for high-intent web apps.
- **TypeScript** (frontend): Typed contracts across product UIs, Node services, and BFF layers. *Engineering note:* Strict type safety from database queries to the client. Keeps runtime errors out of production.
- **Tailwind CSS** (frontend): Utility-first styling for design systems and fast iteration. *Engineering note:* Design tokens in markup without runtime CSS overhead or style collisions.
- **React Native / Expo** (frontend): Cross-platform mobile apps sharing logic with the web. *Engineering note:* Business logic shared between web and mobile instead of written twice.
- **Go** (backend): Services, gateways, and operational tooling. *Engineering note:* Single static binary, fast startup, and dependable concurrency.
- **Python / FastAPI** (backend): APIs, data jobs, and AI inference services. *Engineering note:* Type hints meet async event loops. Our favorite bridge for AI models.
- **Node.js** (backend): BFF layers and TypeScript services next to the product. *Engineering note:* High-throughput non-blocking I/O that lives right beside product teams.
- **Kafka** (backend): Event streams between services when a queue is not enough. *Engineering note:* Partitioned, replayable logs for high-volume event streams.
- **ClickHouse** (backend): Analytical queries over high-volume operational data. *Engineering note:* Columnar aggregations over large event volumes that operators can query interactively.
- **PostgreSQL** (backend): Primary relational store, including pgvector when needed. *Engineering note:* ACID transactions with pgvector. The Swiss Army knife that never lets you down.
- **Redis** (backend): Caching, locks, and short-lived coordination. *Engineering note:* In-memory caching and distributed locking primitives.
- **Kubernetes** (cloud): Container orchestration for services that need it. *Engineering note:* Declarative reconciliation loops. Overkill for small apps, essential at scale.
- **Terraform / OpenTofu** (cloud): Declarative infrastructure across cloud accounts. *Engineering note:* Reproducible cloud estates without manual console drift.
- **AWS / GCP / Azure** (cloud): Cloud platforms chosen to match the team's existing footprint. *Engineering note:* Multi-region resilience, private VPC peering, and least-privilege IAM.
- **GitHub Actions / ArgoCD** (cloud): CI and GitOps delivery with staged environments. *Engineering note:* GitOps workflows where git commits directly drive verifiable production state.
- **Prometheus / Grafana / OTel** (cloud): Metrics, dashboards, and distributed tracing. *Engineering note:* High-cardinality metrics and distributed traces. Spot bottlenecks before users notice.
- **LangChain / LlamaIndex** (ai): RAG and agent orchestration over private data. *Engineering note:* Deterministic retrieval pipelines with strict latency and token budgets.
- **pgvector / Qdrant** (ai): Vector search next to, or instead of, a separate vector SaaS. *Engineering note:* Hybrid dense + sparse embedding search right inside your operational store.
- **OIDC / OAuth** (security): SSO and delegated identity for products and internal tools. *Engineering note:* PKCE flows, role-based claims, and seamless enterprise identity integration.
- **Vault / cloud KMS** (security): Secrets and key management with rotation. *Engineering note:* Envelope encryption with automated secret rotation and no hardcoded credentials.
- **OPA / policy as code** (security): Authorization rules that live next to the services they protect. *Engineering note:* Decoupled authorization policies evaluated next to each service.

## Frequently Asked Questions
### What does Ecorpin build?
Product platforms, cloud infrastructure, and enterprise AI systems, for client companies and for our own products, FirmOps and FluxTrace.

### Who owns the code and infrastructure?
You do. The code, infrastructure, and IP we deliver belong to you, and work lands in your repos from day one. Nothing is held behind a proprietary platform.

### How quickly will Ecorpin respond?
Reply within one business day. Email support@ecorpin.com or send an inquiry on the site.

### Where is Ecorpin based, and which time zones do you cover?
Ecorpin is headquartered in India and serves clients across North America, Europe, the United Kingdom, Asia, China, Australia, and South Africa, with agreed overlap hours for each engagement.

### How do you price engagements?
Assessments are fixed-scope. Delivery programs are priced per milestone, and managed platforms run on an ongoing service agreement. Every proposal states scope and commercials before work starts.

### Will you sign an NDA?
Yes. We sign mutual NDAs before discovery as standard, and can work on your paper or ours.

### How soon can you start?
The proposal confirms the team and start date. Assessments usually begin sooner than full delivery programs.