Engineering process

How I work: from requirements to production

A detailed enterprise delivery workflow covering collaboration, technical decisions, validation, and release. The roles below describe shared team responsibilities.

This section documents how I work on real enterprise projects — from the moment a business idea is raised to the point where it goes live in production. Every phase, meeting, tool, and decision is covered. This is not theoretical; it reflects actual practice on a live production system.

Project context: A 3-tier enterprise tax application processing platform built to replace a legacy system. Stack — Next.js 16 / React 19 / TypeScript (Frontend), Node.js / Express.js (Middleware), .NET 8 / PostgreSQL (Backend). Deployed on AWS with Docker + Bitbucket CI/CD. Live in production.

Recurring Ceremonies (Throughout the Project)

Meeting	Frequency	Who	Purpose
Daily Standup	Every day (morning, 15 min)	Dev + QA + Tech Lead	Progress, blockers, what's done / next
Weekly Stakeholder Review	Every week	CTO + VP Product + Business Head + BA + Tech Lead	Sprint progress, demo, decisions, escalations
Sprint Planning	Every 2 weeks (sprint start)	Full team — Dev + QA + BA + Product Owner + Tech Lead	Plan and commit next sprint backlog
Sprint Review / Demo	Every 2 weeks (sprint end)	Full team + CTO + VP Product + Business	Demo completed features, get sign-off

Phase 1 — Business Requirements

Who: Client / Operations / Product Owner / Business Head
Where: Discovery sessions, workshops, regulatory review meetings
What: Identify pain points, capture new business needs, define scope boundaries, stakeholder sign-off
Output: Agreed Problem Statement + Scope Document

Phase 2 — BRD (Business Requirements Document)

Who: Business Analyst (BA), Product Owner, Compliance Team
What: BA documents functional + non-functional requirements, process flow diagrams, regulatory requirements
Sign-off: CTO + VP Product + Business Head review and approve
Output: Signed-off BRD
→ Weekly Stakeholder Meeting begins at this point

Phase 3 — Engineering Feasibility + POC

Who: Tech Lead, Solution Architect, Senior Devs, BA, DevOps
What: BRD walkthrough with engineering, stack compatibility, integration points, risk identification
POC built if approach is uncertain
Go/no-go presented to CTO + VP Product
Output: Engineering Feasibility Sign-off + Rough Effort Estimate

Phase 4 — User Story Creation in Jira

Who: BA (primary), Product Owner (review), Tech Lead (validation)
Format: 'As a [role], I want to [feature], so that [benefit]'
Each story includes: Acceptance Criteria, UI/UX wireframes, API contract, edge cases, dependencies
Stories linked to Epics in Jira
Output: Fully detailed Jira User Stories ready for sprint

Phase 5 — Sprint Planning

Who: Scrum Master, Product Owner, All Developers, QA, Tech Lead
When: Start of every 2-week sprint
What: Backlog prioritized, team capacity calculated, stories selected and assigned, sprint goal defined
Output: Committed Sprint Backlog with owners and timeline

Phase 6 — Task Estimation

Who: Developers (Frontend, Backend, Middleware), QA, Tech Lead
Sub-tasks per tier: Backend (Controller + Service + Repository + DB), Middleware (API route entry), Frontend (Component + Service + API registration), QA (test cases)
Story Points or hours assigned, Tech Lead validates
Output: Estimated sprint with committed effort per developer
→ Daily Standup begins at this point

Phase 7 — Sprint Kickoff + Development

Who: Frontend Dev, Backend Dev, Middleware Dev, DB Team
Feature branch created per story (feature/project-XXXX-name)
Tier 1 → Frontend (Next.js): UI components, service files, API registration
Tier 2 → Middleware (Node.js): JWT auth, rate limiting, proxy to correct backend
Tier 3 → Backend (.NET): Controller → Service → Repository → PostgreSQL stored functions
PR raised → Code review by Tech Lead → Merged to dev branch
Jira story status: To Do → In Progress → In Review → Done
Output: Working feature merged to dev branch

Phase 8 — Internal QA / Bug Fixing

Who: QA Engineers (testing), Developers (fixing), Tech Lead (triage)
QA writes test cases against acceptance criteria
Bugs raised in Jira with: steps to reproduce, expected vs actual, severity (Critical/High/Medium/Low), screenshot
Developer fixes → QA re-tests → closed
Regression testing on existing modules
Daily standup tracks bug count and closure rate
Critical bugs escalated to Tech Lead same day
Output: Stable tested build ready for UAT
→ Sprint Review / Demo to leadership at end of sprint

Phase 9 — UAT (User Acceptance Testing)

