AP Anshu Priya Download Resume
SOFTWARE ENGINEER & FULL-STACK DEVELOPER

Software Engineer & Full-Stack Developer

BCA Candidate — Engineering purposeful mobile & full-stack systems in AgriTech, Personal Safety, and FinTech.

🎓 BCA — 4th Semester
🛠 Flutter · Java · React · Python
Explore Projects GitHub LinkedIn
01 — Featured Work

Engineering Case Studies

Three systems, three different engineering problems — each one built end-to-end, bugs and honest limitations included.

02 — Technical Focus

Skills & Engineering Philosophy

Mobile & Frontend
FlutterDart Responsive Mobile UIState Management ReactHTML/CSS/JS
Backend & Infrastructure
JavaSpring Boot PythonREST APIs PostgreSQLNode.js / Express MongoDBGit / GitHub
Core Computer Science
Data Structures & AlgorithmsSystem Design Thinking OOPGit Version Control
I don't claim equal depth across everything listed. My strongest hands-on experience currently comes from Flutter/mobile development, Java/backend development, APIs, databases, and complete project workflows — end to end, not just the parts that are easy to demo.
03 — Professional Experience

Timeline

SEPT 2026 — PRESENT
Ongoing
Full-Stack Developer Trainee
Enerzcloud Innovations · View Program ↗

A structured, Monday-to-Friday, 4-week intensive covering both frontend and backend development — from HTML/CSS/JS fundamentals through advanced JavaScript, Git, Node.js/Express backend development, MongoDB integration, authentication, API integration, and deployment.

Trainees build a complete end-to-end web application as a capstone project, integrating frontend, backend, and database technologies — practical skills to develop, deploy, and manage full-stack web applications.
JUNE 2025 — APRIL 2026
Primary Educator, LKG – Grade 5
Sri Aurobindo High School · Hyderabad

Communication & Logic: Delivered structured daily instruction, breaking down complex foundational concepts into digestible modules for 100+ students.

Leadership & Adaptability: Managed classroom operations, student evaluation, and conflict resolution under daily deadline constraints.

FEB 2025 — MAY 2025
Student Counselor & Activity Mentor
Androma International Academy · Tamil Nadu

Adaptability & Relocation: Adapted quickly to regional educational institutions across Tamil Nadu (Vivek Ananda School & Kalvi Karpagam School), managing student programs and creative activities.

Mentorship: Guided students through experiential workshops, honing interpersonal management and clear presentation skills.

04 — Verified Credentials

Certifications

📊
TATA GenAI Powered Data Analytics
Forage · July 2026
Skills Verified
Exploratory Data Analysis Customer Risk Profiling AI-Assisted Analysis Data Visualization
↗ View Credential
🏦
Commonwealth Bank Software Engineering
Forage Virtual Experience · June 2026
Skills Verified
.NET Backend React / Redux REST APIs Unit Testing Git & Pull Requests
↗ View Credential
05 — About

The Journey to Google

I am a BCA student and full-stack software engineer driven by building software that solves high-stakes, real-world problems. My path into engineering was shaped by hands-on experience as an educator across schools in Tamil Nadu and high school institutions. Teaching refined my ability to break down complex systems into fundamental logic, communicate with clarity, and manage responsibilities with empathy — skills I apply directly to software engineering today.

My long-term goal is to engineer large-scale, impactful systems at Google. Currently, I focus on building domain-specific applications in AgriTech, Personal Safety, and FinTech while continuously deepening my knowledge in Data Structures and System Design.

AgriTech · Flutter · Rule-Based Decision Engine

AgroPredict

Role
Lead Developer — End-to-End
Tech Stack
Flutter, Dart, AGMARKNET API
Research Period
May – July 2026
Links
GitHub · Documentary
01

The Problem & The Vision

I grew up in a farming family — my father grows crops, my mother handles the selling decisions. I watched, year after year, the same problem play out: harvest is ready, and now what? Sell here or travel? Today or wait? Nobody in the family had a reliable way to answer that.

Farmers know the price board at their local mandi. They almost never know what the same crop is fetching at a mandi 50–300km away, whether the price difference justifies the trip, or whether today is even a good day to sell.

