Skip to content

Latest commit

 

History

492 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 

Repository files navigation

RYGNeco Operations Platform - MVP Program Case Study

Status: Cross-functional MVP developed against pilot operations. This repository is not evidence of production certification, regulatory assurance, audited ESG results, tax eligibility, verified carbon accounting, blockchain capability, or guaranteed financial outcomes. Product screens and reports may contain demonstration data.

Business problem

RYGNeco's field operation needed a consistent path from e-waste intake through pickup, inventory, testing, disposition, data-destruction records, pricing, payout, and client reporting. The operating risk was fragmentation: field activity, device records, vendor work, and client communication could otherwise live in separate spreadsheets, messages, and manual documents.

The MVP was intended to turn that field workflow into one operating system with role-specific views for administrators, clients, technicians, and downstream partners.

Repository lineage

The code under green-tech-vault-impact/ is an earlier Green Tech Vault / RYGNeco implementation snapshot built with React, Express, MongoDB, and Render-oriented configuration. It helped make the operating workflow tangible, but it is not a byte-for-byte copy of the later vendor-led MVP program and should not be read as proof that every four-portal requirement, AWS recommendation, integration, or acceptance criterion reached production.

Program scope, investment, pilot evidence, vendor governance, and architecture advice describe the broader RYGNeco initiative. Repository capability describes only what can be inspected in this public snapshot. The two evidence classes are intentionally separated below.

Sama Mushtaq's mandate

As co-founder and program lead, Sama Mushtaq owned the operating problem and cross-functional delivery program. His responsibilities included:

  • translating field work into product requirements and a four-portal workflow;
  • defining the roadmap, milestones, acceptance criteria, and pilot feedback loop;
  • coordinating a co-founder, development contributors/vendor, interns, and an AWS architecture adviser;
  • connecting product decisions to intake, testing, disposition, pricing, records, and client-reporting needs;
  • monitoring pilot throughput, safety, data quality, and adoption constraints.

This is a program-lead and product-operations case study. It does not claim that Sama personally authored every line of application code or every visual asset.

Contributor boundaries

Contribution Owner / creator Status
Operating mandate, field workflow, requirements, roadmap, and acceptance criteria Sama Mushtaq Program leadership
Technical leadership and implementation contributions Co-founder / technical lead Collaborative implementation; individual identity withheld in this public case
Additional implementation and delivery support Development contributors/vendor Contributor attribution should be retained in history and delivery records
Architecture guidance AWS architecture adviser Advisory input
Pilot execution and feedback RYGNeco operating team and interns Operational contribution
Sample UI, reports, metrics, and named entities Demonstration content unless a source is explicitly identified Not operating evidence

Git commit ownership identifies who committed a file; it does not by itself establish exclusive design or authorship.

Program scope

The target operating lifecycle covered:

  1. Intake and scheduling - capture organizations, pickup requests, service details, and timing.
  2. Collection and chain of custody - create pickup records and maintain asset handoffs.
  3. Inventory and testing - catalog devices, record condition, and track testing status.
  4. Disposition - record reuse, resale, recycling, destruction, or other approved outcomes.
  5. Financial workflow - support pricing, payout, and financial-impact fields where source data is available.
  6. Client reporting - assemble operational records into configurable client-facing reports.
  7. Administration - manage companies, users, messages, pickups, devices, and reports.

Evidence taxonomy

Evidence class What it supports Current examples Interpretation
Operational program records Pilot execution and program scope 400+ devices processed; approximately 480 cataloged; 130 tested and verified; zero OSHA recordables during the scoped pilot Supplied by Sama Mushtaq from program records; not independently audited. Counts reflect different workflow stages and should not be summed.
Delivery records Program investment and coordination Approximately $11.5K vendor-built MVP program; cross-functional delivery team Program-level record, not proof of production readiness or code authorship
Repository artifacts What was designed or implemented React client, Express API, MongoDB models, routes, reporting modules, deployment configuration Evidence that the artifact exists; not evidence that every path was production-tested
Demonstration data Intended user experience Sample organizations, counts, payouts, environmental values, certificates, and reports in UI/code Fictional or illustrative unless a source and date are explicitly attached
Independent assurance Certification, legal, tax, carbon, ESG, or security conclusions None established by this repository Not claimed

