SOFTWARE DEVELOPER
Lays the structural groundwork that keeps codebases predictable - strict, clean architecture that handles the heavy lifting so others can simply build
Building for the web since 2023 and expanding into mobile architecture. Every technical decision is driven by the end-user's experience — ensuring interfaces are sharp and data is always ready. Behind the scenes, the core focus remains on predictable state and resilient systems. While a primary daily stack drives the main projects, Amel maintains a broad, full-stack foundation with hands-on experience across React, Astro, and Three.js, alongside backend ecosystem tools like Node, Express, and MongoDB. When writing documentation, the philosophy is simple: explain it exactly the way a developer would want it explained to themselves.
01
Developed the Corner Table website and engineered the application's core map experience with dynamic custom pins and robust search functionality. Built the category-driven Discover feed and implemented seamless post sharing both inside and outside the platform. Additionally, took full ownership of the comprehensive management dashboard codebase to refactor legacy logic, resolve core system bugs, and stabilize the platform for production.
Q. 01
A. I refuse to compromise on predictable, immutable state and the strict separation of business logic from the UI. Establishing a clean architecture from day one is non-negotiable. If the application's state isn't completely predictable, the foundation simply isn't solid. I ensure every project starts with this core stability, allowing the system to scale without unpredictable side effects or broken interfaces.
Q. 02
A. I ensure an app feels rock-solid by strictly prioritizing an offline-first user experience. Users shouldn't have to stare at loading spinners just because they have a poor connection. I build with a "cache-then-network" strategy—utilizing local databases to instantly render cached content while remote data silently synchronizes and merges in the background. By implementing predictable, incremental fetching systems, I guarantee that the interface remains instantly responsive and data is always ready, regardless of the network conditions.
Q. 03
A. A good interface works; a great interface feels entirely intentional across every device. Responsivity is the absolute baseline—a layout must seamlessly adapt to any screen size without breaking. However, the detail that elevates it to "great" is strict visual consistency. I believe in rigorously maintaining an established design system throughout an application. By combining fluid adaptability with uncompromising adherence to a unified visual identity across every component, an interface stops just functioning and starts feeling cohesive and professional.
Q. 04
A. I leave a codebase in a better place by prioritizing clarity and pragmatic architecture. I actively avoid over-engineering—favoring targeted, feature-specific implementations rather than cluttering the codebase with unnecessarily complex, "universal" abstractions. I also believe in leaving a clean paper trail, maintaining an accurate and readable commit history so the project's evolution makes sense. Ultimately, my approach is rooted in empathy for the next developer, which extends to my documentation philosophy: I explain things exactly the way I would have wanted them explained to myself.
Q. 05
A. I bridge the gap by actively resisting the urge to over-engineer. When handed a broad request, my first step is to break it down into feature-specific, targeted implementations rather than trying to architect a massive, universal solution from day one. I focus on creating a predictable, incremental rollout plan—delivering core, functional pieces first, which allows stakeholders to see tangible progress immediately. By keeping the scope narrow and the execution agile, I ensure the final product perfectly aligns with the original vision without getting bogged down in unnecessary complexity.
Q. 06
A. For me, it comes down to pragmatism over platform loyalty. Claude often has the edge when it comes to deep context windows and generating nuanced, architectural code—it tends to analyze problems the same way I like to write documentation. ChatGPT, on the other hand, is a versatile powerhouse for rapid debugging, broad problem-solving, and quick prototyping. I don't view it as an "either/or" competition; it is simply about understanding the strengths of each and leveraging whichever tool gets me to a resilient, working solution the fastest.