"Kam jankari hone ke karan samne wale mandi mein hi bech dete hai." — Because of low information, we sell at the nearest mandi.

Target audience: smallholder farmers who lack an easy way to compare mandi prices, distance, and transport cost — especially those for whom English, text-heavy interfaces are a real barrier.

02

Field Research

I spoke with 25 people — mostly farmers with their own land, plus 2 market agents — across Jharkhand (~60%) and Odisha (~40%), May–July 2026. Informal conversations, direct farm observation, and live app-testing sessions — not a formal survey, but a consistent pattern: information gap → sell at the nearest mandi → lower net profit.

A real example from the research: mangoes selling locally at ₹1,500/qtl were fetching ₹1,800/qtl at Berhampur mandi, 347km away — still profitable by roughly ₹200/qtl after estimated transport cost.

Field research, Jharkhand
Field research, Jharkhand
Field research, Jharkhand
Field research, Jharkhand
Field research, Odisha
Field research, Odisha
Field research, Odisha
My father in our farm
03

Technical Architecture & System Design

AgroPredict is built around a rule-based decision engine — not a machine learning model. Every recommendation is transparent and traceable to a specific threshold, which matters when the person reading the advice can't read English and needs to trust it on faith.

01Live Mandi Price Checking
Pulls live government price data via the AGMARKNET API for a searched crop across every reporting mandi — the foundation everything else builds on.
02Smart Advice Engine (Rule-Based)
Computes average price across mandis and classifies the situation: SELL if price is 20%+ above average or average is healthy & stable; WAIT if average is low or trending down; MONITOR otherwise. Plain-language reasons in English and Hindi.
03GPS Nearest Mandi + Distance-Aware Recommendations
Distance to every mandi calculated via the Haversine formula against a hand-built local mandi coordinate database (55 mandis across the Jharkhand–Odisha border — no free API covers rural mandis at this granularity).
04Transport & Shared Transport Calculators
Distance + quantity → transport cost (₹12/km), total earnings, net profit, and a ✅ Worth It / ❌ Not Worth It verdict. The Shared Transport calculator lets neighbors splitting a trip see cost-per-farmer and total savings — a feature no mainstream agritech app formalizes.
05Hindi + Voice Input/Output
Full Hindi UI toggle, voice input for crop names, and flutter_tts reading the final advice aloud — a farmer doesn't have to read a single word to get an answer.
04

Engineering Challenges & Solutions

Bug
Recommending a mandi 1,353km away
The nearby-mandi radius defaulted to 500km. Combined with a sparse rural mandi database, the app once recommended a mandi in Tamil Nadu to a farmer in Jharkhand — 1,353km away. Root cause: bad default + genuinely sparse data (no free API covers rural mandis at this granularity). Fix: hand-built a 55-mandi local coordinate database from Google Maps and tightened the radius to 50km.
Bug
Silent key-mismatch crash in the profit calculator
The calculation function returned keys like netInHand and extraVsLocal, but the UI was reading netGain and extraEarnings — a silent mismatch that crashed the profit screen with no clear error. Fixed by aligning the return map to what the UI actually expected, and used the incident to standardize naming across the codebase.
Bug
A TabController that broke when I added a feature in the wrong place
Wiring the Shared Transport calculator directly into the price-result tabs broke tab navigation — nested navigation inside a TabBarView interfered with the TabController. Solved by choosing better information architecture: moved it to a standalone screen launched from the Home Screen, keeping the existing 3-tab flow untouched.
Stated Honestly — Limitations
  • Curated mandi database (~70+ cities) — not full national coverage
  • Small qualitative sample — 25 conversations, not a formal survey
  • Distance is GPS-estimated, not actual road distance
  • Transport cost uses a single ₹12/km rate — vehicle type not yet distinguished
  • No deployed user base with tracked outcomes yet — impact on real earnings not measured
05

Key Results & Next Steps

The clearest proof isn't a metric — it's the feedback loop. When my mother asked "which rice?" during testing, the variety selector shipped within 24 hours. When farmers said reading was hard, Hindi voice output shipped the same week.

