Infrakinetic

Overview

Infrakinetic runs an entire company on one system. Where a typical business stitches together a CRM, an ERP, accounting, HRMS, payroll, an applicant tracking system, document management and a workflow tool, Infrakinetic replaces the stack with 29 engines on one governed platform. They share one identity, one approval system, one event log and one audit trail.

A deal won in Sales can start onboarding, raise the invoice and post to the ledger without anyone re-keying it. Every approval, handoff and intervention along the way stays on record, not just the final transaction.

I designed it, from the architecture and security model to the product and interface of every engine, and built it with Claude writing the code. It runs in production in early access, and launches publicly on 22 October 2026.

PausePlay

What’s inside

Area	Engines
Revenue	Commercial, Sales, Customer Success, Marketing, Marketing Agency, Partnerships
Money	Billing, Payments, Finance
People	HR, Recruitment, Workforce, Payroll, Performance, Equity
Work and control	Governance, Approval, Workflow, Tickets, Automation, Documents
Intelligence	Analytics, Command, Intelligence, Research, AI
Platform	Migration, Operations, Technology

A few of the things this makes possible:

• A tamper-evident ledger. Every financial entry is append-only and SHA-256 hash-chained to the previous one, so any edit to history is mathematically detectable.
• Indian statutory payroll. Formula-driven pay components, PF, ESI and TDS compliance tracking, payroll runs locked once final, and every payslip traceable to the exact formula version and statutory summary behind it.
• Hiring that doesn’t filter people out. An applicant tracking system that reads what a job actually requires using the ESCO and O*NET skills taxonomies, never rejects anyone over a missing keyword, explains every recommendation, and gives each employer a careers site in their own brand.
• Legal-grade documents. Generation, OCR and structure extraction, and PAdES digital signatures through a provider-neutral document engine.
• Governed migration from legacy systems. Connectors for Salesforce, Zoho, HubSpot and Tally, plus a ten-step pipeline that maps, stages, reconciles and verifies before anything goes live.
• AI under control. Models draft, read and route, but can never post money, change employment or approve anything themselves.

The problem

Most organisations run on disconnected systems. Revenue work starts in one tool and delivery starts in another. Approvals behave differently in finance, HR and operations. Organisational structure lives in slides rather than in the logic that routes decisions. Hiring, payroll and performance don’t share a record of the same person. Financial history can be edited quietly. Leaders look at reports detached from the workflows that produced them.

Each of those gaps loses context: who decided what, under which rules, with what information. Infrakinetic is built to keep that context.

Constraints

• Multi-tenant from day one. Many organisations share one schema, so isolation has to be guaranteed by the database, not just by careful application code.
• Financial integrity. Ledger history must be tamper-evident and auditable, not merely access-controlled.
• Regulatory reality. Indian statutory payroll (PF, ESI, TDS) and DPDP 2023 data-protection obligations, including erasure without destroying statutory records.
• One product, many owners. A unified experience without letting every module read and write every other module’s data.
• AI without loss of control. Model output must never directly post money, change employment or decide an approval.

My role

I engineered the platform. The system design, architecture, ownership and security models, infrastructure, deployment and production certification are mine, as is the product design and UI/UX, and the rectification programme that turned an early, loosely bounded codebase into independently owned engines. The code is written with Claude, working to that architecture. As CEO I also set the product direction.

Reasoning and architecture

The central decision was to make Infrakinetic a shared-schema, multi-tenant modular monolith with independently owned engines. That sits between a microservice estate, which is too much operational surface for the stage, and a free-for-all monolith, where any module can mutate any table.

1. Platform governance and provisioningRoot operator plane: commissioning tenants, policy, quotas. A separate application with its own security boundary.
2. Unified engine control planeEntitlements, team access and navigation for every engine.
3. Domain and platform enginesCommercial, Sales, Customer Success, Billing, Payments, Finance, six People engines, Marketing; plus Tickets, Workflow, Approval, Automation, Documents, Migration.
4. Contract and wiring planePublic APIs, commands, events, transactional outbox and inbox, producer-owned projections.
5. Tenant-isolated PostgreSQLOne schema, Row-Level Security forced on every tenant-scoped table.

Ownership is a hard line. Exactly one engine owns each writable business record and the rules that govern it. Another engine may not write that record, or even read its private tables to decide something. It goes through the owner’s public contract. Analytics consumers read producer-owned projections instead of private tables. Boundary tests keep it that way.

Billing, Payments and Finance are separate on purpose. Billing owns invoices and collection. Payments owns provider connections, attempts and settlement. Finance owns journals, the ledger and reconciliation. A payment webhook is treated as an observation to verify, not as accounting truth.

The people domain is six engines, not one HR blob: HR, Recruitment, Workforce, Payroll, Performance and Equity, because they have different owners, rules and access needs.

Implementation

Isolation in two independent places. Every tenant-facing query is scoped in the application and again by PostgreSQL Row-Level Security with FORCE RLS. The application connects as a least-privilege role that cannot bypass RLS. A separate privileged role handles bounded cross-tenant work and hands execution back to the normal RLS path. A forgotten filter in code still can’t leak another tenant’s data.

Money is append-only. Ledger entries are never edited or deleted. Each is SHA-256 hashed and chained to the previous one, so tampering is detectable, and reversals are new offsetting entries. Payroll runs are locked by trigger once finalised, and salary structures are versioned, so every payslip can be traced to the exact formula that produced it.

One approval engine for everything. Leave, expenses, budgets, requisitions and contracts route through the same rule-based approval engine, with SLA tracking and escalation, and governance-aware routing that knows when a decision belongs to a board.

Events drive automation. Business events such as a deal won, leave approved or an employee hired are logged and trigger workflows, so a closed deal can start onboarding without someone emailing someone else.

Governed data migration. Legacy onboarding is a ten-step governed pipeline, not a bulk import.

1. Prepare
2. Upload and scan
3. Confirm scope
4. Map
5. Resolve
6. Dry run
7. Approve
8. Migrate
9. Reconcile
10. Verify

Mapping combines a field registry, source profiling and statistical similarity, with optional model-assisted review. Staged data stays apart from production until readiness and approval pass, and historical imports never fire live business automations. Connectors exist for Salesforce, Zoho, HubSpot and Tally.

AI as a governed execution plane. All model calls go through one capability boundary with metering, quotas, evidence logging and human-review policy. AI drafts SEO fixes, reads vendor bills through a layered OCR pipeline, and assists routing. It proposes; the owning engine validates and applies.

Documents run on a provider-neutral contract over containerised services for conversion, OCR, structure extraction and PAdES digital signatures.

Evidence and outcomes

• Tenant isolation: the production certification check passed on 468 of 468 tenant-scoped tables.
• Migration at scale: 107,114 records migrated from a 900,000-cell connected dataset with zero execution failures.
• Architecture: a twelve-phase rectification programme, with domain engine boundaries certified against source and tests, and architecture-conformance checks in CI.

Every claim in Infrakinetic’s own documentation is labelled by evidence level (implemented, source-certified, deployed, runtime-verified, browser-verified). I hold this page to the same standard.

Verdict

• Keep: one owner per business record, enforced through public contracts and boundary tests. It’s the reason a 29-engine platform can still change safely. Also the evidence vocabulary that keeps built, deployed and proven in production apart.
• Change: draw the ownership map before the second engine exists. Building fast and rectifying afterwards worked, but a twelve-phase programme is an expensive route to boundaries that could have been set on day one.
• Next: the Migration Engine’s scale roadmap, with million-row packages, resumable uploads and horizontally scaled workers.