Until this phase, everything existed in controlled environments.
The frontend was polished.
The backend was tested.
CI pipelines were validating changes.
But none of that matters unless users can access it.
Deployment is where engineering meets reality.
Phase 6 was not just about pushing code to the internet.
It was about making architectural decisions that would sustain the system in production.
Day 19 — Strategic Deployment Decisions
The first task wasn’t deployment itself.
It was synchronisation.
The frontend and backend had been developed independently with clean boundaries. Now they needed to speak to each other over real networks, not local mocks.
API calls were reviewed and synchronised.
Response formats were aligned.
Error structures were validated end-to-end.
Only after confirming contract stability did infrastructure decisions begin.
The frontend was deployed on Vercel.
The backend was deployed on Render.
This wasn’t random.
Vercel was chosen because:
- It provides seamless static + React deployment.
- It integrates directly with Git-based workflows.
- It supports environment variables cleanly.
- It offers automatic builds and previews per commit.
For a React-based frontend architecture with structured API hooks, it was a natural fit.
Render was selected for the backend because:
- It supports Flask deployments smoothly.
- It offers managed web services without heavy infrastructure overhead.
- It handles environment variables securely.
- It provides auto-deploy from Git branches.
- It simplifies containerised deployment flows.
The key principle was simplicity with scalability.
The goal was not enterprise Kubernetes orchestration.
The goal was reliable, production-ready hosting aligned with the project scope.
Day 20 — Integration, Production Readiness & Developer Experience
Deployment is rarely just "push and done".
Integration required replacing static JSON consumption with live API calls. Hooks were updated to fetch real-time data from deployed endpoints. This validated the full production loop:
Frontend → Deployed Backend → Service Layer → Repository → Response → UI
Environment variables were updated inside .env.production to point to live backend URLs. This is where environment-based configuration proved valuable. The architecture built in Phase 4 made this transition smooth.
No refactoring.
No patching.
Just a configuration change.
The project was added to Vercel for automated builds and deployments. Every commit now triggers a deployment cycle. The CI workflows created in Phase 5 were also updated to reflect live API validations.
But production readiness is not just about running code.
It is about maintainability.
On this day:
- CONTRIBUTING.md was added to define contribution guidelines.
- CODE_OF_CONDUCT.md established community standards.
- The README was expanded and polished.
- Badges were added to reflect build status.
- Issue templates were created.
- Pull request templates were introduced.
This transforms a personal project into a collaborative-ready repository.
A repository without documentation is a code dump.
A repository with contribution standards is an open system.
The CI YAML files for both frontend and backend were refined to align with updated API flows, ensuring that integration changes did not break automated testing.
At this point, the system wasn’t just deployed.
It was structured, documented, automated, and production-accessible.
The Result — A Live, Fully Engineered Portfolio
The project is now live:
👉 https://sushantgaurav-portfolio.vercel.app/
What began as structured JSON files evolved into:
- A modular React frontend
- A layered Flask backend
- Pydantic validation
- Structured logging
- Comprehensive testing (unit + integration)
- Continuous Integration pipelines
- Environment-aware configuration
- Production deployment
- Contribution-ready repository structure
This is no longer just a portfolio.
It is a full-stack system built with layered architecture, validation discipline, testing rigor, and automated deployment.
What Phase 6 Represents
Deployment is often seen as the final step.
But in reality, it is proof.
Proof that:
- The architecture was clean enough to scale.
- Configuration was environment-driven.
- Testing was reliable enough to trust.
- CI was mature enough to enforce discipline.
- Documentation was complete enough for collaboration.
Every previous phase enabled this one.
Without a layered backend design, deployment would be messy.
Without testing, deployment would be risky.
Without CI, deployment would be fragile.
Phase 6 is where all previous engineering decisions justified themselves.
Closing This Series
This article series began with structured planning and ended with a live, production-ready system.
Across six phases, this journey covered:
Architecture.
Backend engineering.
Testing discipline.
Automation.
Deployment strategy.
Documentation.
It wasn’t just about building a portfolio.
It was about building it the right way.
If you’re following along, the complete source lives here:
👉 GitHub Repository: Portfolio.
And this series concludes here.
But the journey doesn’t.
I’ll soon be back with a new article series — diving deeper into another engineering build, exploring a new system, and pushing architectural depth even further.
Until then — build thoughtfully, test rigorously, deploy confidently.
Top comments (0)