Who: Business Users, BA, QA, Developer (standby)
dev → uat branch promoted, deployed to UAT environment via pipeline
Business users test: happy path flows, edge cases, data accuracy, role-based access
Bugs and feedback → fixed → redeployed
UAT feedback reviewed in Weekly Stakeholder meeting
UAT sign-off from Product Owner + Business Head
Output: Formal UAT Sign-off

Phase 10 — CUG (Closed User Group)

Who: Select real users, Ops Team, Tech standby, BA
uat → master branch promoted, live to limited users
Real transactions monitored: performance, error logs, edge cases missed in UAT
Any issues → hotfix → redeployed same day if critical
CUG period: 1–2 weeks depending on module complexity
CUG sign-off from VP Product + Business Head
Output: CUG Validation Report + Sign-off

Phase 11 — Full Production Rollout

Who: DevOps, Tech Lead, Ops, Leadership (final approval)
Final go-live approval from CTO + VP Product
Docker deploy via master branch Bitbucket Pipeline
All users get access, go-live announcement sent
Operations team on standby for user queries
Output: Feature Live for All Users ✅

Phase 12 — Post Go-Live Support (Hypercare)

Who: Full team on standby — Dev, QA, BA, Ops, Tech Lead
When: First 24–72 hours after go-live
Production logs monitored continuously
Critical bugs → hotfix branch → emergency deploy
After stabilization: transition to BAU (Business As Usual) support
Output: Stable production, hypercare closed

Branch Strategy — Bitbucket (3 Repositories)

Same branch structure maintained across all 3 repos: Frontend (Next.js) + Middleware (Node.js) + Backend (.NET)

Branch	Purpose	Deploys To
`dev`	Active development — all feature branches merged here first	Dev environment
`uat`	Stable build — business testing	UAT environment
`master`	Production-ready code only	Production server

feature/project-XXXX-name → Pull Request + Code Review
dev — internal QA testing (promoted after QA sign-off)
uat — business UAT testing (promoted after UAT + CUG sign-off)
master — production deployment

CI/CD Pipeline per Branch

Branch	Steps	SonarQube	Trivy
`dev`	Docker Build → SonarQube → Deploy to Dev → Notify	Non-blocking (warnings only)	Not run
`uat`	Docker Build → Trivy → SonarQube → Deploy to UAT → Notify	Blocking — stops pipeline on failure	Blocking on HIGH/CRITICAL
`master`	Docker Build → Trivy → SonarQube → SFTP Transfer → Deploy → ALB Health Check → Cleanup → Notify	Blocking — zero exceptions	Blocking — zero exceptions

All 3 tiers built on every pipeline run: Frontend image + Middleware image + Backend API images
Deploy: docker save → SFTP transfer to server → docker load → docker-compose up -d
Health Check: AWS ALB confirms new container is healthy before routing traffic
Notifications: Google Chat webhook on build success ✅ or failure ❌
Rollback: edit IMAGE_TAG in remote .env → docker-compose down → up -d (~2–3 min recovery)

Security Implementation

Feature	Implementation
Authentication	JWT (8h expiry, stored in httpOnly cookie)
2FA	Second factor verification on every login
Encryption	AES-256-CBC for passwords and sensitive fields
Rate Limiting	60 requests/min via express-rate-limit
Security Headers	CSP, HSTS, X-Frame-Options via Helmet.js
Auto Logout	30-min idle timeout (react-idle-timer)
Cross-tab Logout	localStorage event sync across browser tabs
Session Management	Token stored in PostgreSQL, invalidated on logout
Non-root Docker	All containers run as appuser (not root)
CVE Patches	OpenSSL patched in Alpine Docker images
Vulnerability Scan	Trivy on every uat + master pipeline build
Code Quality	SonarQube quality gate blocks deploy on failure
VAPT Compliance	Fixes applied from formal penetration test report

Key Challenges Solved

PDF Worker Version Conflict — pdfjs-dist 3.11.174 used across two different rendering paths (CDN worker vs webpack import) — kept both working without breaking either.
JWT + Token DB Two-Layer Validation — Middleware issues JWT AND cross-checks it against PostgreSQL token store on every request — double-layer session security.
Single apiname Proxy Pattern — Frontend passes one apiname field — middleware routes it to the correct .NET service automatically. Frontend never knows backend URLs.
VAPT Security Hardening — Applied all findings from formal penetration test: httpOnly cookies, CSP headers, 30-min idle timeout, cross-tab logout sync, rate limiting.
Multi-role Privilege System — Each menu item has read/write/edit/delete/export flags controlled per user per product — resolved a runtime crash where NULL privilege flags broke Dapper mapping.

Note: This is a confidential internal enterprise project. No source code, live URLs, screenshots of real data, or sensitive credentials are publicly shared. All architecture and workflows represent technical implementation only.

See the project case studies →Discuss an engineering opportunity →