Business systems
I built web applications and internal platforms with user management, workflows, real-time communication, and operational processes.
Who builds PROVEN
I build PROVEN independently, drawing on experience with software used for real work.
I’m Adrian Popescu, a full-stack JavaScript developer from Romania. I have 14 years of experience across web applications, business systems, and operational automation.
Applied experience
I built my experience in systems that had to work, not just look finished.
Before PROVEN, I worked across frontend, backend, services, databases, security, performance, and operational tooling. Much of the software I worked on was built for internal use, where reliability and maintainability mattered more than public presentation.
Full-stack architecture
I work across interfaces, APIs, Node.js services, and databases, integrating them into products that need to remain maintainable over time.
Automation and tooling
I built internal tools, scripts, and automation for repetitive processes, testing, debugging, and operations.
From internal systems to public products
Public products make my experience directly assessable.
Much of my experience comes from products built for internal use. With ZENIA and PROVEN, that experience can be assessed directly through public products, their documentation, and how they work.
- 01
My product experience
Years of work on business applications shaped my engineering discipline around architecture, performance, security, and operations.
- 02
ZENIA
I built ZENIA as a public product so its service integration, workflows, and product experience can be assessed directly.
- 03
PROVEN
With PROVEN, I continue that direction in a Shopify product focused on catalog quality, controlled fixes, verification, and traceability.
How I apply that experience in PROVEN
I want the product to be able to explain what it does and where it stops.
PROVEN’s public principles are not separate from implementation. They describe how I design and verify the product.
Evidence before conclusions
I want each problem to show what was observed and why it was flagged, rather than presenting an unexplained verdict.
Control before change
I keep proposal, approval, and publication as separate stages. A suggestion does not automatically become a Shopify change.
Verification after publication
For supported changes, I check the result again in Shopify before I consider the process complete.
Documented boundaries
When a change, restore, or interpretation cannot be performed safely, I keep that limitation visible.
Assess the product
I explain who builds PROVEN. The product shows how I work.
In the documentation, I explain the product’s functions and limits, while in the changelog I publish relevant changes as PROVEN evolves.