Mădălina-Eleonora Gheorghe | UX & Product Transition

Work Experience

Assignment 1: Nov 2025 - Present

Access & Permissions Platform (RBAC)

The application everyone in the organisation uses to enrol and administer the people and client companies who have access to our products, and to change a role when it is wrong. The application is itself governed by the thing it administers: what any one person can do inside it depends on their own role, so some reach all of the functionality and others only the part their role allows. Production holds the real client companies and every enrolled user, so seeing the true state of someone’s access is the whole job: it is also where a report that somebody cannot reach one of the products gets answered. It is the furthest along of the five products I work across, and like the rest of them still taking improvements and new feature requests. It is the main assignment, and the code I own.

The project already existed and could not be maintained. Organisational changes brought these applications to Romania, so the Romanian organisation inherited a codebase that was unreadable and inefficient. The lead and the architect had already decided, before I joined the team, that rewriting and carrying on would cost less than repairing it. I arrived into that rewrite, and everything else here is the work of carrying it out. It is one part of a larger transition: for years every client got its own copy of the same application, and the direction now is one configurable platform serving all of them instead of separate codebases to keep in step. Around 90 people in the Romanian organisation work on the same estate.
The rewrite is eleven applications behind one shell in place of a single monolith, with each area loading only for a user entitled to it. The lead gave me one example of what a remote application should look like and we went from there. Six of the eleven I built from scratch; the other five I inherited from other people, then fixed and improved. There is now no part of it I have not worked in.
A few months ago the lead said in front of the team that I am the code owner, and he no longer touches the code there. I had refactored and improved most of the application by then, taken it to Angular 21 and reworked the interface.
The golden set: a permission-import feature so that configuring a brand-new client is a clone rather than a rebuild — import an existing client’s permission set as a file, then adjust it. The harder problem was that nobody wanted to use it. Importing is destructive, and enough had been broken by earlier imports that repairing the damage had become its own recurring job. The import now shows exactly what it will change before changing anything, which is what got it used.
Built the delegated-access programme end to end on the frontend: one person acting for another under constrained entitlements: a permissions question as much as an implementation one. Multi-factor-authentication management is another of the sub-applications I built out, over Keycloak and OIDC.
The hardest part was never the development. It was learning what the business words mean — what a ManCo is, what the product is, how capabilities link together. The code was the part I already knew how to do.

Featured Recommendations

...can independently take over and deliver complex features... constantly pays attention to details...

Tech Lead

Tech Lead

...good coding style... quickly integrate... she is great at estimating how long something will take...

Peer

Frontend Developer

...reliable partner... clean code... Reliability on solving problems and unblocking others.

Peer

Frontend Developer

Assignment 2: Nov 2025 - Present

Shared component kit, layout library & Material 3 theming

The Material components behind the permissions platform, built alongside it from the start and improved since for ARIA and keyboard behaviour. Seven applications had been copy-pasting them from each other, so in September 2026 I started pulling them out into one source of truth, where a fix happens once instead of in every copy. It is deliberately an interim library of our own, until the company-wide component library now in progress is stable enough to install. On a design agreed with the lead.

