THE ORIGIN

I have been passionate about photography for years, particularly street and documentary photography.

Over time, I developed a strong understanding of what I liked and disliked about existing editing workflows. Professional tools are incredibly powerful, but that power often comes with complexity.

I found myself repeatedly asking:

• Why am I performing the same adjustments manually?
• Why do I need to understand the software's mental model before I can edit an image?
• Why is color harmony treated as something photographers need to manually construct?
• Why can't the software tell me what is happening in the image?
• Why are increasingly sophisticated tools often accompanied by increasingly complicated interfaces?

Eventually, these frustrations became a backlog.

Instead of continuing to wish someone else would build the tool I wanted, I decided to build it myself.

Harmonizer started as a personal project, but I approached it as a real product.

THE PRODUCT VISION

The vision was simple:

Build a photo editor that helps photographers understand and shape the relationships between colors in their images.

This meant Harmonizer could not simply become another Lightroom or Capture One clone.

The product needed its own point of view.

I wanted the experience to be:

Intelligent without being intrusive.

Powerful without being overwhelming.

Visual without becoming decorative.

Fast without sacrificing control.

This principle influenced everything from the interface architecture to the underlying image-processing approach.

MY ROLE

Product Builder

This project required me to operate across the entire product lifecycle.

I was responsible for:

• Product vision
• Problem definition
• Product strategy
• Feature discovery
• Prioritization
• UX architecture
• Interaction design
• Visual design
• Technical architecture
• Front-end development
• Image-processing logic
• Prototyping
• Testing
• Debugging
• Performance optimization
• AI-assisted engineering
• Product iteration

There was no separate product team, designer, engineering team, or technical lead.

I was the entire product team.

That made the project particularly valuable because every product decision had a direct implementation consequence.

THE PRODUCT PROBLEM

Existing professional photo editors are optimized for breadth.

They offer enormous collections of controls for exposure, curves, HSL, masking, sharpening, noise reduction, color grading, and countless other operations.

That is valuable for professionals who need complete control.

But it creates another problem:

The photographer increasingly becomes responsible for understanding the tool rather than simply making the image better.

I wanted to investigate whether a more opinionated product could reduce that cognitive burden.

Instead of beginning with:

"Which parameter should I change?"

Harmonizer begins with:

"What is happening with the color in this image, and what could make the relationship between those colors stronger?"

PRODUCT HYPOTHESIS

The initial hypothesis was:

If the software can understand the dominant color relationships within an image and communicate them visually, photographers can make more intentional color decisions with less manual experimentation.

This led to the first major product concept:

HARMONY ANALYSIS

The system analyzes the image and identifies dominant color relationships.

Rather than simply presenting RGB or HSL values, Harmonizer attempts to describe the image through relationships such as:

• Complementary
• Analogous
• Triadic
• Split-complementary
• Monochromatic

The interface then exposes these relationships as a visual system rather than a spreadsheet of numerical values.

FROM IDEA TO PRODUCT

I deliberately did not start by building the entire application.

I started by reducing the concept to its smallest meaningful interaction.

V0

Upload image → Analyze colors → Display harmony

This prototype answered the most important question:

Is the underlying concept useful enough to deserve a product?

Once that interaction proved compelling, I expanded the product around it.

This helped prevent a common product-builder failure mode:

building infrastructure before validating the experience.

PRODUCT ARCHITECTURE

As the product evolved, I separated the system into distinct layers.

PRESENTATION

The interface, interactions, panels, keyboard shortcuts, previews, and editing controls.

APPLICATION STATE

Document state, edit history, active tools, selections, masks, and non-destructive adjustments.

IMAGE PROCESSING

Color extraction, transformations, image analysis, masking, blending, and rendering.

PRODUCT INTELLIGENCE

Harmony detection, dominant color analysis, contextual suggestions, and future recommendation systems.

This separation became increasingly important as the application grew.

A photo editor can become a monolith very quickly if UI state, image manipulation, business logic, and rendering are allowed to become tightly coupled.

THE TECHNICAL CHALLENGE

I came into the project with strong product, UX, and design experience, but I was not an experienced software engineer across every part of the stack required to build a professional photo editor.

That was intentional.

Rather than treating this as a blocker, I treated it as a product constraint to solve.

I used AI-assisted development to close specific technical gaps while retaining ownership of the architecture and product decisions.

The distinction was important:

I did not ask AI to build Harmonizer.

I used AI to help me build parts of Harmonizer that I did not yet know how to implement efficiently.

AI-ASSISTED ENGINEERING

AI became particularly valuable when moving from product concepts into unfamiliar technical territory.

I used AI as:

• A coding partner
• A technical explainer
• A debugging assistant
• An architecture reviewer
• A rapid prototyping tool
• A documentation assistant
• A source of implementation alternatives

For example, when I encountered an unfamiliar image-processing problem, I could first define the desired behavior at the product level and then use AI to explore potential implementation strategies.

I would then evaluate those approaches based on:

Performance → Complexity → Maintainability → User experience → Future scalability

This allowed me to move from:

"I don't know how to implement this."

to:

"I understand the implementation options well enough to make an informed architectural decision."

That distinction became one of the most valuable lessons of the project.

AI CODING WORKFLOW

I developed a deliberate workflow for using AI rather than blindly accepting generated code.

01. DEFINE

I first defined the desired behavior and constraints independently.

02. DECOMPOSE

I broke the problem into smaller technical units.

03. EXPLORE

I used AI to investigate implementation approaches and trade-offs.

04. IMPLEMENT

I integrated the selected approach into the codebase.

05. TEST

I tested the implementation against real product requirements.

