Fintech Platform Risk Diagnosis & Architecture Assessment

SPRINT 0 — Fintech Platform Risk Diagnosis & Architecture Assessment 10 Hours — Fixed Price (Project-Based) ACCESS & RULES OF ENGAGEMENT (Zero Trust) Read-only access to AWS, GitLab, and Sentry (Reporter/Member). Credentials shared via a secure Privnote link in Upwork chat. Because there is no reliable staging environment today, the following are strictly out of scope for Sprint 0: - No production changes - No production deployments - No infrastructure modifications - No credential rotation - No code merged into production - No direct database modifications If you want to demonstrate a potential solution, you're welcome to prepare an isolated Pull Request, proof of concept, or written proposal — nothing gets merged or deployed during Sprint 0. If you discover an active critical vulnerability during the assessment (exposed production credentials, a severe data-integrity risk, anything actively exploitable), notify me immediately rather than waiting for the final report, and do not attempt unauthorized remediation. OBJECTIVE Sprint 0 is not about fixing the platform. It's about understanding the real architecture, identifying the highest-risk issues, evaluating current engineering practices and maintainability, and handing back a complete, budgeted roadmap for the real fix. This is meant to identify the highest-risk issues, not to perform an exhaustive audit of every component. One non-negotiable principle for that roadmap: once remediation is complete, the platform should run safely and be maintainable by a competent mid-level engineer day to day. Senior involvement should only be needed for architecture calls, exceptional incidents, or genuinely complex decisions — not for routine operation. Sprint 0 is successful if, by the end of it, I have enough information to confidently decide whether to proceed with remediation, estimate its cost, and define the engineering model going forward. PHASE 1 — Context & System Understanding (~5 hours) Guided walkthrough with the current developer covering: overall application architecture, the loan lifecycle, the disbursement workflow, recent architectural decisions, the deployment process, production operations, CI/CD workflow, and monitoring practices. Use this session to understand both the system and the reasoning behind recent engineering decisions. PHASE 2 — Technical Audit & Business Risk (~5 hours) Validate what you hear in Phase 1 against the actual implementation. If you find something more critical than what's listed below, reprioritize and explain your reasoning. 1. Disbursement recording (top priority) The actual bank transfer is manual. The system only records the loan as disbursed afterward. Determine exactly what happens when that "mark as disbursed" step runs — status updates, notifications, ledger entries, accounting events, downstream integrations, queue jobs, background workers, audit logs. Then evaluate the justifications on record for the real, recurring failures here: a DB error described as "it times out and re-executes itself," and a TypeError/500 crash described as caused by "missing client data." Determine whether either explanation is technically valid, whether the process is actually idempotent, and — if retries do occur — whether they could generate duplicate business events. 2. Database performance N+1 query on the OTP endpoint, general query efficiency, indexing strategy, lock contention if time permits, and any other long-running queries you identify. Determine whether the existing fixes are structurally correct. 3. Security baseline (document, don't patch) APP_DEBUG status, exposed secrets in Git history, chmod 777 usage, file permissions, environment variable handling. 4. Production access model Document what's actually accessible today: AWS IAM, SSH, GitLab permissions, database access, deployment permissions. This becomes the baseline for the least-privilege model in the roadmap. 5. Operational resilience (if time allows) Backup configuration and whether restores actually work (no restore test yet — just confirm it's configured and running), plus a quick read on logging, monitoring, and alerting maturity. 6. Anything else If you find a bigger risk than what's listed here, prioritize it and tell me why. DELIVERABLES (one executive report — PDF, Notion, or Google Doc) PART A — ASSESSMENT 1. Engineering Capability & Role Recommendation Assess the current engineering practices, code quality, decision-making, and maintainability of the platform, based on what you find in the code and the walkthrough. Based on that evidence, tell me clearly whether the right path forward is full-time, limiting the current developer to specific tasks only, or replacement. Support your recommendation with concrete technical findings and examples from the assessment. 2. Platform Risk Assessment Is the platform safe to operate today? For each critical risk you find: business impact, likelihood, and recommended priority. PART B — RECOMMENDATIONS 3. Remediation Roadmap, Hours & Cost, and "Junior-Proofing" — the deliverable I care about most For the 3-5 highest-priority critical items: problem, proposed solution, alternatives considered, trade-offs, recommended approach, effort estimate, acceptance criteria. For everything else, a shorter treatment is fine — problem, priority, and rough effort. This roadmap has one non-negotiable goal: once it's implemented, the system runs safely on its own, without creating a new dependency on you for day-to-day work. It needs to specifically cover: - Infrastructure & DevOps: eliminate standing SSH access to production entirely for the current developer — not just "routine" access, all of it, so a chmod 777 mistake becomes structurally impossible. Least-privilege AWS IAM. Secrets in AWS Secrets Manager (or equivalent), not .env files. - GitOps & CI/CD: protected main branch, mandatory PRs, required approvals, automated deployment pipeline, zero direct production deployments — no exceptions, including admin accounts. - Static analysis & AI review: an automated layer (tools like Codium, Sweep, SonarQube, or equivalent) that catches N+1 queries, mass assignment, exposed credentials, and other security regressions before anything needs human eyes. Provide an example GitLab CI configuration or proof of concept demonstrating how this could be implemented. - Documentation: enough for a different senior engineer to pick this up without relying on tribal knowledge — the goal is a system that isn't dependent on any one person. - Two numbers: estimated hours/cost to implement all of this, and your own estimate of ongoing monthly maintenance hours once it's stable. This roadmap, including that estimate, becomes our shared reference point for scope and hours going forward. - Expected role after stabilization: catastrophic incident response, architectural guidance, occasional review of unusually complex PRs, and periodic audits. Daily operations should not require you. LOGISTICS Two continuous working blocks (~5 hours each), not scattered hours. Final report in PDF, Notion, or Google Doc.