The readable edition

Aayan Amir

Software developer building practical tools that make everyday work easier.

Seeking backend and full-stack internships and junior roles. Open to freelance conversations.

Download résumé (PDF)

Selected work

Student tool · Live project

NoClash

What I brought to the project

I brought timetable interpretation, editable course data and clash checking into one planning workflow, so students can start with the timetable they already have instead of entering every class by hand.

What the application delivers

The resulting planner supports weekly and day-by-day views, shareable schedule selections and high-resolution image export. Planning can continue with saved data through an offline-capable application shell.

Review and correct extracted course data
Compare sections and theory, lab or tutorial components
Explain overlaps and inspect weekly or daily schedules
Share selections by URL and export a timetable image

Engineering decisions

Separate interpretation from validation

AI assists with reading inconsistent timetable documents. Reviewable structured data feeds deterministic client-side clash checks, keeping conflicts explainable rather than asking a model to decide them.

Keep planning lightweight

Versioned static JSON and Zod validation provide a consistent data format. Device-local state includes migration support; compact Base64URL selections make schedules shareable without a mandatory account.

Make timetable data maintainable

A local visual authoring studio and data-validation scripts support updates separately from the student planning interface.

The problem

University timetables arrive as photos, screenshots, scans and PDFs. Students have to identify sections, copy class details and compare overlapping times before they can plan a semester.

The approach

Visual timetable input becomes structured courses, sections, instructors, rooms, days and time slots. Students review and correct the extraction, choose course components, and see specific explanations when classes overlap.

Scope and limitations

Extraction can misread blurry text, merged cells or abbreviations; review remains part of the workflow.

Based on the project README, reviewed 24 October 2026.

Visit live project Source code

Full-stack web application

Student Portal

Workflow illustration: resource submission, pending review, then approved publication — Workflow illustration based on the README · not an application screenshot

What I brought to the project

I connected student submissions, administrator moderation, persistent records and uploaded files in one application. The important boundary is publication: submitting a resource does not make it public.

What the application delivers

The application provides a complete submit → review → publish workflow, with Cloudinary uploads and file open/download endpoints. PDFs are proxied for inline viewing and download; rejection also removes uploaded files.

Classrooms grouped by subject and section
Pending submissions with approve/reject moderation
Room management and cookie-authenticated administrator access
Approved file viewing and download, including inline PDFs

Engineering decisions

Make moderation part of the data model

ClassRoom, ContentItem and ContentFile records, together with content/status enums, express room membership, submission state and file metadata. EF Core with Npgsql persists them in PostgreSQL.

Separate storage from delivery

Cloudinary handles optional JPG, PNG, WEBP, GIF and PDF uploads. Application endpoints handle approved-content access and PDF delivery rather than making the upload form the publication boundary.

Validate setup before serving requests

Startup checks required database, administrator and upload configuration. Local development uses user-secrets; the repository also contains a separate Capacitor Android wrapper for a hosted portal.

The problem

Notes, links, images and PDFs need a shared classroom home. Publishing every submission immediately gives administrators no opportunity to review what becomes visible.

The approach

Students browse subject/section classrooms and submit metadata with an optional file. New records enter Pending status. Cookie-authenticated administrators approve or reject submissions and manage classrooms; approved items appear in the room.

Scope and limitations

Running the portal requires PostgreSQL, Cloudinary and administrator configuration. The Android project is a web wrapper, not a separate native implementation.

Based on the project README, reviewed 24 October 2026.

Source code

Linux desktop application

NoTerm

Workflow illustration: choose a task, review the command, read the result — Workflow illustration based on the README · not an application screenshot

What I brought to the project

I built a task-first command center around a predefined action catalog, validated inputs and visible execution results. It helps users find a task while preserving a review step before higher-impact actions.

What the application delivers

The desktop app includes 66 built-in actions across ten system areas. An optional PostgreSQL catalog can supply validated actions, while a built-in fallback keeps the catalog available when database loading fails.

66 actions across System, Storage, Network and seven other areas
Intent search, grouped actions and validated parameters
Command previews, risk confirmations and polkit integration
stdout/stderr and exit status, plus catalog diagnostics

Engineering decisions

Use predefined actions instead of arbitrary shell text

ProcessStartInfo.ArgumentList passes arguments without shell-string interpolation. Type-specific validation covers package/service names, hostnames, relative paths, process IDs and file names.

Keep privilege and impact visible

Administrator and destructive actions are marked and confirmed. Privileged operations delegate to pkexec; file-path actions are home-relative by design. These measures reduce risk, rather than guaranteeing every operation is harmless.

Treat the remote catalog as optional

The Supabase/PostgreSQL integration validates loaded data and falls back to the built-in catalog. A CLI consistency self-test checks duplicate IDs, categories and parameter placeholders; a separate mode seeds the database.

The problem

Routine Linux maintenance can require remembering commands, parameters and their consequences. A friendly interface still needs to make privileged or destructive operations explicit.

The approach

Users search by intent, choose an action, supply any required parameter and review the command preview and impact badges. Risky actions request confirmation; execution reports standard output, standard error and exit status in the application.

Scope and limitations

Ubuntu/Linux is the primary target. Actions depend on installed utilities; privileged operations require working polkit and a desktop session.

Based on the project README, reviewed 24 October 2026.

Source code

Contributions

Backend Developer (Contract) · January–September 2026

Outreach that stays organised

Lead records were spread across Excel sheets. Built a C# and EF Core CRM with defined pipeline stages and follow-up reminders.

Supported 500+ active leads in one workflow.

Stock records with structure

Inventory keeping relied on repetitive operational record keeping. Designed and deployed an ASP.NET Core and PostgreSQL inventory module.

Covered 100+ stock items across 15 product categories.

Expense approvals with clear steps

Expense submissions needed a consistent review process. Built receipt uploads, departmental budget validation and Employee → Manager → Finance approvals.

Processed 200+ monthly expense claims.

Less time reconciling reports

Monthly reconciliation required manual financial data aggregation. Automated PDF financial summaries.

Reduced monthly reconciliation processing time by approximately 30%.

How I work

I start with repetitive tasks and look for a practical way to make them easier. I use AI tools to help with development, review the output, and check what I ship.

Contact

aayanwork1@gmail.com

GitHub