Sahil Sapariya is a full-stack software engineer at Jeavio, based in Vadodara, Gujarat, India. He builds production SaaS systems end to end — frontend architecture, backend workflows, deployment. He is an alumnus of Dharmsinh Desai University (DDU). Selected work includes Nexchool (a school management SaaS), Retail-OS (a retail platform), and the DUHACKS 2.0 award-winning College360. Sahil works with Next.js, TypeScript, Python, Django, FastAPI, PostgreSQL, and React.
A school management SaaS platform built for real institutions — academics, attendance, timetable, dashboards, and operational workflows. Co-owned with a friend; shipping iteratively.
I own the frontend architecture and several backend modules, working closely on product decisions and implementation flow.
"Designing the academic backbone in a future-proof way instead of taking shortcuts that would have made timetable, attendance, and subject management harder later."
Schools don't get to be down. Academic cycles are calendar-driven. A subtle data-model decision in week two echoes for years.
A 3D virtual campus experience built during DUHACKS 2.0 hackathon to help students explore Dharmsinh Desai University remotely.
I was the team lead — product direction, frontend implementation, and overall execution.
"Aggressively limiting scope so the demo felt polished and complete instead of trying to simulate an entire university ecosystem."
Thirty-six hours. Four people. A judging panel. Scope wasn't a planning exercise — it was the only variable we could actually control.
A retail SaaS platform that runs the whole shop — parties (customers/suppliers), products, purchases, inventory, POS sales, returns, with accounting and analytics on the roadmap. Inventory is one module inside it; retail is the actual domain.
I handle the product architecture, frontend system design, and backend workflow implementation.
"Prioritizing operational simplicity and maintainability over adding unnecessary complexity too early — a small retailer's reality is messier than the abstractions you'd reach for first."
Retail data is operational data. A confusing UI doesn't slow people down — it produces wrong numbers. Reliability beats novelty here.
A collection of internal experiments around AI-assisted engineering workflows, implementation pipelines, and developer automation systems.
Solo — exploring how AI can improve execution speed and iteration quality without replacing engineering judgment.
"Designing workflows that remain reliable and practical instead of becoming over-automated gimmicks."
Trust is the bottleneck, not throughput. A pipeline that's slightly wrong fifty percent of the time saves nothing — engineering judgment stays the bar.
One continuous flow — from a brief to production and back again. Each stage is a decision; each curve is a habit that's taken a while to learn.
Real engineering moments, abstracted to protect client and internal details.
← SCROLL ↓ TO ADVANCE →
Worked on an education product where some users were visually impaired. Keyboard navigation, focus rings, screen-reader landmarks, semantic structure — features that should have been there from day one became retrofits. The lesson stayed: accessibility isn't a feature, it's a debugging discipline.
Building a Zoom integration inside an internal product. Users could connect their Zoom account, authorize access, browse the recordings of meetings that had happened in the product, pick the ones they wanted, and import those recordings back in. The documentation example fit on one screen — making it survive timezones, token refresh, large recording lists, and partial import failures took weeks. Real integrations are five percent protocol and ninety-five percent edge cases.
Helping a client product clear a certification audit meant writing not just the code but the trail it leaves — audit logs, role boundaries, data handling, retention policy. Engineering is the part everyone sees. The certification is the part nobody does.
A deployment that should have been routine wasn't. Half the diagnosis was reading other engineers' notes from eighteen months ago. The other half was learning the system from the way it failed. Production teaches faster than docs — but only if you write the docs as you go.
Most of the work on a real product isn't shipping the flashy components. It's making sure the existing ones don't break when the content is in Hindi instead of English, when the browser is Safari, when the network is 3G, or when the device hasn't been updated since 2019. The boring half is most of it.
More live in commit messages.
Half-built experiments and side explorations. Honest about status — not every idea ships, and that's the point.
A small Unix shell built in C. Process control, pipes, syscalls — low-level exploration to learn how the layer beneath the language actually works.
Assembly experiments from undergrad. Low-level programming on the 8086 — register conventions, addressing modes, the metal underneath higher-level abstractions.
Structured AI-assisted implementation workflows. Prompt → critique → patch → test loops for my own development cadence.
This site — a cinematic editorial engineering portfolio. Built in public.
My own take on Authorizer.dev — user management primitives, auth flows, role boundaries. Mostly a learning exercise; the original is the better tool, but rebuilding it taught me where the hard parts actually are.