06. REVIEW

I used AI to help identify potential bugs, edge cases, performance issues, and architectural weaknesses.

07. REFACTOR

Once the behavior was validated, I simplified and reorganized the implementation where necessary.

This prevented AI-generated code from becoming an uncontrolled dependency inside the product.

ONE OF MY BIGGEST EARLY MISTAKES

My first instinct was to build too much.

Because I had years of experience with photo editing software, I had a huge backlog of features I wanted:

• RAW processing
• Layers
• Masks
• Adjustment tools
• Color grading
• Presets
• History
• Export
• Keyboard shortcuts
• Advanced selection
• Metadata
• Non-destructive editing
• AI-assisted adjustments

The backlog was exciting.

It was also dangerous.

I realized that I was building the product I imagined after years of frustration rather than validating the smallest product users could actually benefit from.

THE LESSON

A backlog is not a product strategy.

I began aggressively separating:

Must prove → Should explore → Nice to have → Later

The product became significantly clearer once I stopped treating every feature as equally important.

MY SECOND MISTAKE: OVER-ENGINEERING TOO EARLY

Another mistake was trying to design the architecture around the theoretical future of the application.

I was building abstractions for functionality that did not yet exist.

This created unnecessary complexity and slowed iteration.

The lesson was straightforward:

Architecture should enable the next stage of the product, not solve every hypothetical future problem.

I subsequently moved toward a more modular architecture, extracting systems only when there was a demonstrated need for them.

This allowed me to preserve technical flexibility without sacrificing development velocity.

MY THIRD MISTAKE: CONFUSING TECHNICAL POSSIBILITY WITH PRODUCT VALUE

AI made it remarkably easy to implement things I previously would have considered technically expensive.

That created a new product risk.

Just because something can be built quickly does not mean it deserves to exist.

I had to become even more disciplined about asking:

Does this improve the user's outcome?

Does this make the editing process meaningfully better?

Is this solving a problem or demonstrating technology?

This became particularly important when experimenting with AI-powered features.

The technology was exciting.

The product still needed to earn its place.

DESIGNING THE INTERFACE

I deliberately avoided recreating the visual language of existing professional photo editors.

I did not want Harmonizer to feel like another Lightroom, Capture One, or Darkroom.

The central image remains the primary object.

Controls are organized around it rather than dominating the workspace.

The interface uses a restrained, spatial approach where panels can appear around the image and adapt visually to the context of the photograph.

One of the core concepts is the Harmony Panel.

It presents:

• Dominant colors
• Detected harmony
• Harmony score
• Color relationships
• Relevant adjustment opportunities

The objective is to turn an abstract color theory concept into something immediately understandable.

THE HARMONY ENGINE

The product's central technical concept is the ability to analyze the color composition of an image.

The system extracts representative colors and evaluates their relationships within a color space.

Rather than treating colors independently, Harmonizer evaluates the relationship between colors.

This creates the foundation for future capabilities such as:

• Harmony-aware adjustments
• Intelligent palette suggestions
• Color replacement
• Context-aware grading
• Style exploration
• Automated recommendations

The product therefore has a potential intelligence layer that sits above conventional editing controls.

NON-DESTRUCTIVE EDITING

One of the most important architectural decisions was to preserve the original image while allowing edits to be modified, reordered, or removed.

Instead of treating an edit as a permanent pixel transformation, the product maintains a representation of the user's editing state.

Conceptually:

Original → Operations → Rendered Output

rather than:

Original → Modified Pixels → Modified Pixels → Modified Pixels

This makes the system much more flexible and creates the foundation for:

• Undo / redo
• Editing history
• Adjustment layers
• Parameter changes
• Reordering operations
• Reversible experimentation

This is an example of how product requirements directly influenced technical architecture.

PERFORMANCE AS A PRODUCT FEATURE

Photo editing is computationally expensive.

Every interaction that causes an image to re-render has the potential to introduce latency.

I therefore treated performance as part of the user experience rather than purely an engineering concern.

I focused on:

• Minimizing unnecessary re-renders
• Separating preview and final-resolution processing
• Reducing expensive operations during interaction
• Managing application state carefully
• Avoiding unnecessary image copies
• Keeping UI updates independent from heavy processing where possible

The goal was not simply to make the software technically efficient.

It was to preserve the feeling of direct manipulation.

When a photographer moves a control, the product needs to feel like it responds immediately.

BUILDING WITH AI WITHOUT LOSING OWNERSHIP

One of the most interesting aspects of Harmonizer was learning where AI dramatically increased my capabilities and where it introduced risk.

AI was extremely effective for:

Exploration
Quickly investigating unfamiliar technical approaches.

Boilerplate
Generating repetitive implementation patterns.

Debugging
Helping identify likely causes of errors.

Documentation
Explaining unfamiliar APIs and libraries.

Refactoring
Identifying opportunities to simplify existing code.

Technical research
Comparing alternative implementation strategies.

But I learned not to delegate:

Product decisions

Architecture ownership

UX decisions

Prioritization

Quality standards

Trade-offs

The most productive relationship became:

I decide what the product needs. AI helps me explore how to build it.

ITERATION LOOP

I adopted a very tight product-builder loop:

IDEA

↓

HYPOTHESIS

↓

PROTOTYPE

↓

IMPLEMENT

↓

USE

↓

IDENTIFY FRICTION

↓

REFACTOR

↓

REPEAT

Because I was also the target user, I could immediately put the product through real editing workflows.

This created an unusually short feedback cycle.

Instead of waiting for a formal product review, I could discover a problem while editing an actual photograph and immediately investigate why it happened.

‍