When I started building a browser-based photo collage maker, I assumed the hard part would be the canvas work.
It wasn’t.
The harder problem was designing a workflow that actually matched how people think when they make collages.
A lot of existing tools fall into one of two extremes. They either feel too generic, like a blank editor that expects you to do everything yourself, or they feel too template-heavy, where you spend more time fighting presets than actually arranging your photos. I wanted something in between: simple enough to start fast, structured enough to feel useful, and flexible enough to fit real output needs.
So for the first version, I made one decision that shaped the whole product:
I would build around layouts first, not templates.
Starting with the smallest useful version
It was tempting to build everything at once: layouts, templates, themed pages, use cases, marketing flows, and dozens of starting points.
But I’ve learned that “everything at once” usually creates a blurry product.
So I asked a simpler question: what is the fastest path to helping someone make a decent photo collage in the browser?
The answer was not “give them more choices.” It was “help them start with structure.”
That led to a layouts-first approach. Instead of opening a blank canvas and figuring everything out manually, users can begin with a collage structure that already makes sense for 2 photos, 4 photos, 9 photos, and so on.
That sounds small, but it changed the product a lot. It made the editor feel less abstract and more task-oriented from the start.
Why layouts came before templates
One thing became clear pretty quickly: layouts and templates are not the same thing.
A layout is structure. It defines how many photos fit, where emphasis goes, how the canvas is divided, and what kind of rhythm the collage has.
A template is something else. It is a styled starting point. It can include backgrounds, decorations, theme choices, text placement, seasonal visuals, and all the extra presentation details that turn a structure into a finished design.
I didn’t want to fake a template system before it was ready. So instead of calling everything a template, I kept the first version honest. The product currently solves the structure problem well. Templates will come later, once the editing workflow feels solid enough to support them properly.
That separation helped me keep the product model cleaner too. Instead of mixing every concept together, I could treat layouts as the foundation and let future template work build on top of that.
The ratio and export size problem
Another issue showed up once I started testing real editing flows.
At first, ratio and export size were tied together too tightly. In practice, that meant a preset was doing too many jobs at once: it was describing the shape of the canvas and the final pixel output.
That sounds convenient at first, but it becomes awkward very quickly.
A square Instagram post and a square export image are related, but they are not the same thing. The same collage structure might need different pixel sizes depending on whether someone wants a quick social post, a sharper upload, or a print-friendly export.
So I split those ideas apart.
Instead of treating one preset as the source of truth for everything, I separated the model into:
- canvas format
- surface preset
- export profile
That gave the editor a much clearer internal logic.
The format describes the shape.
The surface helps narrow down common ratio choices.
The export profile controls the actual output size.
This sounds like a technical refactor, but the real benefit was product clarity. Once those concerns were separated, the interface started making more sense too.
Browsing by photo count felt more natural
Another lesson was that naming layouts is less important than organizing them in a way people instantly understand.
When someone wants to make a collage, they usually don’t think, “I want a hero-stack layout with asymmetric emphasis.”
They think, “I have 4 photos,” or “I need a 2-photo vertical collage,” or “I want something for 9 images.”
That changed how I organized the layout browser.
Instead of treating layout names as the main entry point, I grouped layouts by photo count. That makes browsing feel much closer to the actual task. Users can still care about style later, but the first decision is often just how many photos they want to use.
It’s a small UX shift, but it removes a lot of friction.
Keeping the product focused
One of the most useful parts of building this project was deciding what not to do yet.
I removed ideas that were creating more confusion than value. I dropped unfinished use-case flows. I hid template entry points that weren’t ready. I simplified public routes. I tried to make the product say one clear thing instead of five half-finished things.
That doesn’t mean those ideas were bad. It just means they weren’t right for the current stage of the product.
I’d rather have a focused collage maker with a strong layouts workflow than a bigger product full of placeholders.
Building it in the browser
From a technical point of view, I wanted the editor to feel lightweight and immediate.
The browser is already good enough to handle a lot of this work if the data model is clean and the workflow is predictable. Users can upload photos, position them, adjust the collage, and export without going through a heavy desktop-style setup.
That was important to me. I wanted the product to feel accessible, not over-engineered.
I also ended up deploying it on Cloudflare Workers, which introduced its own set of practical issues. That part was a reminder that product development is rarely just about features. Sometimes the real work is getting the boring infrastructure details out of the way so the actual experience stays fast and reliable.
What’s next
The current version is intentionally layouts-first.
That is not the final vision. Templates are still part of the roadmap, but I want them to arrive as a real feature, not as a vague promise. When they do show up, they should feel clearly different from layouts and genuinely useful as styled starting points.
For now, I’m happy with the scope of the first version. It solves a real problem more clearly than the earlier versions did, and it gives me a much stronger foundation for everything that comes next.
Building this product has been a good reminder that the best early features are often not the flashiest ones. Sometimes the biggest improvement comes from making the model simpler, the workflow clearer, and the starting point more honest.
Top comments (0)