What a farmer saidWhat shipped
"Kaunsi chawal?" (Which rice?)Variety selector — 24 hrs
"Padhne mein dikkat hota hai."Hindi UI + voice output
Farmers call friends to compare pricesMulti-mandi comparison view
Neighbors informally split transport costShared Transport Calculator
1Price-date transparency & a "stale data" warning past 48 hours
2One-tap feedback loop — "Was this advice useful?"
3Odia language support, and a price-history graph farmers explicitly asked for
4A small 15–30 farmer pilot, tracking whether advice actually changes behavior
FlutterDartAGMARKNET API Geolocatorflutter_ttsspeech_to_text
GitHub ↗ ▶ Documentary
Safety Tech · Flutter · Real Device Tested

REPSHIELD

Role
Solo Developer — End-to-End
Tech Stack
Flutter, Dart, Sensors Plus
Test Device
TECNO KL4h · Android 14
Links
GitHub · APK
01

The Problem & The Vision

It's 10:30 PM. Someone is travelling home alone on a bus. She feels uncomfortable but isn't in immediate danger. She has no way to silently let someone know where she is — or what happens if she suddenly stops responding.

Most people in uncomfortable situations face three problems: no silent way to call for help (calling openly can escalate the situation, typing takes too long), no proof when something goes wrong (incidents go unreported because there's no evidence), and nobody is watching (if someone stops responding, no system notices).

Target audience: anyone in a situation that feels unsafe but not yet dangerous — where speed, discretion, and evidence all matter more than a loud alarm.

02

App Gallery

Nine working features, all tested on a real Android 14 device over wireless ADB debugging.

REPSHIELD screen
REPSHIELD screen
REPSHIELD screen
REPSHIELD screen
REPSHIELD screen
REPSHIELD screen
03

Technical Architecture & System Design

The real engineering challenge wasn't building an SOS button — it was connecting Sensor → Trigger → GPS → Emergency Communication → Local Storage → Evidence Integrity while keeping the experience simple enough to use under pressure.

01SOS with Live GPS Location
Long-press fetches live GPS, opens SMS pre-filled with an emergency message and exact Google Maps link. Tested on a real device — the trusted contact received the exact coordinates within seconds.
🚨 EMERGENCY! I need help immediately! My location: https://maps.google.com/?q=22.4300569,84.6967738
02Shake-to-Trigger SOS
The accelerometer constantly monitors movement. When acceleration = √(x²+y²+z²) exceeds a threshold, SOS fires automatically — no screen tap needed, works from inside a bag or pocket.
03Forensic Journal with SHA-256 Sealing
The user describes an incident; the app generates a SHA-256 hash of the text plus timestamp — the same technology used in blockchain. If even one character changes later, the hash changes completely, proving the entry wasn't tampered with after the fact.
04Stealth Mode
One tap hides all system UI and returns a pure black screen — the phone looks off, but shake detection and SOS stay fully active underneath.
SystemChrome.setEnabledSystemUIMode( SystemUiMode.manual, overlays: [], // nothing visible ); return Scaffold(backgroundColor: Colors.black); // exit: long-press anywhere
05Safety Timer
A countdown the user sets before entering an uncertain situation. Tap "I'm Safe" before it hits zero, or an alert begins.
04

Engineering Challenges & Solutions

Design Challenge
Simple enough to use under pressure
Connecting six distinct subsystems (sensor, GPS, SMS, local storage, hashing, UI state) is straightforward on its own — the actual hard problem was making all six work reliably enough that someone under real stress, who cannot look at instructions, can trigger help correctly on the first try. That constraint shaped every feature: shake instead of a precise tap target, one long-press for stealth exit instead of a menu, a single SOS button instead of a form.
Stated Honestly — v1.0.0 Scope
  • Contacts are stored locally (SharedPreferences) — not yet cloud-backed, so evidence is lost if the phone is lost
  • SOS sends via SMS, one contact at a time in v1 — simultaneous multi-contact alerts are a v2.0 feature
  • No authentication layer yet — anyone with the device can access saved evidence
05

Key Results & Next Steps

TestResult
SOS SMS sent✅ Real SMS received by contact
GPS accuracy✅ Exact coordinates confirmed
Shake trigger✅ Activates without screen touch
Stealth mode✅ Black screen, app still active
Journal hashing✅ SHA-256 seal generated
Android 14 device✅ Tested end-to-end

v2.0 — Safety Sessions: the biggest planned upgrade turns the timer into a full 6-stage escalation ladder — session start → check-in prompt → no-response alert → SMS to contacts with last known location → contact takes action → SOS trigger → critical escalation. The core principle: the app detects non-response, not the reason for it — it never assumes what happened, only that the user hasn't checked in.

1Silent Evidence Mode — automatic audio/photo capture when danger is detected
2Firebase Authentication — secure Gmail/phone login so evidence stays protected and accessible even if the phone is lost
3Fake app icon — disguised as a calculator, opened only with a secret code
4Multi-contact simultaneous alerts + live location sharing during a session
FlutterDartGeolocator Sensors PlusCrypto (SHA-256)SharedPreferences
GitHub ↗ Download APK
FinTech · Java + Spring Boot + React · Explainable Risk Engine

SentinelPay

Role
Lead Developer — Full-Stack
Tech Stack
Java, Spring Boot, React
Database
PostgreSQL
Links
Frontend · Backend
01

The Problem & The Vision

Payments carry real financial risk, and the moment that risk actually gets decided is before a transaction is allowed to go through — not after. A transaction needs to be evaluated in real time: does this look safe, or does it need to be stopped?

SentinelPay is built around exactly that decision. Instead of simply recording a transaction, it evaluates each one live and decides whether to approve it, flag it for review, or block it — and explains exactly why, instead of behaving like a black box.

Target audience: this is a demonstration of production-grade fintech risk engineering — the kind of explainable, auditable decisioning that real payment platforms need, built to understand how those systems actually work under the hood.

02

Dashboard Gallery

SentinelPay dashboard
SentinelPay approved
SentinelPay blocked
SentinelPay history
03

Technical Architecture & System Design

Request → Validation → Rules → Risk Evaluation → Decision → Persistence → Dashboard. Every transaction runs through independent checks — amount, time of day, payee velocity, device recognition — and each triggered check adds points plus a specific, plain-English reason.

01Explainable Risk Scoring
Example: someone sends ₹15,000 at 1am. The system doesn't just say "blocked" — it returns Risk Score: 45 — FLAGGED, with reasons: "High amount transaction (+30)", "Unusual transaction hour (+15)".
02Live Fraud Attack Simulator
Fires a rapid burst of transactions at the same payee. A single transaction rarely looks suspicious alone — real fraud shows up as a pattern over time. Try it below.
Live Simulator
Rapid transactions from same payee →
03Device Fingerprinting
Before every transaction, the browser collects screen resolution, timezone, browser type, and language into a rough fingerprint string. If a known payee suddenly transacts from a new fingerprint, that's a risk signal: "Transaction from unrecognized device (+20)".
04Real-Time Dashboard
Live summary cards — total transactions, blocked, flagged, approval rate — computed directly from stored data, not hardcoded. Example output: 137 Total · 47 Blocked · 27 Flagged · 46% Approval Rate.
04

Engineering Challenges & Solutions

Bug
Every transaction disappeared on server restart
Early on, all transaction data lived only in the server's temporary memory — restarting the backend wiped every transaction ever created. Unacceptable for anything claiming to detect and track fraud. Fixed by connecting to a real PostgreSQL database via Spring's JPA — every transaction's amount, payee, risk score, decision, device fingerprint, and timestamp is now permanently saved.
Stated Honestly — Limitations
  • No authentication yet — anyone with the API address can currently use it
  • Velocity tracking only works correctly on a single running server (in-memory, not yet Redis-backed)
  • Device fingerprinting relies on browser-reported info, which a determined attacker could fake — one honest layer of protection, not a complete solution
  • Risk rules are fixed thresholds I chose by hand, not values learned from real data
05

Key Results & Next Steps

1Scam-intent detection — ask the user why they're paying, check against known scam-language patterns
2Move velocity tracking to Redis so it works correctly across multiple servers
3Beneficiary verification & graph-based mule-account detection
4ML risk scoring alongside the explainable rules — not replacing them
5Authentication + Docker deployment — turning this from a local demo into something real users could use
JavaSpring BootReact (Vite) PostgreSQLMavenREST APIs
Frontend ↗ Backend ↗