At Rimo Health, I joined a startup where the frontend had been rapidly built using AI-generated components. While this helped initial speed, it created long-term issues—duplicated logic, inconsistent UI, and slow page performance, with some key pages taking 2–3 seconds to load.
Although I was hired to “clean up the UI,” I took full ownership of the problem at a system level rather than making isolated fixes. I audited the entire frontend across three apps—admin, store, and patient portal—and identified that the root issue was lack of reusable architecture.
I created UI diagrams and used Figma to define consistent patterns, then refactored the codebase using React best practices—separating presentation and logic, consolidating reusable components, and standardizing styling with Tailwind and ShadCN. I also optimized rendering and data fetching.
I did this while continuing to ship features in a fast-paced environment.
As a result, we reduced UI bugs by about 40–50%, improved page performance by 20–30%, and increased development speed by roughly 30–40%. The component system I introduced became the foundation for future development.
At Schneider Electric, I was on-call handling live customer escalations. One case involved a university that had lost about a year of energy data after a firmware upgrade, which they needed for a carbon reduction grant.
The customer was extremely frustrated and under pressure. I couldn’t guarantee a full recovery upfront, so I focused on being transparent while working toward a solution.
I investigated the full pipeline—SQL databases, on-prem systems, and Azure pipelines—and confirmed the data wasn’t reaching ingestion. Working with on-site engineers, I verified the devices were still recording data locally. I traced the issue to a firmware change that broke compatibility with our C-based device drivers.
I updated the driver to match the new schema, tested it in my environment, and deployed it to the customer system.
Throughout the two-week process, I provided consistent updates and avoided overpromising.
In the end, we recovered about 90–95% of the missing data, and the customer was able to submit their grant. More importantly, we restored their trust through transparency and follow-through.
At Schneider Electric, our Salesforce-based documentation was heavily used during on-call support, but it was disorganized and relied too much on keyword searches.
I noticed engineers often had to search multiple times—sometimes 3 to 5 queries—just to find the right article, which slowed down issue resolution.
I proposed restructuring the documentation into a more logical system based on system layers, issue types, and device categories, so engineers could navigate instead of guessing keywords.
I learned how to work within Salesforce Knowledge tools and implemented tagging, categorization, and standardized article formats. I also consolidated duplicate articles and updated high-use entries.
As a result, we reduced article count by about 30–40% and lowered search queries by roughly 25–35%. This improved on-call efficiency and helped keep our API and storage usage within lower thresholds.
At Schneider Electric, I encountered a case where a customer had missing data for a subset of devices after a firmware upgrade.
Instead of assuming a common issue, I systematically analyzed each layer of the system—database, on-prem storage, cloud pipelines, and finally the devices themselves.
I verified that no data existed in SQL or cloud systems, then worked with on-site engineers to inspect the devices directly, where I found the data was still being recorded locally.
This pointed to a transmission issue. I compared firmware changes and identified that updated port mappings had broken compatibility with our device drivers.
I modified the driver to align with the new schema and validated it end-to-end.
This deep investigation allowed us to recover most of the data and prevent similar issues in the future.
At Rimo Health, the frontend had been built quickly using AI-generated components. While this helped initial development speed, it led to duplicated logic, inconsistent UI, and performance issues.
As new features were being added, I realized continuing with this approach would compound the problems.
I pushed back on continuing to build on top of the existing structure and proposed investing time in creating reusable components and standardizing the UI.
I supported this with examples of duplicated code and performance bottlenecks, and outlined how a structured approach would improve both speed and stability long-term.
I then implemented the changes incrementally so we could continue shipping features.
This resulted in significant improvements—40–50% fewer UI bugs and faster development—and the team adopted the new component system going forward.
At Schneider Electric, engineers relied heavily on Salesforce documentation, but it was inefficient to use due to poor organization.
I noticed that engineers often had to run multiple searches to find relevant information, which slowed down debugging.
I reorganized the documentation by introducing structured categories and consolidating duplicate articles. I also standardized how articles were written to make them easier to scan and use.
This reduced the number of queries needed to find information by about 25–35% and improved resolution time during on-call support.