Moved the table filters into the table. The problem was screen space: filters sat in a row of text boxes above the table and we needed those lines back for data, so the filter went into each column header instead. It touched every table in the application and all of it had to be retested, which is why I converted one table first and showed it working rather than asking for the change in the abstract. People liked it, and we agreed together to convert the rest.
The consolidation argument only became winnable once I measured it. Six findings, all checkable by anyone who doubted me. Among them: seven components whose "simplified" forks were larger than the original; three pairs sitting byte-identical in different applications and kept in step by hand; and forks that had gained useful features and never sent them home, so one application was quietly holding a better version than the one everyone treated as canonical. That last part is what made it more than a tidiness argument.
The kit is 33 components carrying ~1,050 tests between them — built over the life of the permissions platform and now being reconciled into one place rather than rewritten, merging duplicate types instead of importing them twice. The blocker was a dialog service referenced in 60 files that everyone assumed was too entangled to touch; I split its generic half from its domain-coupled half and costed the migration at ten import lines, and that number is what got it agreed. Virtual scrolling started with the lead; I carried it into the other lists and trees across the estate that were large enough to need it.
Moved the estate’s data grid into a library of its own. The lead had written the first version inside one project and it had been copy-pasted into several more; I moved it out, then built it up from there, the dynamic inline column filters included. Wrote the kit’s tree and its autocomplete components, some of which the lead improved afterwards.
Designed the one component the estate did not have: inline-editable table cells. Nothing saves optimistically, so the table and the page can never disagree about a value. The input goes read-only rather than disabled while saving, because a disabled input drops focus and a rejected save would reopen with the caret nowhere useful. And a verdict arriving after the user has pressed Escape is discarded rather than applied to a field they have walked away from.
Migrated Angular Material M2 to M3 behind a two-layer token system, unprompted — the lead and I improve the applications we work in whenever it can be done without breaking anything, so he saw this one after it was done. Every token falls back to a Material system property and then to a literal, because an application that has not installed a theme should still render correctly rather than render broken. 69 colour tokens mapped deliberately, including the families Material has no equivalent for.
A cleanup nobody enforces comes back, so the kit includes the tests that keep it true: 356 assertions that no stylesheet has reintroduced a colour literal or reached into another application, and 48 checked against every generated theme to catch a mistyped token name — which otherwise looks exactly like a deliberate fallback. Extracted five copy-pasted forks of the grid and layout SCSS into one framework-free published library, and cut a remote’s runtime entry bundle by 68.6% (508 kB to 160 kB).

Assignment 3: Aug 2026 - Present

Reference-data & content administration applications

Administration interfaces for reference data, published content and taxonomy across the client-facing products. The lead owns the content-management application and I contribute updates and fixes there; I own the reference-data side and the estate’s single source of truth for applications and resources.

Rebuilt the last thing standing in the legacy codebase. One reference-data application was all that remained in the old permissions codebase. It was not in use any more, or not yet, but it could not simply be deleted, so I asked the architect what should happen to it: fold it into the permissions platform, or stand it up on its own. He decided it should be an application of its own. Parts of it had never been finished and there was nobody left to ask what they were meant to do, so I went back to the original documentation and rebuilt the missing behaviour from that. Completing it is what lets the legacy codebase finally be archived: there is nothing left to migrate out of it.
Built the estate’s single source of truth for applications and resources. The idea was the architect’s, raised in a daily call. I ran a spike to work out what it would need, built it in spare time, and own the code now.
Rebuilt the content-list, tag and category pages off two third-party rendering libraries and onto our own components, which removed both dependencies and gave those pages the estate’s standard paging, filtering and accessibility behaviour without writing any of it again.

Assignment 4: Nov 2025 - Sep 2026

Administrator configuration panel

Where application administrators configure the platform, one micro-frontend per configuration area. Used by administrators only, not by the people the products serve.

Data-transformation configuration: the first feature at the company, built with the lead (Nov 2025). Set up a new micro-frontend from nothing and built the configuration of how a client’s data is transformed on its way through the platform. The extensions it needed later went to another developer, by which point I was in full-time development on the permissions platform.
Built the frontend of the notifications configuration micro-frontend (Jun–Sep 2026): creating a notification type, and the event that fires it.
The notification widget itself sits in the applications rather than in the panel. The lead started it; I refactored and redesigned it: a different design for each notification status, its own redirect target so opening one goes straight to the thing it is about, and an animation as a new one arrives. Each notification carries a read and a delete action, except an important one, which renders differently and cannot be deleted.

Assignment 5: Jan 2026 - Present

Platform TypeScript SDK

The typed client every application in the estate talks to the backend through, generated from OpenAPI specifications. The lead built it; I co-maintain it and run it day to day. Everyone builds against it, so when it stops, everyone stops.

Keep it releasing on every merge rather than on someone remembering: 14 OpenAPI specifications become four published packages, so no consumer waits on a manual publish.
Added specifications and clients as new backend surface arrived, including delegated access and device registration, keeping generated types consistent across every application that depends on them.

Assignment 6: Nov 2025 - Present

Design & accessibility

The design language the estate shares, and the accessibility behaviour built into the components that carry it.

