Agriha
Frontend engineering work for a near-MVP startup initiative. Built as the sole frontend engineer on a six-person team, working toward a production-ready MVP over approximately two months before the initiative wound down.
Overview
Agriha was a startup initiative led by seniors at my college. The team had six members across frontend, backend, design, and product. I joined as the only frontend engineer during my second semester and was responsible for the complete client-side implementation.
Development stopped before the MVP shipped when founders' priorities shifted, but the codebase reflects real production-oriented decisions: maintainable code, team Git workflow, performance practices, and pragmatic tradeoffs between ideal solutions and shipping.
Technical Stack
| Layer | Technology |
|---|---|
| Framework | React |
| Routing | React Router |
| State management | Context API / local state |
| Version control | Git (team workflow with branching strategy) |
| Package manager | npm |
Key Implementation Areas
Routing Multi-page routing with React Router. Route structure designed around the product's core user flows with protected routes where authentication was required.
Performance
Lazy loading applied to route-level components using React.lazy and Suspense, reducing initial bundle size. Component-level code splitting for heavier UI sections.
Rendering Deliberate decisions around when to use client-side rendering versus static rendering for different page types based on data freshness requirements and SEO considerations.
Code organization Component structure designed for maintainability in a team environment. Consistent naming conventions, co-located styles, and documented component interfaces so other team members could read and extend the code.
Git workflow Feature branch workflow with pull requests. Commit messages written to be meaningful at a glance. Merge conflict resolution in a live collaborative environment.
Development Practices
Code was written with the assumption that other engineers would read it, debug it, and extend it. This meant:
Avoiding clever abstractions that only make sense to the person who wrote them. Writing components that do one thing well. Keeping side effects explicit and easy to trace. Adding comments where the why is not obvious from the what.
Debugging under time pressure pushed toward faster hypothesis formation: identify the most likely failure point first, test it, move on. Less exhaustive elimination, more informed guessing.
Tradeoffs were made continuously between the technically ideal and what was needed to keep pace with the product roadmap. Documenting those tradeoffs in code comments or PR descriptions kept the team aligned.
Getting Started
git clone https://github.com/YOUR_USERNAME/agriha
cd agriha
npm install
npm run dev
Environment Variables
Create a .env file in the project root:
VITE_API_BASE_URL=your_api_url_here
Build
npm run build
Output goes to dist/. The build is optimized for production with minification and tree-shaking applied automatically.
Status
Development paused. The initiative wound down approximately two months in when founder priorities shifted before the MVP shipped. The codebase represents the work completed up to that point.
