AWS Predictive Finance MIS App

Project Brief: Full-Stack Engineer — Enterprise Planning & Forecasting (EPM) Platform, Production Build on AWS
Overview
We're building an Enterprise Performance Management (EPM) platform — budgeting, forecasting, scenario planning, and consolidation for finance teams — positioned to complement existing ERPs (SAP, Oracle, Dynamics, or others), not replace them. We pull in actuals from a client's system of record and provide the planning, forecasting, and scenario layer ERPs are typically weak at. Think Anaplan, Pigment, or Workday Adaptive Planning as the closest reference points, not SAP or NetSuite.
We have a validated, feature-complete working prototype (React/TypeScript frontend, Postgres/Supabase backend, an AI-grounded analytics copilot) and are rebuilding it as a production-grade, AWS-hosted platform with a dedicated backend, designed so each client's data can be isolated in its own environment.
Required skillsets
Frontend:
• JavaScript/TypeScript, React — extending an existing, data-dense codebase (editable grids, real-time computed values, dashboards, charting).
Backend:
• Python (FastAPI preferred) for the API layer.
• Strong Postgres schema design — versioned/audited data models, row-level access control.
• Experience designing per-tenant isolated deployments — each client's data in its own database instance (their own cloud account, or a dedicated instance we provision), never shared multi-tenant storage.
AI application layer:
• Tool-calling/function-calling architecture with LLMs (Claude or GPT-class APIs) — the AI must only ever answer from real database queries, with zero ability to fabricate data or write to financial tables.
• Comfortable designing guardrails: read-only tool scoping, full logging of every AI query/response, a hard boundary between what AI can read and what only an authenticated human action can change.
Core EPM functionality to build
• Approval workflows — submission → review → approval → lock, with role-based sign-off (not just binary lock/unlock).
• Planning-hierarchy RBAC — access scoped to a user's plant, region, or entity, with read-only visibility upward until a submission is approved.
• Multi-entity consolidation with intercompany eliminations, and FX translation at the consolidation layer (local-currency plans rolling up into a group reporting currency).
• ERP/accounting-system actuals-ingestion connectors (starting with Tally/Zoho Books; SAP/Oracle-compatible ingestion for larger clients) — this is the platform's core integration point, not a peripheral feature.
• Planning submission calendar — open/close windows per budget or forecast cycle, with reminders to contributors ahead of deadlines.
Data & cost-efficiency requirements
• Efficient batch/incremental data ingestion pipelines for financial/ERP-sourced data, optimized for AWS cost — serverless/scale-to-zero patterns (Lambda, Aurora Serverless) where the workload genuinely fits, avoiding always-on over-provisioning.
• Architecture must keep per-client operational cost low and predictable — this product is explicitly positioned against expensive, heavy enterprise tooling; infrastructure cost directly affects whether that positioning holds.
Deployment model
• Every client gets an isolated data environment — their own cloud account, or a dedicated instance we manage — never shared multi-tenant hosting.
• Infrastructure as Code (Terraform or CloudFormation) so new client environments provision repeatably.