Key program decisions and tradeoffs

  • Workflow before polish: structure the field lifecycle and ownership model before treating dashboard visuals as outcomes.
  • Role-specific portals: reduce cognitive load by separating administrator, client, technician, and partner workflows.
  • Configurable reporting: support multiple report cadences and sections while preserving a common data model.
  • Vendor-led implementation: use external technical capacity while retaining requirements, milestone, and acceptance governance inside the program.
  • Pilot-informed iteration: use real handling and cataloging activity to expose gaps in intake, status, and reporting logic.

Current repository capabilities

The codebase contains implementation paths for:

  • client and administrator authentication;
  • company, user, message, pickup, device, and report records;
  • role-specific dashboards and profiles;
  • pickup scheduling and calendar views;
  • device inventory and lifecycle tracking;
  • impact and reporting modules;
  • printable/report export experiences;
  • a React client and Node/Express API configured for MongoDB.

These are repository capabilities, not a representation that each feature is production-ready, secure, integrated, or accepted.

Technical architecture

Layer Technology
Front end React 18, Material UI, React Router, Chart.js, Recharts
API Node.js, Express
Data MongoDB with Mongoose
Authentication JSON Web Tokens and bcryptjs
Reporting Handlebars-style templates, jsPDF, html2canvas
Observability / quality tooling Sentry packages, Lighthouse, axe, React testing utilities
Deployment configuration Render

Repository layout

green-tech-vault-impact/
  client/                  React application
    public/                Static assets
    src/                   Pages, components, contexts, services, and reporting module
  server/                  Express application
    config/                Database configuration
    controllers/           Request handlers
    middleware/            Authentication middleware
    models/                Mongoose models
    routes/                API routes
    services/              Supporting services
    utils/                 Shared logic
  render.yaml              Render configuration
  package.json             Root scripts and API dependencies

API route groups

  • /api/auth - authentication
  • /api/companies - company records
  • /api/pickups - pickup workflow
  • /api/devices - device inventory
  • /api/impact - environmental-impact data paths
  • /api/reports - report generation and retrieval
  • /api/messages - communication records

Local development

Prerequisites:

  • Node.js 18 or later
  • npm 8 or later
  • a MongoDB connection string
git clone https://github.com/Samamak1/RYGNeco.git
cd RYGNeco/green-tech-vault-impact
npm run install:all
npm run dev:full

Expected local endpoints:

  • client: http://localhost:3000
  • API: http://localhost:5000

Create local environment configuration outside version control. The application expects values such as:

NODE_ENV=development
MONGODB_URI=<your MongoDB connection string>
JWT_SECRET=<a strong local secret>
PORT=5000

Never commit live credentials, client data, or production secrets.

Useful scripts

npm run dev:full       # API and client development servers
npm run build:client   # install and build the client, then copy static images
npm run build          # build client output
npm start              # production-style API start

The root test script currently reports that no test is specified. Client-side test and quality-tool dependencies exist, but this README does not claim a passing automated test suite.

Render deployment configuration

The repository includes Render-oriented configuration. From green-tech-vault-impact/, the documented commands are:

Build: npm install && npm run build:client
Start: npm start

Required production configuration includes NODE_ENV, MONGODB_URI, JWT_SECRET, and the platform-provided PORT. A deployment should not be treated as production-ready until security, privacy, data retention, backup, monitoring, accessibility, and acceptance reviews are complete.

Limitations and claim controls

  • Dashboard and report values must be treated as demonstration data unless they include a named source, date, scope, and owner.
  • Environmental calculations require a documented methodology, boundaries, factors, units, versioning, and review before external use.
  • Certification badges or compliance language in prototype files do not establish certification or compliance.
  • Tax values, deductions, forms, and eligibility require qualified legal and tax review; the application must not determine eligibility.
  • Data-destruction and chain-of-custody outputs require verified operational controls and source records.
  • Carbon-credit, ESG-rating, blockchain, assurance, audit, or customer-result claims are not established by this repository.
  • Security controls, role permissions, production data handling, and end-to-end tests require independent validation.

Licensing

The repository currently contains conflicting license metadata: the root file is MIT, the package metadata says ISC, and the previous README used proprietary language. Maintainers should select one authorized license and update all files consistently before inviting reuse or contributions.

About

Electronics lifecycle platform for device intake, testing, grading, chain of custody, disposition, evidence, and client reporting.

Topics

Resources

Stars

1 star

Watchers

2 watching

Forks

Releases

Packages

Used by

Contributors

Languages