Product design. Our designer produced a first draft for one application, covering where the header and sidenav should sit. I took it from there: designed the screens the draft did not cover, applied the language across every other application in the estate, and refined the original as the products grew.
Accessibility, as I build. ARIA attributes, keyboard interaction, per-row labels on data tables so a screen reader announces which row an action belongs to, and focus management and restore in dialogs, written with the component rather than retrofitted. What a consuming application still has to do itself is documented per component, so the next person cannot miss it.

Assignment 7: Nov 2025 - Present

Mentoring, interviewing & practice

The part of the job that is not a product: who I bring in, who I teach, and how I stay fast in code I did not write.

Interviewing & hiring. Ran the technical interview for two partner-vendor engineers joining the team in August 2026, and fed into the hiring decision.
Mentoring. Mentoring engineers on our India-based team since new joiners arrived in August 2026, and the person peers come to when a change crosses code they do not know.
A verified engineering knowledge base. Dense reference notes on the whole estate, every claim traceable to a file and line and re-checked rather than assumed. It is how I get productive in an unfamiliar application in hours, and the only reason the six measurements behind the consolidation argument existed at all.
AI-assisted delivery. Automate the repetitive half of the work with AI tooling (Claude Code CLI, MCP-connected Jira and Confluence): scaffolding, mechanical cross-application refactors, reading unfamiliar code faster before a review, and drafting ticket and documentation updates.

Assignment 1: Jan 2023 - Sep 2025

Banking fraud-detection platform

Around 11 Angular screens used by a Belgian retail bank’s security agents, in four languages. Two jobs: watch whether the volume of fraud is inside a safe limit and escalate if it is not, and work the review queues of suspicious transactions — human-initiated fraud, automated attacks run by scripts and websites, new device enrolments, and the cases needing two agents to approve — deciding on each one whether to allow it, block it, or telephone the customer. I started it with the tech lead, whose part of the screens was the first two queues; I built every screen after that, ran the frontend after she left, and was Interim Team Lead by the end.

Started the application with the tech lead and learned it from her, and her part of the screens was the first two queues. Every screen after those is one I built. She was the team’s only lead, covering both frontend and backend, so she was constantly in meetings and ownership of the code came to me as I went. When she left on maternity leave I was the only person who knew both the codebase and the business rules — which is why speaking for the frontend in business meetings came naturally rather than as a promotion I had to argue for.
Every transaction closed as one of four recorded outcomes: confirmed fraud, cancelled by the customer, referred to the customer’s branch, or false positive. Each opened a slide-in with its own checks and an email template already filled in from the case, because the notes written and the messages sent were tracked against the transaction. An agent finished a case without leaving the queue.
Case ownership and workload. An agent could take a transaction themselves or be assigned one; the two-agent cases had to be assigned explicitly; and a manager could move transactions off an agent who was out for the day onto someone else. Managers and team leads also had their own investigation screen over the same data, with bulk selection, bulk actions and filtering across up to a year of history.
Any transaction opened the whole customer — a detail page holding that customer’s transactions and their statuses, the beneficiary’s details and address, the device used, how their contact details had changed over time, and their relationships to other customers of the bank. Plus a search screen across all of it, and a screen where an authorised police investigator could be granted scoped access to one person’s history for an investigation.
The specifications came from the business analysts and the product owner, and I designed the screens that answered them, contradicting a requirement where it did not hold up. The large data-grid screens came out of that: the police-investigation screen, the managers’ and team leads’ investigation screen with its bulk selection and year-wide filtering, the search across everything, and the customer detail page. Working out what each of them had to show, and for whom, was as much of the work as building them.
Bulk reclassification through AG Grid, validated three times over: higher-role agents could change the classification of many transactions at once, but a transaction that should not be reclassified was not, even with manual override — checked first by the automatic system, then by business rules in the frontend, then again in the backend. The interface also tracked whether the customer had been called. An agent could not get it wrong, which was the entire point.
Role-based access control across the application, deciding with the business which roles should reach which screens. That is a permissions conversation as much as a technical one, and I was in it.
Won the UI/UX decision authority rather than being handed it. The business analysts had mapped the flows from their own point of view; I argued the position of a brand-new agent with no background in that business, alongside the technical view of what belonged where. Many calls, pros and cons on each. It ended with the business pulling me into the sessions with the actual agents and their department managers so I could get feedback first-hand. A process manager described me as the team’s "unofficial screen designer"; a manager review listed UX design among the tasks I took on outside the role. The disagreements were real and so was the relationship: a meeting spent arguing over who had it right ended with the same people from the client over coffee afterwards.
Learned WCAG for this work and argued the screens from it. Where a decision needed an international standard, or a tool’s real capabilities rather than what everyone assumed they were, I went and read them and came back with what they allowed.
Guidance built into the interface, because the application had to be usable by newly enrolled agents and by people transferred in from other departments — descriptions and indications throughout, treated as a requirement rather than a nicety. It ran in four languages (English, French, German and Dutch), with every string routed through i18n files.
WebSockets on the screens that needed them, so agents saw a fraud status change or a moving statistic as it happened instead of waiting on a refresh.
Release owner from the third release onwards — releases ran every two to three months, at 5am on a Saturday. No production incidents across the releases I owned, few defects reached the client at all, and those that did were fixed quickly.
Interim Team Lead: frontend architecture decisions, an Angular version upgrade, CI/CD deployments, sprint planning, and writing refinement descriptions clearly enough that colleagues were not guessing. Two colleagues went from delivering one story in two weeks to one story in three days.
Mentoring and code review: Angular practice and Jasmine unit testing, plus consistent review to hold quality as the team changed shape. I finished as the only frontend developer on the application, with one backend colleague and a new joiner I was bringing up to speed.

