Technology
Our production technology stack
We use proven, flexible technologies built for security and performance.
What is in the ERPStack technology stack?
In short: the ERPStack production ERP technology stack is Next.js, React and TypeScript on PostgreSQL, deployed to AWS or Microsoft Azure with Terraform. 24 components in 6 categories, every one open source or a commodity cloud service, with Semgrep SAST and OWASP ZAP running in CI so the system stays SOC 2-ready.
The full component set
React, TypeScript, Tailwind CSS, shadcn/ui and Radix UI on the front end; Node.js with Drizzle ORM or Prisma ORM and Zod on the server; PostgreSQL, MongoDB Atlas and Redis for state; AWS or Microsoft Azure provisioned with Terraform, Docker, Kubernetes and GitHub Actions; Sentry, Semgrep SAST and OWASP ZAP for security; Vitest, Playwright and Storybook for verification. The ERP we hand over carries no proprietary runtime licence.
Frontend
5 components. React 19 and TypeScript 5 compile to one typed component tree, so renaming a PostgreSQL column surfaces as a build error rather than a blank panel. Tailwind CSS 4 styles it with zero runtime cost. shadcn/ui and Radix UI supply the primitives that are expensive to get right, dialogs, menus and comboboxes built to the WAI-ARIA authoring patterns, so keyboard and focus behaviour is never re-implemented per project. Next.js 16 renders the result on the server.
TypeScript
Tailwind CSS
shadcn/ui
Radix UI
Backend
4 components. Node.js runs the API. Drizzle ORM and Prisma ORM give typed SQL access to PostgreSQL with migrations under version control, so a schema change is reviewed as code. Zod 4 validates every REST request body, form payload and environment variable at the boundary, which means a malformed input fails at the edge of the ERP rather than 3 layers in, where the stack trace stops being useful. GraphQL is available where a client needs it.
Node.js
Prisma ORM
Drizzle ORM
Zod
Database
3 components. PostgreSQL is the default system of record: relational, ACID, and the only store most ERP and CRM workloads need, with Row-Level Security, JSON columns, full-text search and table partitioning built in. MongoDB Atlas holds document-shaped data where a rigid schema would fight the domain. Redis carries sessions, rate-limit counters and cache entries that expire on their own, typically inside 15 minutes.
PostgreSQL
MongoDB Atlas
Redis
Cloud
6 components. AWS and Microsoft Azure are both first-class targets, and the ERP deploys into your account rather than ours. Docker and Kubernetes package and schedule workloads that need long-running processes. Terraform declares every resource as version-controlled code, so an environment rebuilds from the repository in 1 command. GitHub Actions runs build, test and deploy on each merge, and blocks the merge when any of the 3 security scans fails or coverage drops below 80%.
AWS
Microsoft Azure
Docker
Kubernetes
Terraform
GitHub Actions
Security
3 components. Sentry captures runtime errors with release and user context, so a regression traces to the commit that shipped it. Semgrep SAST scans each pull request for injection, authentication and secrets-handling patterns before a human reviews it. OWASP ZAP runs a dynamic scan against a deployed preview, so findings come from a running system rather than a static read of the source. Secrets never enter the repository; AES-256 encryption at rest and TLS 1.3 in transit are the defaults.
Sentry
Semgrep SAST
OWASP ZAP
Quality
3 components. Vitest 4 covers units and integration boundaries. Playwright 1.59 drives real Chromium, Firefox and WebKit browsers through the flows a user performs, including SSO sign-in and checkout. Storybook isolates each component so states that are hard to reach in a running app, empty, error and loading, stay reviewable. No code reaches staging below the 80% coverage threshold, and the suite runs on all 3 engines before each deploy.
Vitest
Playwright
Storybook
Our Engineering Lifecycle
Phase 1Week 1
Architecture Review & Threat Modeling
We conduct thorough systems auditing, threat modeling, dependency mapping, and data flow modeling to capture your business logic constraints in writing before building.
Phase 2Weeks 2-3
Proof of Concept (PoC)
Using React Server Components, Drizzle ORM relations, and PostgreSQL, we build a working proof-of-concept of your most complex data models to prove performance targets.
Phase 3Months 1-3
Incremental Strangler Fig Migration
We employ a Strangler Fig progressive migration path, introducing request routing rules via API gateways or edge middleware to extract legacy monolith routines with zero downtime.
Phase 4Ongoing
Global Edge Deployment
We host production applications on low-latency Edge runtimes, backing them with read-replica database pools and cache sync engines to maintain sub-50ms visual response times globally.
Engineering principles
Type safety
We enforce strict type-safety across the entire transaction boundary—from database constraints and Drizzle schema structures down to client-side component state. This eliminates runtime failures, acts as living documentation, and gives external auditors a machine-checked trail instead of a promise.
Clean architecture
By isolating the database models, clean business logic interactors, and UI presentations, we restrict technical debt propagation. Changes to database keys or external payment gateways are isolated, preventing cascade regressions.
Continuous security scanning
We secure our application boundaries using Arcjet threat protection, Semgrep SAST pipelines, and GitHub Actions-integrated OWASP ZAP penetration testing. Continuous dependency monitoring detects vulnerabilities pre-merge, not post-deployment.
80%+ test coverage enforced
A comprehensive suite of unit tests, integration validation schemas, and Playwright end-to-end user path simulation scripts is verified in CI. No code reaches staging without meeting an 80%+ coverage threshold.
Immutable audit trails
Administrative mutations are routed through secure, tamper-evident audit logs on read-only cloud enclaves. This gives internal and external compliance audits immediate verification of system access history.
Infrastructure as code
Every infrastructure element—from PostgreSQL clusters to private VPC enclaves and Cloudflare cache rules—is provisioned using Terraform. This enables version-controlled, reproducible, and disaster-recoverable environments.
Type-Safe Everything
// End-to-end type safety from DB to UI
export const getUsers = async () => {
const data = await db.select().from(users);
return data; // Inferred as User[]
};How we measure the latency figures on this site
Every millisecond figure quoted across our service, industry and location pages is an engineering target for a system we have not built yet — not a measurement of your workload. Here is exactly what those targets assume, so you can hold us to them or dismiss them on the evidence.
- Workload
- A 25–150 seat mid-market deployment: indexed single-tenant reads returning under 50 rows, JSON payloads under 32 KB, warm connection pool. Analytical aggregates and unbounded reports are explicitly not covered by these numbers.
- Percentile
- p95 server-side, measured at the application boundary — after routing and authorisation, before the network. p50 is typically 2–4x faster; p99 is where the interesting failures live, and we will show you ours.
- What is excluded
- Client network transit, cold serverless starts, third-party API calls, and any query the client adds after handover. Anything crossing a vendor boundary is outside our control and outside the target.
- What we will prove
- Targets are written into the Statement of Work as acceptance criteria with the load-test script attached, and verified in your staging environment before the milestone is invoiced. A target we cannot demonstrate on your data is a target we do not get paid for.
Why is this technology stack deliberately small?
Because every extra tool is a hiring requirement, an upgrade path and an audit line for the team that inherits the ERP. 24 components across 6 categories is enough to build a multi-tenant system with SSO, RBAC and immutable audit trails, and small enough that 1 engineer can hold it in their head. 5 of the 24 are front-end, 4 back-end, 3 data, 6 cloud, 3 security and 3 quality. Where 2 tools overlap, such as Drizzle ORM and Prisma ORM, the choice is made per engagement and then held for the life of the system. Technical Debt in this stack is a decision, not an accident.
The same stack builds every engagement: custom ERP development, cloud migration and security and compliance engineering. To see how your current stack compares, run the Architecture Audit Grader or read the Systems Architecture Blueprint.
Questions about this technology stack
Why does ERPStack standardise on PostgreSQL rather than a proprietary database?
ERPStack anchors the production stack on PostgreSQL because it is relational, ACID-compliant, open source, and runs identically on AWS, Microsoft Azure or a laptop, so the ERP you own is not tied to 1 vendor's managed service. It supports Row-Level Security, JSON columns, full-text search and table partitioning natively, covering the workloads that would otherwise pull in 3 more products. Migrating away from it is a dump and a restore rather than a rewrite, which is the opposite of the SAP or Oracle NetSuite position.
Can we host this stack in our own AWS or Azure account?
Yes, and that is the default: this technology stack is designed to run in your account rather than ours. Infrastructure is declared in Terraform and applied to your cloud account, so the running ERP, the PostgreSQL database and the logs sit inside your boundary from day 1. AWS and Microsoft Azure are both supported, and a Docker or Kubernetes target works the same way. You keep the billing relationship, the AES-256 encryption keys and the audit trail; ERPStack uses only the access your team grants for the 8 to 20 weeks of the engagement.
What happens to this technology stack if we stop working with ERPStack?
Nothing breaks. Every layer of this technology stack — React, TypeScript, Node.js, PostgreSQL, Redis, Docker and Terraform — is open source or a commodity cloud service with a large hiring pool, and 100% of the code is yours with no runtime licence attached. There is no proprietary language such as ABAP or SuiteScript anywhere in the build, unlike SAP or Oracle NetSuite, so any competent engineering team can read it. Source code escrow is available for procurement teams that require it in writing.
How is security tested in this technology stack?
On every pull request and every deploy. Semgrep SAST scans the diff for injection, authentication and secrets-handling patterns before review. OWASP ZAP runs a dynamic scan against a deployed preview, so a finding comes from a running system. Sentry captures runtime errors with release context. Dependency vulnerabilities are checked pre-merge rather than after deployment, and all 3 scans run inside GitHub Actions with results attached to the pull request. RBAC and Row-Level Security are enforced in PostgreSQL rather than in the UI, so a frontend defect cannot widen access anywhere in the production stack.
Does this technology stack make our system SOC 2 or HIPAA certified?
No. Certification is issued by your auditor, against your scope, and typically covers a 3 to 12 month observation window. What the stack provides is the evidence an assessor asks for: Terraform state showing how infrastructure was provisioned, GitHub Actions logs showing what was tested and deployed, immutable audit trails of administrative actions, and RBAC enforced at the PostgreSQL layer. ERPStack builds systems designed to pass a SOC 2 Type II, HIPAA or ISO 27001 assessment and holds no certifications of its own.