How I Built and Shipped an App in a Weekend

By Lz on 2026-07-12 · 3 min read

How I Built and Shipped an App in a Weekend Thumbnail

About a week ago, on a Thursday night, I went to share a screenshot. I'd just shipped a small Budgitify update I was happy with, and I went to post it to Instagram and Threads like I always do, and it just looked bad, a raw shot sitting on a plain white square with nothing framing it or giving it any depth, the kind of thing you'd scroll right past.

I know there are tools for this and I've used a few of them over the years, but they're mostly on the web, or they want a subscription, or they do way too much when I only wanted the one thing. All I wanted was to grab a screenshot on my phone, make it look decent, and post it, without opening my laptop or signing up for anything.

So instead of posting something ugly I closed the app and started sketching out a different one, and by that Sunday it was submitted to the App Store. It's called Framewich, and after a week in review it's finally live. Here's how the weekend actually went.

1. The idea was small on purpose

The most useful thing I did all weekend was decide what the app wouldn't do before I wrote any of it.

Framewich does one thing. You take a screenshot anywhere on your phone, whether it's an app you're building or something you just want to mock up, you share it into Framewich from the iOS share sheet, and you make it look good. That's the whole loop. There's a fair bit of control inside it, but all of it is there to serve that one job:

  • Drop the shot into a device frame, then set the frame color and its shadow
  • Pick the background, solid or a gradient
  • Change the canvas size for wherever it's headed
  • Add text above or below the bezel, with the font, size, and color you want
  • Save your frames into folders so a project or a run of versions stays together
  • Export and share

When the idea hit that Thursday I wrote the list down, and then I spent more time deciding what to leave off than what to put on. Every feature I talked myself out of that night was one I didn't have to build over the next two days, and that's the only reason a weekend was enough.

2. How AI actually helped

I get asked about this constantly, so I'll be honest about where AI actually fits, because it's a bigger part of how I work now than people tend to assume. It didn't do the thinking for me, but it wrote a lot of the code.

Where it mattered most was before I'd written a single line. That Thursday night I talked the whole architecture through with it, how the share extension hands the image over to the main app, how the editor state should be structured, where the frame and background and text layers each live, and how export needs to work so what you see on screen is exactly what comes out. I'd float a structure, it'd push back or point out the thing I was going to regret two days later, and I'd adjust. So by the time I opened Xcode on Friday I already had a plan I trusted and could just start building, instead of spending the first day working out the shape of it.

From there a good chunk of the actual code came out of AI while I drove. I'd describe the piece I wanted, it'd write a first pass, and I'd read through it, catch what wasn't right, and make the tweaks. Some of it was boilerplate, the kind of thing that's more or less the same in every app, but plenty of it was real feature code. Either way the loop was the same. It'd write a version, I'd go through it and adjust, and I'd decide what actually stayed.

What didn't change is that I'm still the one making the calls. Which frame looks right, how an export should feel, what to cut, that's still on me and not something a prompt hands me. The way I think about it, AI let me move at the speed of reviewing code instead of writing every line from scratch, and on a build this short that time is most of why it got finished at all.

3. Two days of building

Friday and Saturday were the actual build. It's all SwiftUI and fully native, which is what keeps it fast and makes it feel like it belongs on the phone.

The share extension was the first thing I built, because if that part isn't effortless then none of the rest matters. After that I built the editor, which is a live canvas. When you change the frame, the color, the background, or the text, it updates on the spot as you go, so there's no separate step to check what the export will look like.

Most of the time went into small stuff that only looks easy: getting gradients to render smoothly, getting shadows to look like real depth, and getting text to land in the right spot above or below the bezel across different canvas sizes. Export was the one that really ate the weekend, because getting the output sharp and at the right resolution for wherever it's headed is fiddlier than it sounds, and it took longer than anything else. It's also the kind of thing nobody notices unless it's wrong.

By Saturday night I was testing it on my own screenshots, running the exact thing I'd wished for on Thursday, and it worked. That was the moment the weekend paid off.

4. Shipping it

That Sunday I submitted it for review. It's free, it's native, and there's no sign-up. After about a week of waiting it's now live, and you can grab Framewich on the App Store.

I could've spent another week polishing before I sent it in, there's always more to do, but it was already doing its job, and something that's actually out in the world getting used teaches me more than a slightly better version sitting on my machine. I'd rather learn from people framing their own screenshots than keep guessing on my own.

There's something fitting about the whole thing existing because I couldn't share a Budgitify screenshot nicely, and the next update I post is going to be framed in Framewich.

What I'd tell someone building a weekend app

Keep the scope way smaller than feels comfortable. Two days go by fast, so pick the one thing the app has to do and keep saying no to everything else. Most of the work here was deciding what to leave out on the first night.

And lean on AI without pretending it does the work for you. Let it write the code, but read all of it, keep making the calls yourself, and put the time it saves you into the parts that actually need you. Then send the thing before it feels ready. Framewich went from an annoyance on a Thursday night to something real on the App Store, and it's better for being out here than it would've been sitting on my machine while I kept polishing.