Featured Recommendations

Not only you help us with designing and developing screens for our end user, you also think with us to find the best suitable solution which is smart and user friendly.

Kathleen Renard

Process Manager

You are my favorite developer... you ask good questions so we as application manager can fill in the blanks... always thinking about finding good customer solutions.

Iris Vanstraelen

Application Manager

We appreciate: your ownership, your involvement, your E2E view... how you take up a key position after replacing the old Tech Lead...

Etienne De Paepe

Manager

Assignment 2: 2024 - Sep 2025

Employee access-management system

The second application the tech lead and I started from nothing: administering employees — checking a user, granting or replacing a role, editing their details. We grew it to a working MVP, after which it moved to a separate team under a new lead.

Started it with the tech lead and took it to MVP — the same pairing that had built the fraud platform, so the patterns and the ways of working carried across.
Stayed its point of reference after the handover: kept helping the new team, and the new lead in particular, with difficult Angular problems and with business decisions that needed someone who knew why the application worked the way it did.
Covered the application while that team was away for a month — the responsible person for it, as the only one who still knew all of it.

Assignment 1: Feb 2022 - Dec 2022

Internal banking application — sole frontend developer

Client and loan management for the staff of a banking client, built on Mambu’s core-banking platform and inside its constraints. The project had been started by someone else; I picked it up and carried it, and was the only frontend developer on it for eleven months. Also the first time I worked in React.

The only frontend developer for eleven months, on a project already underway when I joined. That meant working directly with every other role rather than through a frontend team — and being effectively unreviewed on frontend specifics, since code review came from backend-focused colleagues or from a principal frontend lead who did not touch the code.
Built the client-profile, loan-creation, refinancing and onboarding workflows. The loan work was flow, validation and state rather than computation — all the financial calculation sat in the backend.
Took over the Java PDF transaction-history reports the bank’s staff relied on. API changes were needed and the backend developers were occupied, so I made them myself. Then took on the document itself, which was not good enough: pagination, alignment, and the header and footer the bank is legally required to carry. Nobody asked for that second part.
Mambu was the year’s real difficulty, twofold: learning React while working inside a platform whose interface constrained what the frontend could look like, and then making that interface as good as it could be within those limits.
Configured the cloud environment and installed the applications there myself (AWS). Outside the frontend remit and outside what I knew when I started; it stood between the work and the people waiting for it, so I learned it. Other teams also came to me for the business and technical detail their own integrations needed.
Challenged the requirements and the input data rather than implementing them as written — mostly validation rules, and making sure a screen was usable at first glance by someone who had never seen it. A team lead singled this out in a review.

Featured Recommendations

Cristina-Mihaela Antohe

Senior Consultant

Pavol Tomek

Project Manager / Scrum Master

Andrei-Ioan Popescu

