From Idea to Launch: How I Rebuilt the Frontend for SnapAPI

How it all started

I looked at the mountain of JavaScript I’d written for SnapAPI just to make it behave like a real site instead of a Craftum landing page in disguise. I figured it would honestly be easier to just write my own thing from scratch. I wanted a convenient interface for the screenshot service — one that would look modern and work without a pile of workarounds.

Diving into the new frontend

Let’s go. I picked up Cursor — an AI code editor that’s genuinely great at frontend work. I picked Astro as the framework — a perfect fit for this kind of project thanks to its island architecture. I fed prompts into Cursor.

I spent three days tinkering: tweaking styles, adding animations, going back and forth with Cursor. I crawled through Dribbble looking for inspiration, read a dozen articles on “yet another million JS libraries that killed the previous library-killers.”

That part was genuinely enjoyable. A creative process without a platform’s endless constraints gives you a kind of freedom that template builders just don’t offer.

First results

The site came together. The personal dashboard worked like a charm. All the little frontend bells and whistles slotted in far more easily. Loaders, services, sockets, notifications, animations — the kind of stuff you can only pull off in Craftum inside a design block (or in your worst nightmares).

The API interface for managing screenshots looked modern and responsive — users could easily configure parameters, view their request history, and manage their API keys.

It seemed like everything was going great. Sure, I could keep polishing it, but the overall picture already felt right. Time to launch.

The moment of truth: launch

Launching… 3… 2… 1…

And that’s when my nightmare began. It felt like I’d been through the trenches, come home, drank myself numb for ten years, and then suddenly remembered the horror.

I just wanted to check the style of one element… was that really too much to ask? I opened Dev Tools and it turned out I had mobile view mode switched on…

And that’s when I remembered the thing I hate most about frontend work — wrestling with media queries and every device resolution under the sun. CSS Grid and Flexbox are supposed to make it easier, but once you have to account for dozens of breakpoints, you start wondering “why do I even need this.”

Not that it’s a huge problem. It’s a fix that takes a couple of days, nothing tricky about it. But it’s maddening down to the bone. I absolutely can’t stand it.

Takeaways and conclusions

I don’t even remember anymore why I decided to build my own app — probably out of frustration with constant frontend bugs and “platform limitations.” But I unexpectedly realized that if you don’t demand too much and try to build the site out of “ordinary” blocks, things aren’t so bad after all.

All that’s left is writing some JS scripts, and that’s not exactly rocket science.

Sure, builders like Craftum are missing a lot of things, but you don’t actually need all of that to launch a fast MVP. SnapAPI, as a service for generating screenshots via an API, doesn’t need an overly sophisticated frontend — what matters is that the interface is clear and functional.

Maybe it was my procrastination talking, my reluctance to move forward, but the whole point of “slapping together a frontend on Craftum” was to launch quickly and “test the waters,” not to hand-craft the perfect frontend from scratch.

That’s probably what I should actually be doing, instead of inventing “important” tasks for myself that aren’t really that important. At the end of the day, the best code is the code that already works and delivers value. Responsive design… well, that can always wait.

So for now, let’s shelve the frontend. There are more important things to do.

If you’re curious how I fight procrastination and boost my productivity, check out this post on time management techniques for developers .