A product leaderProduct LeaderDefines product vision, aligns teams and stakeholders, and turns business goals into products that create measurable user and business value. / product builderProduct BuilderTurns ideas into real, usable products by combining strategy, UX, technology, experimentation, and execution from concept to launch. using AI-native thinking to turn complex customer problems into clear, scalable digital products.
00:00:00
Warsaw
Harmonizer
Client
Personal product experiment
Scope
Vision, UX, architecture, code, AI-assisted engineering
Year
2026, ongoing
Role
Product Builder
In short
Harmonizer is a personal photo editing tool built from the ground up to rethink how photographers work with color. After years of professional editors that make you think about the software instead of the image, I wanted to test one question: what if the software understood the relationships between the colors in an image and helped you make better decisions, instead of handing you more controls? Harmonizer is my attempt to answer it, combining product management, photography and a decision to build the software myself.
There was no product team, designer, engineering team or technical lead. I was the whole product team, which meant switching between six ways of thinking, sometimes within a single afternoon. Try each one on.
Try it yourself
Harmonizer begins with one interaction: upload an image, analyse its colors, show the harmony. This is a small, illustrative version of that first product concept. It runs entirely in your browser; nothing is uploaded anywhere. Try one of the sample scenes, or drop in a photograph of your own.
—
Illustrative only. The real engine works in a proper color space with far more nuance than a hue wheel.
The product problem
Existing professional editors are optimised for breadth: enormous collections of controls for exposure, curves, HSL, masking, sharpening, noise, grading and more. That is valuable if you need complete control. It also means the photographer becomes responsible for understanding the tool rather than making the image better. I wanted to test whether a more opinionated product could reduce that burden. Compare where each one starts.
From idea to product
That hypothesis led to the first product concept, harmony analysis: describe the image through relationships (complementary, analogous, triadic, split-complementary, monochromatic) and expose them as a visual system rather than a spreadsheet of values. I deliberately did not start by building the whole application. I reduced the concept to its smallest meaningful interaction.
That prototype answered the only question that mattered at the time: is the concept useful enough to deserve a product? Once the interaction proved compelling, the product grew around it, which avoided the classic builder failure of laying infrastructure before validating the experience. As it grew, I separated it into four layers. Tap one.
The separation mattered more every month. A photo editor becomes a monolith very quickly if UI state, image manipulation, business logic and rendering are allowed to couple.
Building with AI
I came in with strong product, UX and design experience, and without being an experienced engineer across every part of the stack a professional photo editor needs. That was intentional. I treated the gap as a product constraint to solve, using AI-assisted development to close specific technical holes while keeping ownership of the architecture and every product decision.
A deliberate loop, so generated code never became an uncontrolled dependency inside the product.
Three mistakes
Three mistakes, each with a lesson I still use. Tap them.
A few of the original wishes. Sort them the way the project eventually did, then compare.
Non-destructive editing
One of the most important architectural decisions: keep the original image untouched and treat edits as a list of operations you can change, reorder or remove. Original, then operations, then rendered output, instead of pixels overwriting pixels overwriting pixels. Toggle and reorder the operations below and watch the render follow.
This is what makes undo and redo, editing history, adjustment layers, parameter changes, reordering and reversible experimentation possible. A product requirement that directly shaped the technical architecture.
Design and engineering
Three decisions that shaped the product as much as any feature. Pick one.
The iteration loop
Because I was also the target user, the product went through real editing workflows the moment something was built. Instead of waiting for a formal review, I could hit a problem while editing an actual photograph and investigate it immediately. The loop got very tight.
What I learned
Six things Harmonizer taught me about product building. Open them.
Why I built it
Harmonizer started because I wanted a better photo editor. It became something more useful: an experiment in what happens when a Product Manager can also build. I could take an idea the whole way without waiting for a separate team to translate it into reality.
AI did not make me a software engineer overnight. It let me move through unfamiliar technical territory faster, while forcing me to be more rigorous about architecture, quality and product decisions. That is the real value I took from the project.
Harmonizer is an ongoing personal product project. The current build is the foundation of a larger vision rather than a finished endpoint. The long-term direction is to make intelligent color analysis a deeper layer in the editing workflow, helping photographers understand, experiment with and intentionally shape the visual relationships in their images. It keeps evolving through experimentation, real-world use and technical iteration.
Toolkit
© 2026, Alan Abramek. All Rights Reserved.