Team Lead

Assignment 2: Oct 2021 - Jan 2022

Insurance purchase & cover-upgrade platform — Deloitte’s Alpha Platform

An MVP on the Alpha Platform team, for a product Deloitte intended to own rather than deliver for a client: buying an insurance policy through a guided flow, and — if the cover turned out not to reach far enough — upgrading a policy already in force and paying only the difference. Two frontend developers, four to five backend, one designer.

Built the purchase flow and the mid-term adjustment flow: mid-term adjustment is upgrading a live policy part-way through its term, paying the difference rather than starting again. Upgrades only — the flow did not support downgrades or cancellation.
Worked with the designer every day as the frontend’s feasibility voice, feeding back what was and was not possible so the two of us improved the product together. The result was more consistent and easier to use than either of us would have got to alone — and this is the earliest point where design input was an explicit part of the job rather than something I did on the side.
Built for end users, not specialists. Whether the eventual audience was agents or customers directly was never settled while I was on it, so we made it simple enough for someone with no insurance background.
Went through the existing application and wrote up everything that could be better, a long list of it, then implemented a lot of those items inside a couple of weeks. Taught Angular to the colleague on the team who did not know it while doing that, on practice as much as on code. The Angular questions came from outside this project too: across the year at Deloitte I was the person people asked, which was never a title and was how it worked anyway.
The MVP finished and I moved to another project; I do not know what happened to the product afterwards.

Featured Recommendations

She gave a huge boost to our Web app development... The quality of the code she has been writing, and the overall work quality has been impressive.

Dragos-Vasile Lungu

Technical Lead

Assignment 1: Apr 2020 - Oct 2021

E-commerce platform & CMS — 6 grocery brands, Albertsons

One AEM-based CMS driving six brand websites for a major US grocery group, built by roughly 40 developers in Romania working alongside a similar number on the client side. I was on the product-browsing and cart team: product lists and carousels, add-to-cart, the product detail page, and the mini-cart in the site header.

Built roughly 90% of the coupon experience, the feature shoppers touched most. On a search or category page a product with eligible offers shows an "x coupons available" link; opening it slides in the offers with their terms ("20% off when you buy three"), and applying one strikes through the original price and shows the new one beside it. The same control repeats on the product page and inside the mini-cart, where applying a coupon turns green with a check, updates the order total in real time, and reports how many products the offer covers. Coupons could also be redeemed by code from the site or from the customer’s profile. The same machinery carried BOGO (buy one, get one) offers, where applying the code added a second unit at no charge.
Store-location logic driving stock availability, delivery pricing and in-store pickup — the omnichannel behaviour that decides what a customer is even allowed to order.
Everything shipped behind feature toggles controlled by the advertising side, which meant most components existed as two live versions at once and both had to work. It doubles the surface to maintain, which is why a toggle’s lifetime matters.
Separate applications that met in the browser. I used to call this a micro-frontend team, but it predates Module Federation — teams owned separate applications that integrated through shared browser storage rather than through a runtime contract. The modern term implies infrastructure we did not have.
One CMS drove six brands, so a change landed everywhere simultaneously and a bug could reproduce on one brand and not another. Working out the blast radius before changing anything was the daily discipline.
Wrote some functionality in plain JavaScript rather than Angular, either because it was a small AEM-authored component or because it was simply the leanest option: US shoppers on poor connections had to get a working page regardless of signal. Performance was tracked in the network panel, on total payload and CSS and JavaScript weight.
Accessibility was client-mandated and independently verified: ARIA, keyboard navigation and screen-reader behaviour (VoiceOver) were checked by testers on every ticket. Externally verified, not self-assessed.
Helped diagnose a production checkout outage: another team had given a CSS class the same name as one of ours, style encapsulation stopped holding, and a button disappeared on one brand’s site, so shoppers could not pay for around an hour. I was on call, and found the cause working through it with the senior developers. Scoped styles and token contracts are a correctness problem, not a tidiness one.
Also delivered a personalised reorder feature, real-time discount feedback with animations, daily build ownership, and feature demos for stakeholders.
Mentored one to two junior developers and wrote the learning plan for an IBM iX intern, onboarded new joiners into the wider IBM iX practice, and was the point of contact for the client’s US team, working US hours from Romania for the duration. Separately, taught a colleague enough Vue.js to start a new project in it, and contributed to a web-analytics project by reviewing colleagues’ code and building reusable components.

