Photopea: start by opening one file well

An imperfect release note

Photopea's official blog introduced version 0.1 in September 2013. Its listed features included basic PSD parsing and rendering, zoom, movement, and history controls. The author also described unresolved rendering and performance problems. The current product site presents a browser editor with layers and PSD support. Read together, these pages make the distance between a first release and a broader product visible.

This article uses public material. It makes no claim about the present team size, revenue, or profit. The following lessons are Shilu's editorial observations.

Replace a broad ambition with an observable result

“Build an image editor” is too broad to tell a small team whether today's work helped. “Open this file and preserve the important content” has an input and an output that can be compared. A useful experiment asks what changed for the person doing the work and whether they still need another application to repair the result.

A first version can therefore be valuable even with few features if it establishes a repeatable example. Our suggestion is to collect a small set of real materials: one simple case, a common case, and an awkward case. Repeat the same workflow after each change. Record both improvements and regressions. Those notes can also help explain what the tool currently supports.

Explain limits in a useful way

If a file type is unsupported, say so near the input. If large files may take time, help the person understand what is happening. Clear boundaries make feedback easier to interpret and prevent users from spending time on a task the product cannot finish.

This is not an argument for celebrating rough edges. A useful limitation notice gives the user a next action: save a copy, try a compatible format, or choose another tool. It should help someone complete their work rather than merely explain the developer's difficulties.

Try a small exercise

Choose one file-handling task you regularly encounter. Define a successful result and three ways it could fail. Make the shortest workflow that addresses those cases, then ask someone else to try it without guidance. Note where they hesitate before deciding what to add.

If the problem is still hard to describe, spend more time watching the existing process. A finished interface can make its beginnings disappear from view. The transferable idea is not to reproduce a mature application at once, but to make progress observable and give the next revision a specific job.