FADZ

Computer Science graduate based in Melbourne — curious by nature. I like understanding how things work, solving problems and working with people along the way.

Fadzly Eiman

Melbourne, Australia (AEST) —:—
Open to opportunities
Scroll ↓
Fadzly Eiman
About me

A CS foundation, and a soft spot for the messy parts in between

I studied Computer Science at RMIT because I liked how things were built, but the part of university I got the most out of was figuring out how to explain technical ideas to people who didn't think in code.

My first real look at the industry was a front-end development internship at M+ Software, working on an internal ideas-management platform called Kiakoe. It was hands-on, occasionally frustrating in the way debugging always is, and it led directly to my next role.

From there I moved into a Junior ERP Consultant role at Portcities, an Odoo consultancy in Melbourne. I expected to spend most of my time writing configuration. Instead I spent a lot of it in the middle — translating what a client was describing into something a developer could act on, tracking down issues, chasing timelines, and helping keep everyone (clients, developers, operations teams, people in different countries and time zones) roughly on the same page.

What I enjoyed most was that middle ground. I'm particularly interested in roles where technology, people and business problems overlap — technology consulting, graduate programs, and IT roles where I'd get to keep building that skill set. I'm still early in my career, and I'm looking to continue building from here.

A few things about me
Currently into

Movies that require me to watch three prequels first · Almond croissants · Fitness · Cat reels · Flat noodles

A random fact

I played flute in an orchestra and once performed at Dewan Filharmonik PETRONAS in the Petronas Twin Towers.

Pet peeve

When someone asks me questions during a movie we both haven't seen before.

Always down for

Crossing Melbourne for a restaurant I saved on TikTok six months ago.

Experience

Where I've worked so far

01

Junior Consultant

Portcities (formerly M+ Software), Melbourne · December 2025 – July 2026
  • Worked closely with developers, operations staff and clients to resolve issues and keep project activities on track
  • Maintained project records, documentation and system updates across multiple projects
  • Prepared weekly reports and project documentation to track progress, identify issues early and keep clients and internal stakeholders informed
  • Assisted with day-to-day project administration, client communication, record keeping and follow-up tasks
02

Front-End Developer Intern

M+ Software, Melbourne · November 2025
  • Built and styled front-end components for Kiakoe, an internal product initiative
  • Worked alongside senior developers, quickly picking up new tools, development processes and coding standards
  • Tested and debugged UI components across different screen sizes, identifying issues and correcting them as needed
  • The internship led to an opportunity to continue with the company as a Junior ERP Consultant
03

Sales Assistant

Typo, Docklands · January – July 2025
  • Helped customers in store and over the phone, answering enquiries, understanding their needs and recommending suitable products
  • Processed transactions accurately while managing customer requests during busy trading periods
  • Kept merchandise, displays and stock areas organised and well maintained
  • Worked closely with the team to handle customer enquiries and keep day-to-day store operations running smoothly
04

Inventory Assistant

Blossom Costumes, Thomastown · July 2023 – November 2024
  • Recorded and checked daily stock movements, identifying and correcting inventory discrepancies to keep records accurate
  • Prepared, labelled and dispatched customer orders, handling more than 100 orders during busy periods
  • Received incoming deliveries, checked items against records and inspected product quality
  • Kept stock areas organised and supported the day-to-day running of the warehouse

Projects / Case Studies

01

Overview

At Portcities, I supported Odoo v14 → v19 upgrade projects across two client engagements. My work sat between testing, issue investigation, documentation and communication — checking migrated functionality, reproducing problems, working with developers and keeping project information organised.

02

My Role / What I Worked On

Junior ERP Consultant — supporting the project, not leading it.

Test

Checked migrated features module by module — Sales, Accounting, Inventory, Rentals, Repairs — against how they worked before.

Investigate

Reproduced bugs myself before handing them to a developer, so the report was specific rather than vague.

Document

Kept an issue log and a module audit up to date so the team always knew what was open and what was resolved.

Communicate

Wrote updates for developers, the internal team and the client — same issue, different level of detail each time.

03

A Few Problems I Worked Through

The bug only public visitors could see

Website · post-migration testing
+

Problem

A product page worked fine for me, but a client had reported it breaking for other visitors. I couldn't reproduce it while logged in.

How I investigated it

I worked out that browsing in an incognito window simulates exactly what a public, logged-out visitor sees — and used that to reproduce the error myself instead of guessing at it.

What happened / what I learned

I could now hand the developer a clear, reproducible bug report instead of a secondhand description. It also taught me that "I can't see it" isn't the same as "it isn't happening."

Old files, new system

Document storage · post-migration testing
+

Problem

After migration, some document links worked fine and others threw server errors on click — with no obvious pattern at first.

How I investigated it