Featured Recommendations

...always reliable and helps her team members... strongly recommend her to any new opportunity and challenge.

Raluca Rusu

Project Manager

Madalina was my mentor... she was always eager to show me new front-end tricks and quirks. The proactivity which she possesses inspired me a lot...

Madalin Tuca

Frontend Developer

Appreciate your guidance and helping bring new talent to our wider iX IBM team... strong contribution to project delivery.

Alexandra-Luminita Tanef

Project Manager

Assignment 2: Mar 2019 - Mar 2020

Munich Re — offline tablet app, document platform & device compliance

Three applications for a reinsurance client, learning Angular from close to nothing at the start of it. The main one was a tablet application used by repair technicians in customers’ homes, on connections that could not be relied on.

One of seven to eight developers on the tablet application: a technician arrives at a customer’s house, checks whether the appliance is covered, pulls up the policy details, records what was repaired, photographs the proof, and captures a customer signature that has to be legally valid. All of it has to work with no connection and reconcile later. The offline storage-and-sync layer was designed by our UI architect, not by me — I built against it rather than building it, and I would not claim to know its internals.
A demanding designer, which was the point. The client had their own designer who set a high bar and gave us genuinely difficult designs to build. Working to that standard, a design was a specification, not a suggestion.
Built the frontend for a company-wide document platform — every document the company held, research included, well over 10,000 of them, searchable by metadata and by content inside the files. Filtering ran on the backend; I built the interface over it. I also designed it entirely, with small inputs from the lead, which makes this the earliest thing I owned the look and behaviour of as well as the code.
Took over an ageing device-compliance application (Jamf-based) that checked enrolled company phones — weak passwords included. It already existed and had aged badly, so the work was refactoring it and remediating its dependency vulnerabilities, which I did by hand, package by package. It took a long time and there was no clever way to do it.
Three on-site trips to Munich, three to five days each: development discussions, demos, face-to-face time with the product owner and the client, and working alongside the Munich Re developers. I never watched a technician use the app in the field, but we had the devices and tested on them.
Unit tests on all of it — every application I worked on here had them.

Featured Recommendations

Great job on the project... strong drive and attitude... continue to invest in your skills.

Sorina Radulescu

People Manager

...having in charge a very hard project and client... being in front of the client for direct communication and problem solving.

Raluca Rusu

Project Manager

Assignment 3: Dec 2018 - Feb 2019

Internship — learning Angular and joining the client team

Started with training in Angular, Ionic and the rest of the stack. By the second or third month I was picking up small tickets on the Munich Re tablet application and taking part in the daily calls — so the internship and the role that followed are one continuous piece of work on the same project.

Learned Angular here, from close to zero. No JavaScript at that point, only Vue.js projects from student competitions and some courses. Angular and Ionic both came from this period.
Ended the internship with an offer already signalled: the feedback I had been given said the client was satisfied with the work I had done, and I moved onto a permanent contract on the same engagement.

Tool for processing consumption data

Processing the data that came back from cars under test, at Renault Group’s engineering centre in Bucharest. A stipend contract taken through Drive Your Future, the group internship programme, under a partnership between Politehnica University and Renault Technologie Roumanie. Full time, five days a week, 19 June to 30 September 2017, between the second and third year of the bachelor’s degree.

The objective written into the contract was a tool for processing consumption data. What arrived was everything the cars recorded: speed, altitude, fuel consumption, how many times a door had been opened, anything the vehicle could measure, from cars being tested in different countries.
Eight scripts by the end of it, and other departments started using them to aggregate their own data. The contract asked for one tool.
Presented the extracted and synthesised results to the teams in France, in English. Running the scripts was half of it; the presentations were the other half.
Found why the durations were coming out wrong. The procedure recording how long a road run lasted started at some number of seconds instead of at zero for torque, engine regime and speed, because some of the cars were already doing 30 km/h at time zero. The logs did not begin at rest, and the procedure assumed they did. Reports had been built on those durations already, and saying so meant contradicting the people whose procedure it was.