# Abhiram V M A curious designer who likes to build. I’m a product designer who likes to build. At FlytBase, I turn complex drone workflows into tools people can use. Outside work, I’m making Pickem, my first iOS app, and photographing things that catch my eye. ## Sources - [LinkedIn](https://www.linkedin.com/in/abhiram-vm/) - [GitHub](https://github.com/pixlncode) - [Instagram](https://www.instagram.com/abhiyyh/) - [X](https://x.com/akkwho) ## Products I shipped ### FlytClip Drone footage became a report operators could approve and share. Someone outside FlytBase needed to understand a drone mission’s findings alongside the footage. FlytClip kept selected media, operational context, and reviewed claims in one report, with operator approval controlling what could be shared. **From problem to shipped product** I owned product strategy, experience design, and the AI-assisted frontend and backend build. ![FlytClip Studio showing mission footage, selected media, and report review.](/media/flytclip-studio.jpg) [Explore FlytClip](/work/flytclip) [FlytClip demo](https://vimeo.com/1234034640) ### Weather Intelligence Weather data became flight guidance operators could inspect. Remote drone operators needed to know whether to fly now or plan for later. Weather Intelligence translated local readings, aviation observations, and forecasts into guidance with visible sources and operating limits, while the operator kept the final decision. **Product design & build** I took a supplied brief through design and shipment, with mentorship from a domain expert. ![FlytBase Docks overview with local weather and flight readiness guidance.](/media/weather-overview.jpg) [Explore Weather Intelligence](/work/weather-intelligence) ### Pickem: Take & Make Take pieces of the world. Make a new photo with them. Pickem explores a simple idea: the things you notice now can become material for a photo you make later. I designed and built an iPhone camera that collects objects as Pieces, carries them in a Pocket, and lets people arrange them in a new photo. **My first iOS app** I conceived, designed, and built Pickem from camera collection through composition, save, & share. ![Pickem iPhone screens for collecting pieces and composing a new photograph.](/media/pickem.jpg) App Store release coming soon. [Pickem Launch video](https://vimeo.com/1233957249) ## A little more about me. ### Hey, I’m Abhiram. I design products, build things, and take a lot of photos. ![Abhiram V M](/media/abhiram-portrait.jpg) ### Experience - **FlytBase — AI Design Engineer:** May 2026 – October 2026 - **DMI Finance — Product Design Intern:** October 2025 – April 2026 ### Education IIT Madras · 2020–2025 MA, English Studies ### How I got into design I used to fill notebooks with drawings. During COVID lockdown, I started designing for [@pulp.ithihasam](https://www.instagram.com/pulp.ithihasam/). I kept learning at IIT Madras and taught myself product design. ### Portfolio reel [Kalpa — portfolio reel](https://vimeo.com/1233445496) ### My camera roll A few photos from my travels. #### A govt school in Idukki (Kerala) ![A flowering tree by the hills](/media/photographs/flowering-hills.webp) #### The view outside my room in Kalpa ![Prayer flags in the mountains](/media/photographs/prayer-flags.webp) #### Third-wheeling made me capture this ![An afternoon by the sea](/media/photographs/by-the-sea.webp) #### Kodaikanal, you beauty! ![Under the hillside tree](/media/photographs/hillside-tree.webp) #### Kinnaur Kailash from Chhakha ![Mountains through the pines](/media/photographs/through-the-pines.webp) #### Captured bro’s best pic ever in Sissu ![A moment in the mountain light](/media/photographs/mountain-light.webp) #### On the way back home after resigning ![Sunset from the window seat](/media/photographs/above-the-clouds.webp) #### Man, the architecture of Safdarjang! ![Looking up at a carved ceiling](/media/photographs/carved-ceiling.webp) #### Safdarjang at dawn ![A palace lit up at night](/media/photographs/palace-at-night.webp) #### Fav hues in Delhi ![Plant shadows on turquoise](/media/photographs/turquoise-shadows.webp) #### Light & shadows of Kalpa ![Light on a green stairway](/media/photographs/green-stairway.webp) #### Stuck in Bangalore traffic ![A portrait in red window light](/media/photographs/red-window-light.webp) #### Scenes after the traffic ![A night out with a friend](/media/photographs/with-a-friend.webp) #### Hungry, yet charming ![A quiet moment at the table](/media/photographs/at-the-table.webp) #### Thrifting from MKT, Delhi ![Out for a city walk](/media/photographs/city-walk.webp) #### Kinnaur from my room in Kalpa ![Snow beyond the branches](/media/photographs/snow-and-branches.webp) #### Rohtang Pass, first Himachal trip ![Among the mountains](/media/photographs/among-mountains.webp) ### Interactive explorations Explore the garden, play the mascot slingshot game, and rotate or switch between the three avatars. ## Design Valley ### A playlist for your moment **Product** · Product, Web Tell Curator what you’re doing. It builds a playlist you can shape with controls for mood, energy and discovery. Try the interactive concept with sample tracks; playback is simulated. ![A playlist for your moment](/media/project-valley/spotify-poster.webp) [Curator walkthrough — video](/media/project-valley/spotify.mp4) [Interactive prototype](/prototypes/spotify/index.html) #### A nice surprise ![Spotify’s conversational interface playing a requested mix of Bad Bunny songs.](/media/project-valley/spotify-conversation.webp) About a week after this exploration, Spotify introduced a conversational feature of its own. It was exciting to see a similar direction go live. [View Spotify’s post](https://x.com/Spotify/status/2077016125582266789?s=20) ### Pickem, in motion **Motion** · Motion, Product Two motion studies from Pickem: a theme switch from day to night, and a blur transition inspired by the iPhone Duo opening animation. ![Pickem, in motion](/media/project-valley/pickem-theme-poster.webp) [Theme switching — video](/media/project-valley/pickem-theme.mp4) [Duo-inspired blur — video](/media/project-valley/pickem-duo.mp4) App Store release coming soon ### Your creative archetype **Web** · Web, Motion A small souvenir for the AI Creatives Hackathon. Answer a few questions about how you create, then discover your archetype: Alchemist, Architect, Dreamer or Explorer. ![Your creative archetype](/media/project-valley/archetypes-poster.webp) [Creative archetype experience — video](/media/project-valley/archetypes.mp4) [Find your archetype](https://lifeatflytbase.com/hiring-hackathon/roles/creatives/souvenir) ### Proof of the trip **Product** · Product, Motion A Google Maps concept born from a disputed auto-rickshaw fare. The arrival screen keeps the distance, time and route together in a trip receipt you can share or save. ![Proof of the trip](/media/project-valley/maps-poster.webp) [Arrival interaction — video](/media/project-valley/maps.webm) [Read the story](https://lnkd.in/p/gyYFZr_c) ### Netflix as an AR interface **Web** · Web, Motion An AR-inspired interaction exploration for browsing Netflix with hand gestures. Wave to browse, point and push to open, and make a fist to shuffle or close. Best tried on desktop with camera access. ![Netflix as an AR interface](/media/project-valley/netflex-thumb.webp) [Netflex walkthrough — video](/media/project-valley/netflex.mp4) [Explore Netflex](https://netflex-browse.vercel.app/) ### A clearer path abroad **Web** · Web A study-abroad website exploration for Ambitio, bringing programme discovery, guidance and the next step into one page. Desktop and mobile layouts, side by side in the same study. ![A clearer path abroad](/media/project-valley/ambitio-desktop-thumb.webp) ![Desktop design](/media/project-valley/ambitio-desktop.webp) ![Mobile design](/media/project-valley/ambitio-mobile.webp) ### Pocket play **Illustration** · Illustration A Figma Draw exploration of a handheld console, using layered shapes, gradients and highlights to study light and depth. ![Pocket play](/media/project-valley/controller-thumb.webp) ![Handheld console study](/media/project-valley/controller.webp) ### Start a saving habit **Product** · Product A mobile onboarding exploration for Vault, from the first introduction to setting up an account. Clear steps and a calm visual rhythm for getting started. ![Start a saving habit](/media/project-valley/vault-onboarding-thumb.webp) ![Welcome to Vault](/media/project-valley/vault-onboarding.webp) ![Account setup](/media/project-valley/vault-setup.webp) ### Flight at your fingertips **Motion** · Motion, Product A mobile drone-control interaction study, exploring how a compact directional control can feel responsive while keeping the aircraft in view. ![Flight at your fingertips](/media/project-valley/drone-poster.webp) [Drone control interaction — video](/media/project-valley/drone.webm) ### A little currency clarity **Product** · Product A compact GBP-to-INR currency widget exploration for Aspora. The rate, amount and change are brought together in a small, glanceable surface. ![A little currency clarity](/media/project-valley/aspora-thumb.webp) ![Currency widget variants](/media/project-valley/aspora.webp) ### Out for delivery **Illustration** · Illustration A Figma Draw exploration of a delivery card, experimenting with a translucent surface, a parcel illustration and soft shadows. ![Out for delivery](/media/project-valley/delivery-thumb.webp) ![Delivery status card](/media/project-valley/delivery.webp) ### A pocket-sized throwback **Illustration** · Illustration A Figma Draw exploration of the Game Boy, using shape, shading and small details to give a familiar object depth. ![A pocket-sized throwback](/media/project-valley/gameboy-thumb.webp) ![Game Boy illustration](/media/project-valley/gameboy.webp) ## Case studies ### FlytClip FlytBase / Shipped product / FlytClip Drone footage became a report operators could approve and share. An outside recipient needed to understand a drone mission without opening FlytBase or assembling the story from raw files. I designed FlytClip around an evidence package that carried media, context, and reviewed findings together. The operator could edit AI drafts, approve the report, and share its evidence through a controlled link. [Read the case study](/work/flytclip) ![FlytClip Studio with drone video, selected media, and report review controls.](/media/case-studies/flytclip-studio.jpg) The shipped Studio is where the operator selects media, adds context, and prepares the report for review. - **My role:** Product strategy, design, and AI-assisted frontend / backend implementation. - **Ownership:** Identified the problem and owned the product from definition through shipment. - **For:** Drone operators and external recipients reviewing mission evidence. #### Contents - [Overview: Drone footage, ready to share](/work/flytclip#case-title) — Selected media, mission context, and reviewed findings travel together in a report the operator approves before sharing. - [Problem: The handoff after the mission](/work/flytclip#case-chapter-1) — Recipients outside FlytBase needed a clear account of the mission, without the operator assembling another long PDF. - [Design decisions: Designing the evidence package](/work/flytclip#case-chapter-2) — Media, source playback, report review, and claim attribution form one evidence package the operator approves before sharing. - [Implementation: Build around the review rule](/work/flytclip#case-chapter-6) — Small working slices progressed from mock contracts to real media, with tests guarding review and publication rules. - [Outcome: An approved report, ready to inspect](/work/flytclip#case-chapter-7) — FlytClip shipped a connected path from mission footage to a shared report, keeping context, evidence, and claim origins visible. #### The mission ended. The handoff didn’t. Problem · Sharing outside FlytBase One customer’s recipient had no FlytBase access. The operator had to find media, select evidence, and assemble a long PDF before anyone outside the platform could understand the mission. Flight logs and Reports already served record-keeping. I built the missing handoff: selected media, context, and reviewed findings in a recipient view that exposed the supporting evidence. ##### 01. Find Locate the relevant mission media. ##### 02. Curate Decide what matters and add context. ##### 03. Review Own the complete composition. ##### 04. Share Let the recipient inspect the evidence. I prioritized the DFR handoff, where a responder may need the evidence without being a FlytBase operator. #### The report had to carry the footage’s context. Product model · Packaging media with context A clip link left the operator explaining what the recipient was looking at. I made the shareable object an evidence package: selected media, mission context, findings, observations, and review state. The original media stayed in FlytBase. The same package carried its context from the first working prototype through review and into the recipient’s view. ![FlytClip media selection showing mission clips ready for an evidence package.](/media/case-studies/flytclip-media-selection.jpg) Select mission media first. The package carries its operational context through to the recipient. ##### What a link left behind The recipient gets a clip. The sender still has to explain what it shows and whether its conclusions were reviewed. ##### What travelled together Media, context, and review state stay together as the operator prepares and shares the account. #### The recipient needed the moment and its source. Video playback · Keeping clips tied to the source To inspect a finding, the recipient needed the relevant part of the source. A rendered-trim path briefly existed, but it added processing, storage, and another file to manage. The flow changed to saving a playback window against the original video. The operator sets the range in Studio; the controlled viewer presents that saved portion of the same source, without generating a separate trimmed file. ![FlytClip Studio playback range controls beneath the original mission video.](/media/case-studies/flytclip-studio.jpg) Studio capture: the orange range handles and Save playback window control define the source segment to present. ##### What this removed A second video-processing and storage lifecycle. FlytClip saves the source reference and playback window rather than another rendered clip. ##### What it depended on The original video must remain available, and the permitted window must be enforced reliably. The shared experience is view-only, not a downloadable clip. Expiry and revocation close the share link. They do not delete the original Gallery video. #### AI could draft. The operator approved the report. Report review · Operator approval before sharing A generated report could look complete before anyone checked it. I kept findings as candidates and let the operator edit the account while inspecting the exact report prepared for the recipient. Inline edits shaped the findings; one approval committed the complete report. That removed repeated approval actions, but put more weight on checking every required field and evidence plate before publication. ![FlytClip report drawer with draft findings and approval controls.](/media/case-studies/flytclip-report-review.jpg) The report drawer keeps candidate findings in a private review step before approval. ##### 01. Private analysis Candidates stay in the workspace. ##### 02. Review & edit The operator shapes the report. ##### 03. Approve One decision on the composition. ##### 04. Share Only the approved view is public. ##### Evidence changes → review again Changing media or context makes earlier analysis stale. Missing references and incomplete results cannot cross the approval boundary. ##### Only the approved account The public payload is explicitly allowlisted. Prompts, provider responses, rejected candidates, and diagnostics remain private. #### The report had to show who made each claim. Claim attribution · Separating operator notes from AI The first rule kept a note private unless it supported an AI finding. In the running product, that meant the model could silence knowledge the operator brought from the site. I gave approved Operator Observations their own place and linked evidence. AI Findings stayed separate, so readers could see who was making each claim. ##### AI Finding A model-generated candidate, reviewed by the operator. Its source is visible. ##### Operator Observation A human assertion, approved independently. Its evidence travels with it. ![Shared recipient view with source video and the approved report.](/media/case-studies/flytclip-recipient-viewer.jpg) The recipient can inspect source media beside the approved report, with operator observations and AI findings kept distinct. Independent observations preserved the operator’s voice, at the cost of more provenance and publication rules. Evidence Plates kept both kinds of claim inspectable; weak crops fell back to the analyzed frame. #### The review rule had to survive the build. Implementation · Building and testing the report flow I built on FlytBase’s shared app foundation. Agent-readable rules guided Codex through small working slices, first with mock contracts and then with real media and services. Codex helped implement the slices; the report AI drafted findings inside FlytClip. I checked the running behavior against the evidence, review, and publication rules, then owned the tests, staging checks, and release judgment. ##### 01. Frame the rule Define meaning, private states, and scope. ##### 02. Build a slice Constrain the agent with mock contracts. ##### 03. Test the meaning Review behavior with real media. ##### 04. Verify & ship Revise UI, contracts, and checks together. > Working software exposed the gaps. When operator knowledge disappeared, I revised the rule, interface, and checks together. #### Recipients could inspect what the operator approved. Outcome · Sharing an approved evidence report FlytClip shipped a connected path from mission footage to a recipient-facing report. Context, source evidence, and the origin of each claim stayed available for inspection; the operator approved what was shared. I now start with what the recipient must be able to check: whose claim it is, what supports it, and what approval allows them to see. What does the weather actually allow? Flight guidance with an inspectable source, time horizon, and operating limits. [Explore Weather Intelligence](/work/weather-intelligence) ### Weather Intelligence FlytBase / Shipped product / Weather Intelligence Weather data became flight guidance operators could inspect. Remote drone operators needed to know whether a site was ready now or a planned mission remained viable later. I translated the brief and expert guidance into rules for which weather source to use and how limits changed during flight. The product showed the basis of its guidance while the operator kept the final flight decision. [Read the case study](/work/weather-intelligence) ![FlytBase Docks overview with weather guidance alongside the fleet.](/media/case-studies/weather-dock-overview.jpg) The shipped Docks overview shows the current verdict, its key factors, and the weather feeds beside the fleet. - **My role:** Product design and AI-assisted frontend / backend implementation. - **Ownership:** Took an assigned brief through design, build, and shipment. - **Collaboration:** Subject-matter experts advised source meaning and drone-operation rules. #### Contents - [Overview: Weather guidance you can inspect](/work/weather-intelligence#case-title) — Source, time horizon, and flight phase explain the guidance, while operators keep the final decision about flying. - [Problem: Make the answer inspectable](/work/weather-intelligence#case-chapter-1) — Operators needed to understand the evidence and limits behind the guidance, including weather services they already trusted. - [Design decisions: Designing inspectable guidance](/work/weather-intelligence#case-chapter-2) — Sources, flight phases, fallback rules, and wind freshness made guidance inspectable. The overview redesign stayed planned. - [Implementation: Test the rules against real data](/work/weather-intelligence#case-chapter-7) — Mock states became real provider integrations, with checks for source eligibility, thresholds, and unreliable readings. - [Outcome: Keep the flight decision human](/work/weather-intelligence#case-chapter-8) — The shipped guidance showed its sources, time horizon, and operating limits so operators could inspect the basis and decide. #### Operators needed to inspect the answer. Problem · Deciding when to fly I started by assuming operators needed fewer weather dashboards. A product discussion challenged that: someone might already trust one regional service. I designed guidance around the question being asked, the evidence allowed to answer it, and the flight phase. Operators could inspect the source and limits while keeping the final flight decision. > What supported this answer? The operator retains the final flight decision. The interface makes the evidence and its limits inspectable. ##### Current readiness Does the available local or eligible nearby evidence support flying now? ##### Future viability What does the outlook suggest for a mission planned later today or this week? #### Now and later needed different evidence. Source selection · Different evidence for now and later The first step was deciding what each source could mean. With subject-matter experts, I separated local readiness, eligible nearby aviation evidence, and forecast-based planning. The interface retained the source behind its guidance. Forecasts stayed advisory for current readiness by default, and limited or unavailable states remained visible when the evidence could not support an answer. ##### 01. Local sensor First source for current site conditions. ##### 02. Eligible METAR Nearby aviation evidence, when eligible. ##### 03. Forecast Later planning; advisory now by default. ![Weather forecast outlook with a viability timeline and site map.](/media/case-studies/weather-future-outlook.jpg) The outlook exposes changing viability over time instead of presenting a forecast as a live site reading. ##### A traceable answer One eligible source drives the current verdict. Disagreement stays visible instead of being averaged into a reassuring number. ##### Less apparent completeness A reachable forecast cannot always fill a missing current reading. Limited or unavailable states are accepted when the evidence cannot support the answer. #### The guidance changed when the drone took off. Flight phases · Changing limits after takeoff A launch verdict stopped making sense once the drone was airborne. The language and limits needed to follow the flight, including its different launch and landing constraints. I carried flight phase into the guidance. In-flight conditions could be nominal, need monitoring, or prompt an advisory return home, rather than label an airborne drone “grounded.” ##### 01. Before launch Ready to fly ##### 02. In flight In flight · nominal ##### 03. Conditions worsen Monitor / advisory return-to-home ![In-flight guidance with flight status, weather sources, and a map.](/media/case-studies/weather-in-flight.jpg) The in-flight surface uses phase-appropriate language and distinguishes telemetry from weather sources. Phase-aware guidance added rules and states to test, but avoided applying launch limits after takeoff. Drone telemetry stayed labeled as estimated wind resistance, giving operational context without presenting it as a calibrated weather reading. #### I planned a clearer path to the evidence. Planned redesign · Simplifying the dock overview The shipped overview made the reasoning inspectable by showing the verdict, key factors, and every feed. It also repeated evidence detail available in the dock and graph layers. The archived PostHog checklist report recorded more actors at fleet review than at dock-decision and evidence-detail steps. The counts did not track an ordered journey or establish drop-off. I used that pattern to explore a simpler overview, with supporting evidence available on demand. ![Weather Intelligence Docks overview. Numbered outlines identify the flight decision, key factors and weather-feed status columns across the first three dock rows.](/media/case-studies/weather-dock-overview.jpg) Shipped dock overview The shipped overview placed the decision, conditions and every feed side by side. These annotations explain that existing screen; the proposed simplification below was not shipped. ##### 1. The decision and its reason Each dock shows a verdict and its main driver. A missing required sensor can leave it with no verdict, even when other feeds are live. ##### 2. The conditions behind it Wind, gust, temperature and humidity sit beside the decision, adding detail to every dock row. ##### 3. Every feed’s status Sensor, METAR, forecast and drone-data statuses remain visible. A live feed is not necessarily the source used for the verdict. ##### Keep the decision up front. Planned · not shipped Move supporting evidence into dock details, while keeping the current decision and its active source in the overview. ###### Shipped overview: All three layers in every row - **Decision:** Current verdict and its main driver. - **Conditions:** Wind, gust, temperature and humidity. - **Feeds:** Status of every weather source. ###### Planned simplification: A summary, with a deeper view - **Visible in the overview:** Current decision, driving condition and active source. - **On opening dock details:** Other feeds, source comparisons, freshness, graphs and diagnostics. The trade-off: a simpler overview, with an extra step to inspect supporting evidence. The rules for choosing the active source would stay the same. This direction was not shipped before I left. #### One site’s fallback stayed explicit. Customer exception · Forecast fallback without a sensor The source hierarchy also met a real constraint: one customer had no local sensor and already relied on an external forecast provider. I added an organization-level provider policy that stayed visible and kept live sensor precedence. When a later simplification removed that accepted exception, I restored it. ![Weather provider settings for an organization-level exception.](/media/case-studies/weather-provider-configuration.jpg) Provider configuration supports an explicit, organization-scoped path rather than a silent global fallback. ##### A real site stays supported An explicitly approved provider fallback supports the organization without displacing a live local sensor. ##### More rules to preserve Organization-specific branching adds testing and maintenance. Simplifying to sensor-only would erase an accepted customer workflow. #### A convincing picture could still be stale. Wind visualization · Making stale wind data visible Inspectability also mattered in the altitude-aware wind view. I built freshness checks, field validation, diagnostics, and degraded states alongside the visualization. A frozen field could still look believable. Its visual quality only mattered if the product made stale or missing information clear. ![Regional wind visualization with altitude-aware data on a map.](/media/case-studies/weather-regional-wind.jpg) The altitude-aware wind layer provides regional context while preserving freshness and failure behavior. ##### 01. Validate Check the field and manifest. ##### 02. Publish Keep the data path accountable. ##### 03. Render Handle lifecycle and diagnostics. ##### 04. Degrade honestly Make stale or missing data explicit. ##### Failed updates stay contained Validated wind data is staged before the current manifest changes. A failed publish preserves the prior valid assets. ##### More than visual polish Validation, staging, diagnostics, and freshness handling add operational work. Retaining an older valid bundle does not make it current. #### Real data tested the guidance rules. Implementation · Integrating and testing weather data From FlytBase’s shared app foundation, I translated the brief and expert guidance into rules for source eligibility, thresholds, and unreliable data. I directed AI-assisted slices from mock states to real providers, then reviewed behavior, tests, and builds. I owned the interpretation, exceptions, and release judgment. ##### 01. Interpret Brief and subject-matter guidance. ##### 02. Constrain Rules and mock-backed edge states. ##### 03. Integrate Real sources, platform, and backend. ##### 04. Revise & verify Failures feed back into the rules. Wrong-phase labels, old readings, and the lost customer exception sent me back to the rules, then to the interface and its checks. #### Operators could inspect the guidance and keep the decision. Outcome · Guidance operators can inspect The shipped product connected current and future flight questions to the source, time horizon, and operating phase behind the guidance. Operators could inspect that basis and retained the final flight decision. The planned overview asked how to make that basis easier to reach while reducing the feed detail at first glance. I now define the operator’s question and the evidence that can answer it before designing the screen. > Make the answer possible to question. Source authority, operational phase, and visible limits are part of the interface. Who gets to turn evidence into a claim? A controlled handoff from mission media to an approved recipient report. [Explore FlytClip](/work/flytclip) ## The little things matter to me. I used to fill the margins of my notebooks with drawings. During COVID lockdown, I started designing for [@pulp.ithihasam](https://www.instagram.com/pulp.ithihasam/). I kept learning at IIT Madras, and somewhere along the way, I started building the things I wanted to design. AI helped me write the code for this portfolio. I shaped the idea, the design, and every little interaction. The flowers, the notebook, even the way a page slows down when you scroll. I kept coming back to these details because I wanted them to feel right. I wanted this place to feel like me. That’s the care I bring to my work. If you’re building something and feel we’d work well together, I’d love to hear about it. ## Contact [Let’s chat](mailto:abhiramvm14@gmail.com) [abhiramvm14@gmail.com](mailto:abhiramvm14@gmail.com) [X](https://x.com/akkwho) [LinkedIn](https://www.linkedin.com/in/abhiram-vm/) [GitHub](https://github.com/pixlncode) [Résumé](https://drive.google.com/file/d/15xi1gAQMw5jep7YO719vZalVdxqRr3wX/view?usp=sharing) Abhiram V M © 2026