I traced it to files that hadn't been copied across to the new system's storage yet, even though the record of each file had migrated correctly. Because it affected a large share of the catalogue, I flagged that a proper storage transfer at go-live would resolve it on its own.

What happened / what I learned

Rather than manually patching thousands of records, the team held off and let the planned migration step fix it properly. I learned that the right call is sometimes to wait, not to act immediately.

Marked as fixed — but was it?

Issue verification · UAT
+

Problem

A logged issue about duplicate records being created had been marked resolved by a status label alone.

How I investigated it

Instead of accepting the label, I tested the exact scenario myself on the test environment, step by step, to see what actually happened.

What happened / what I learned

The fix genuinely worked, and I could confirm that with confidence — but the habit stuck: I check things myself before signing off, rather than trusting that "done" means done.

The report that wouldn't cooperate

Odoo Studio · QWeb/XML debugging
+

Problem

A Field Service report could no longer be edited properly in Odoo Studio, which was blocking a requested change to the report. The issue involved several inherited QWeb and Studio customisation views layered on top of each other rather than one simple customisation.

How I investigated it

I investigated through Odoo's Technical > Views menu, traced through the relevant inherited views and Studio customisation layers, and inspected the XML. Once I understood the structure, I corrected it and removed the requested report sections, then tested the change in the development environment and confirmed the report printed successfully. Partway through testing, an edit I made in Studio introduced a separate printing issue — I caught it and reverted to the last known-good XML before continuing.

What happened / what I learned

The report printed successfully in the development environment, and the requested changes were ready to progress from there.

Odoo Studio QWeb / XML View inheritance Technical debugging Testing
04

Project Artefacts

I can't share the real client documents, so these are recreated from scratch with fictional data, to show the shape of the work rather than the content.

Recreated — fictional data
UAT / issue tracker
Sample issue log
Sales — order confirmationResolved
Inventory — stock countIn review
Rentals — extension flowOpen
Accounting — statement exportResolved
Migration / testing workflow
How a feature moved through testing
Old system
(v14)
→
Test & log
issues
→
Developer
fix
→
Verify &
close
Module audit
Sample status view
Reviewed & migrated In progress Pending decision
05

What I Took Away From It

This experience taught me that solving a technology problem isn't always about immediately changing the system. Sometimes the first step is understanding whether something is actually broken, whether behaviour has changed between versions, or whether the issue needs to be explained differently to the user.

I also learned to verify things myself rather than relying only on a status update, and to communicate the same technical issue differently depending on whether I was speaking with a developer, an operations team or a client.

UAT & QA testing Issue tracking & documentation Root-cause investigation Cross-audience communication Developer coordination Independent verification Odoo Studio & QWeb Technical debugging

I contributed to the front-end of Kiakoe, an ideas-management platform where users could submit and vote on ideas, rank them by preference, and where admins could manage entries.

Working alongside more experienced developers gave me my first exposure to contributing to a real team codebase outside university.

The project ultimately didn't progress to a public release.

Front-end development Working in a team codebase Adaptability

Relay is a small internal IT support tool, built end-to-end to demonstrate how I'd actually approach a workplace ticketing system — not just CRUD, but the workflow behind real support: guided intake, evidence gathering, and spotting when several reports are really one incident.

It has two deliberately different experiences on the same data: a simple, plain-language portal for employees reporting a problem, and a proper work-queue view for IT — grouped by what needs attention next rather than a raw ticket count.

Guided issue intake Related-incident detection Incident grouping SLA tracking Employee / IT dual experience No-login demo mode

One feature I'm particularly glad I built: when several employees report similar problems close together, Relay flags it as a possible wider incident — and shows exactly why it thinks that (same category, same location, how many minutes apart, which words overlap), rather than a black-box "AI detected this."

Stack: Python, Flask, SQLite, server-rendered Jinja2 templates, vanilla JS.

Live demo →

A tool for tracking company IT assets (laptops, licences, equipment) alongside the support requests linked to them — so a technician can see an asset's history and open tickets in one place instead of two separate systems.

Asset register Assignment history Linked support tickets Lookup & reporting view

Early days — design and data model in progress, following on from what I learned building Relay. More detail (and a stack) will go here once it's further along.

Skills

What I can bring to the table

Technology

  • ERP systems (Odoo)
  • Front-end development
  • Python
  • SQL
  • Git / GitHub
  • Microsoft Excel
  • Troubleshooting & issue investigation

Consulting & projects

  • Requirements gathering
  • Documentation
  • Issue tracking
  • Stakeholder communication
  • UAT coordination
  • Reporting

People

  • Customer service
  • Client communication
  • Teamwork
  • Working across cultures & time zones

SAY
HELLO.

I'm always open to conversations about opportunities, interesting projects, or just saying hi. I promise I reply.

Email eimanfadzly@gmail.com
LinkedIn linkedin.com/in/fadzly-eiman
GitHub github.com/eimanfadzly