I shipped a Mac app without opening Xcode.

We write everything in Markdown. Notes, specs, reports, this post. And for years, every path from Markdown to a PDF you'd actually hand to someone has been mildly embarrassing — print dialogs, LaTeX toolchains, headless browsers held together with tape.

I'd been meaning to fix this for myself for a long time: a small native Mac app. Markdown in, beautifully paginated PDF out, styled with plain CSS. A well-bounded problem I understood completely — which made it the perfect subject for an experiment I'd been wanting to run.

The rule

One rule: I don't touch it. Not the code, not the project, not once.

I spent a little while in Claude's design tool describing what the app should feel like, picked a direction I liked — a three-pane window: source, live paginated preview, conversion inspector — and handed the design to Claude Code untouched. Then I let it work.

I never opened Xcode. I still haven't. I genuinely could not tell you which parts are SwiftUI and which are AppKit, or what tools it reached for along the way. I know it from the outside, the way a user knows it.

What came back

Six days from empty scaffold to a notarized DMG and an App Store package. Seventy-two commits. Around six thousand lines of Swift, with 183 tests it wrote for itself — including a self-test harness that exports a real PDF and checks the page numbers, outline, and clickable links land where the preview said they would.

My own time, counted honestly, came to about a working day — spread thin across six days of evenings. Almost none of it was hands-on. It went on decisions and feedback: which design direction, how page numbering should behave, that copy sounds off, this bullet list is indented too far. The kind of feedback you'd give a colleague, not instructions you'd give a compiler. Time spent writing or debugging code: zero. A day of judgment bought a week of engineering.

The part that genuinely surprised me is that the app contains ideas I would not have come up with. Front-matter fields like version: or status: become tokens you can drop into headers and footers. Fenced ::: divs give stylesheets semantic hooks I didn't know I wanted. Nobody specified any of that. It read the problem and went further than the brief.

The dinner test

The website made the point sharper. I told it the features page should show the real product with real screenshots, and went for dinner. When I came back, it had rebuilt the app, written demo documents to show it off, driven the app through the accessibility APIs to capture retina screenshots of itself, assembled the page, and deployed it. It also wrote the App Store listing and produced the store screenshots at Apple's exact required sizes.

The only marketing instruction I ever gave was, at the end, "make it more marketing."

What I think this proves — and what it doesn't

It's the first finished macOS app I didn't participate in, and I think it's the best one I've shipped. Both halves of that sentence matter.

First: the spec is the work now. The highest-leverage time was all up front, deciding what the thing should be and how it should feel. If the first spec is good, you do a design and then let it code. Judgment doesn't disappear — it moves up the stack, from the keyboard to the brief.

Second: the boundary conditions matter. This worked because the problem was small, greenfield, and completely specified by someone who knew exactly what they wanted. That is not the situation inside a bank's document pipeline or a regulated data platform, where the spec is distributed across systems, policies, and people — and where an agent's enthusiasm needs governance, evidence, and audit trails around it. That gap, between what an agent can do unsupervised on a clean problem and what it must be constrained to do on a consequential one, is exactly the layer we spend our days building at Vela.

But on a clean problem? It's not close anymore. The app is real, it's fast, it's careful about typography, and it's free to try.

See what it built →