I just wanted to present my projects better.
I ended up building an entire tool for that.
Anyone who works with products knows that finishing the application doesn't end the work.
There's still a stage that's usually treated as a detail: showing what was built.
A good interface may seem common in a standalone screenshot. A project with months of decisions can turn into just another rectangle lost on a portfolio page.
The product exists.
But the presentation still doesn't tell its story.
That's where Framecraft was born from.
The problem wasn't creating mockups
Mockup tools already exist.
Some are excellent.
The problem appeared when I tried to fit them into my process.
Watermark on the result. Important resources blocked. Little control over composition. Difficult to justify signatures for a task I didn't perform every day.
I could create an image.
But I couldn't create exactly the presentation I had imagined.
That difference matters.
When you're presenting an authorial project, each choice communicates something: perspective, background, device, proportion, typography, depth, and even the empty space around the interface.
If the tool limits these decisions, the result starts to carry more of its identity than yours.
The first decision was to build for myself
Framecraft didn't start as a SaaS idea.
It started as a tool I wanted to use.
The initial goal was simple: send a screenshot, position it in a composition, and export a ready-to-use image for my portfolio.
Desktop first.
Then tablet and mobile.
Next came perspective controls, scale, rotation, shadow, blur, browser frame, and different canvas proportions.
Each new function emerged from the same question:
does this help me present a real project better?
This filter prevented the editor from becoming just a collection of controls.
Creative tools don't need to offer everything.
They need to make the right decisions easier.
When an editor stops being a screen
At some point, saving only the current state wasn't enough.
I needed to go back to a composition.
Duplicate an idea.
Test another proportion without losing the previous one.
Rename projects. Organize versions. Continue from where I had stopped.
That's when Framecraft stopped being an editing screen and started to behave like a product.
I created a local project library using IndexedDB. Compositions started to be saved automatically in the browser, without requiring an account, database, or initial configuration.
This decision may seem small, but it defines a lot of the experience.
The user enters and creates.
There's no registration interrupting the first contact. There's no remote infrastructure to justify before there's value.
First, the tool proves it's useful.
Then it can ask for more.
Visual control without turning everything into complexity
As I used the editor, another need became evident: the screenshot shouldn't be the only element in the composition.
I added custom texts, native stickers, and uploaded my own adhesives. Next came positioning, rotation, opacity, fonts, weights, alignment, colors, and organization by layers.
Elements can be blocked, hidden, duplicated, and reorganized.
Magnetic guides help find the canvas center.
Shortcuts make the flow closer to a real visual tool.
Even the browser's standard dialogs were replaced.
Not because a alert() would make the application unusable.
But because products lose coherence in the places where we stop deciding.
If the interface has its own language, a confirmation of exclusion is also part of it.
Templates should not erase authorship
Templates can accelerate work.
They can also make everything look the same.
That's why the Framecraft library doesn't deliver closed pieces. It delivers starting points.
Each template combines proportion, device, background, perspective, elements, and visual direction, but preserves the current image and keeps all editable decisions.
The template reduces the time to the first good composition.
It doesn't end the creative process.
This distinction is important for any tool that promises speed: accelerating cannot mean removing control.
Exporting is also a product decision
An image for the portfolio doesn't have the same needs as a square post.
A story doesn't have the same proportion as a horizontal cover.
That's why export has evolved to support resolutions in 1x, 2x, and 3x, as well as fast formats for presentations and social media.
The goal wasn't just to generate a PNG.
It was to reduce the path between finishing the composition and actually publishing it.
The shorter the path, the greater the chance that the work will leave the editor and reach the world.
The stack was a consequence of the product
The Framecraft was built with Next.js, React, TypeScript, Tailwind CSS, and Zustand.
Projects live locally in IndexedDB. Export transforms the canvas into a high-resolution image in the browser itself.
But the most interesting thing wasn't choosing the stack.
It was deciding what didn't need to exist yet.
No authentication in the first version.
No remote database.
No billing.
No architecture designed for millions of users before the first real use.
Technology supported the product stage instead of trying to anticipate all future stages.
This makes the base simple today and still leaves a clear path for cloud synchronization, accounts, plans, and collaboration tomorrow.
Building for oneself doesn't mean building without rigor
Personal projects often receive a perilous permission: to remain improvised.
Since there is no client demanding, some decisions are postponed indefinitely.
In the Framecraft, I tried to follow the opposite direction.
Empty states, save feedback, storage errors, compatibility with previous projects, accessibility of dialogs, migration of new fields, and production build were part of the work.
Not because everything needed to be born perfect.
But because there is a difference between a small first version and a careless first version.
Reduced scope doesn't need to mean reduced quality.
Maybe that will become a micro SaaS
Today, the Framecraft solves my first problem.
And that's already enough to justify its existence.
But the structure points to something bigger.
Cloud projects. Shareable templates. Brand kits. Version history. Batch exports. Plans for creators and teams.
These possibilities exist.
They just don't need to be built before we know which ones really matter.
Turning a personal tool into a product doesn't mean adding billing to everything.
It means discovering if the problem also belongs to other people, and if the solution fits their process.
What remained from this construction
The Framecraft started because I didn't want to continue adapting my work to the limits of other tools.
But building your own solution isn't always the answer.
Most of the time, paying for a ready-made tool is still cheaper than developing and maintaining another.
The point is different.
Sometimes, a Repetida discussão encontra exatamente as habilidades, a curiosidade e o momento certo para se transformar em produto.
When this happens, the nuisance ceases to be just an obstacle.
He turns direction.
I just wanted better images for my portfolio.
During the process, I built a new piece from it.
Share on:
No spam. Only content worth opening.