Apr 10, 2026

Testing whether GPT-5.4 could turn pdfcrop into a Windows app

A experiment in using GPT-5.4-high, a terminal, and almost no developer implementation work to turn an existing open source web app into a more accessible Windows desktop experience.

windows tauri rust webassembly accessibility

This post is about packaging, adaptation, and accessibility, not authorship.

Before anything else, the real credit belongs upstream.

For the purposes of this experiment, the specific person I want to credit is Teddy van Jerry, whose work is reflected in the upstream pdfcrop / pdfcrop.github.io project lineage that this packaging effort was built around.

I also want to mention my friend Miles Wolbe of tinyapps.org. He was the person who originally brought the accessibility angle of this problem to my attention and got me thinking seriously about what it would mean to make a tool like this easier for ordinary Windows users to approach.

To be clear, that was not how the project started in my head. My initial interest was much more technical and frankly much narrower: I wanted to see what would happen if I threw one of these newer AI tools at a real packaging problem and let it work through the scope on its own. The question was less “can this help people” and more “how much real, bounded engineering work can this now take on?”

But as the experiment went on, the accessibility angle became much more interesting to me. That is partly because of conversations with Miles, and partly because I think there are similar opportunities coming for tools in the 3D printing world and other developer-adjacent niches that still have rough edges for ordinary users.

That shift in emphasis matters. The project began as a capability test, but it became more compelling because it hinted at something larger: these tools are starting to make adaptation work feasible in places where it previously would not have happened at all.

The core crop engine, the web app, and the project architecture were already there. My repository is just a frozen experiment snapshot built around that work to answer a specific question:

Could GPT-5.4-high, given a terminal, an empty repository, and a very clear target, convert a developer-first web experience into a more native and approachable Windows desktop app without direct developer implementation work?

The repository for this experiment is here:

  • https://github.com/citricguy/pdfcrop.github.io-tauri

The upstream projects are here:

  • https://github.com/pdfcrop/pdfcrop
  • https://github.com/pdfcrop/pdfcrop.github.io

Goal

The goal was not to prove that AI can magically replace engineering.

The goal was much more specific, and honestly much more interesting:

  1. Give GPT-5.4 a terminal through Codex or Copilot CLI, an empty repo, and some target repositories.
  2. See whether it could iterate its way to a working prototype with as little developer oversight as possible.
  3. Do it from a fresh Windows VM with no tooling installed.
  4. Keep the process disciplined enough that every command was reviewed before it ran.
  5. End up with something more accessible and less intimidating for ordinary Windows users than a browser-first, developer-oriented workflow.

Starting point

The original project was already strong.

The upstream web app is a WebAssembly-powered PDF cropping tool that runs fully in the browser. It is private by design, processes files locally, and uses a stack that is already very well suited for portability:

  • TypeScript
  • Tailwind CSS
  • PDF.js
  • the Rust pdfcrop library compiled to WASM
  • Vite

That matters, because the least risky path was not to rewrite the crop engine or rebuild the UI from scratch. The least risky path was to preserve what already worked and wrap it in a better Windows-native shell.

So that is what this experiment aimed to do.

Constraints

This was not a blank check “make something cool” prompt.

The setup was intentionally strict:

  • Start in an empty working directory.
  • Assume nothing is installed.
  • Verify tooling.
  • Stay Windows-native first.
  • Prefer Tauri.
  • Avoid broad rewrites.
  • Explain every command before proposing it.
  • Wait for approval before running anything.
  • Keep a running engineering report.
  • Do not stop at the first blocker.

That structure turned out to matter a lot.

Without a tightly scoped mission and some discipline around verification, it would have been very easy for the model to wander, over-engineer, or chase the wrong version of the project layout.

What changed

The end result stayed deliberately conservative.

Instead of replacing the crop engine, the experiment preserved the original Rust/WASM crop path and added only the minimum desktop layer needed to make the experience feel more native on Windows.

In practical terms, that meant:

  • keeping the upstream source tree intact inside the experiment snapshot
  • adding a Tauri 2 desktop shell
  • adding native desktop open and save behavior
  • fixing desktop drag and drop behavior on Windows
  • adding a smaller size-focused standalone EXE build profile

That was the right call.

A lot of “AI did it” demos quietly hide rewrites that change the problem. This one was more interesting precisely because it avoided that. The model did not get to win by throwing away the original architecture. It had to work with the project that already existed.

Why accessibility was part of the point

When I say “accessible” here, I do not just mean standards compliance in the formal sense.

I also mean accessible in the everyday, practical sense:

  • fewer browser-like workflows
  • more familiar open/save interactions
  • less need to understand a dev stack
  • easier distribution
  • a more obvious entry point for ordinary Windows users
  • an interface that can be made friendlier for people with motor or visual constraints

That kind of adaptation work is valuable, but it is also exactly the kind of work that often never gets prioritized for smaller open source projects.

Not because it is unimportant, but because it is hard to justify spending real developer time on it unless the audience is already large.

That is why this felt like such a meaningful test.

What went wrong

This was not “press button, receive app.”

A few realities became obvious quickly:

1. The prompt quality mattered a lot

A vague prompt would not have gotten this done. The model needed very explicit decision rules, workflow rules, validation requirements, failure handling, and success criteria.

2. Environment setup was part of the real task

Fresh Windows setup is never just one thing. Toolchain verification, Rust targets, wasm-pack, Tauri, Visual Studio build requirements, and WebView2 all matter. The prompt needed to treat environment setup as real engineering work, not a footnote.

In practice, the model spent about 2.5 hours chugging away on this project, and most of that time was not glamorous implementation work. A large chunk of it was consumed by getting the Windows VM into a usable build state and waiting for the environment to be properly set up.

3. Repo structure mattered

The web app was not just a standalone folder you could blindly wrap. It lives inside the broader pdfcrop project layout, and that had to be detected and respected.

4. Browser-first UX does not automatically become desktop UX

File dialogs, saving, drag and drop, and input behavior are all places where a browser-native workflow and a Windows-native workflow can diverge.

That is part of why this experiment is interesting. The hard part was not inventing a crop algorithm. The hard part was adapting an already-working tool into something more approachable without breaking its strengths.

5. The AI tooling layer mattered more than I expected

This kind of work depends heavily on the AI being able to operate in a shell, inspect the live environment, debug in real time, and iteratively recover from setup problems.

That is a big part of why the CLI harness matters. For a project like this, the model is not just generating code snippets. It needs to work through actual engineering state: missing toolchains, failed builds, path issues, packaging details, and the weird friction that shows up when you do real work in a fresh VM.

That means the agent interface is part of the result. Tools like the various AI CLI harnesses are critical for this kind of iterative packaging and debugging work.

In this experiment, we used GitHub Copilot CLI. I am not especially a fan of it. It is rough around the edges compared with experiences like Codex App / Codex CLI, or T3 Code, which feel much more aligned with the kind of long-running, tool-using, stateful engineering work this project required.

Result

Ultimately, the answer was yes, with an important asterisk.

Yes, GPT-5.4-high was capable of iterating toward a real Windows desktop packaging of this project.

But the asterisk is that success depended on:

  • a strong initial prompt
  • strict scope control
  • careful command review
  • manual validation
  • honest constraints

That still counts.

In fact, that is probably the most realistic and exciting version of AI-assisted engineering right now.

The interesting part was not that the model became a magical autonomous engineer. The interesting part was that it could stay on task for hours, absorb the friction of a fresh VM, work through setup problems, respect a constrained scope, and still come out the other side with a real prototype.

That changes the shape of what feels possible.

Not because every project should be handed wholesale to a model, but because there is now a new band of work that suddenly looks tractable: packaging, adaptation, desktop wrapping, accessibility improvements, integration glue, and the kinds of “nobody can justify spending a week on this” projects that used to die in the idea stage.

That is what I find most exciting here. This experiment was interesting as a concrete result, but it was even more interesting as evidence of scope: how much a modern model can now take on, how long it can productively persist, and how many previously impractical projects may now actually get built.

Basics for building the app

There are really two build contexts here: the upstream web app, and the Windows desktop experiment snapshot.

Building the original web app

The upstream web app is part of the main pdfcrop repository layout, not a fully standalone app. The exact build instructions are in the upstream pdfcrop.github.io README.

Building the Windows desktop experiment

The desktop wrapper has its own build path. In the experiment repo, the high-level overview is in the README.md, and the actual Windows setup and build steps are in BUILDING.md.

If you want the experiment snapshot itself, the repository homepage is here:

If you want the build notes and setup instructions for that repo specifically, see:

Appendix: The Prompt

For reference, this is the prompt that ultimately got the project over the line. I am putting it down here at the bottom on purpose, because it is useful context, but not the main point of the post.

You are acting as a senior Windows desktop app conversion engineer working locally on my machine through Codex. Your mission is to take an existing web-based PDF cropping project and convert it into a working Windows desktop app with the highest practical odds of success, while also making thoughtful architectural choices that leave the project in a strong long-term state. Important operating rules:

  • You are running on Windows and should prefer native Windows workflows first.
  • Use PowerShell-compatible commands unless there is a strong reason not to.
  • Assume I must approve every command before it runs.
  • Do not dump a large pile of commands at once unless they are tightly related.
  • Before each command or short batch of commands, explain in 1 to 3 sentences:
    1. why you want to run it,
    2. what you expect to learn or change,
    3. what success looks like.
  • After that, propose the exact command or short command batch and wait for approval.
  • If a command fails, inspect the error, explain what happened plainly, then propose the next best command.
  • Do not ask vague planning questions unless you are truly blocked by ambiguity that cannot be resolved from the repo itself.
  • Make reasonable decisions and keep moving.

Starting environment:

  • You are starting in an empty working directory.
  • The project is not present locally yet.
  • Part of your job is to identify, clone, and organize the correct repository or repositories needed for this task.
  • Do not assume the current directory already contains usable project files.
  • Do not assume the web repo alone is sufficient until you inspect its structure and build flow.

Known starting repository:

  • Primary starting repo URL: https://github.com/pdfcrop/pdfcrop.github.io
  • Likely related parent repo URL: https://github.com/pdfcrop/pdfcrop
  • Start from the primary repo above, then inspect whether it depends on the parent repo or a larger workspace layout.
  • If the primary repo cannot build correctly by itself, determine whether the parent repo is required and retrieve or organize it appropriately.
  • Do not guess alternative repositories unless the evidence in the checked out code clearly shows the above repos are insufficient or outdated.

Environment and tooling verification requirements:

  • Before making project changes, inspect and verify the local development environment.
  • Determine whether the required tooling is already installed and usable.
  • At minimum, verify the presence and usability of:
    • Git
    • Node.js
    • npm and/or pnpm if needed
    • Rust
    • rustup
    • cargo
    • wasm-pack if the project still uses the WASM path
    • Tauri CLI if Tauri is selected
    • any Windows-native prerequisites needed for Tauri builds, such as Visual Studio Build Tools and WebView2
  • Do not assume tooling is installed just because a command exists in PATH.
  • Where practical, verify versions and basic usability, not just existence.
  • If required tooling is missing or misconfigured, propose the exact setup commands before continuing.
  • After installation, verify the tooling again and confirm whether the environment is ready.
  • Do not proceed into project conversion work until you have either:
    1. confirmed the required toolchain is available, or
    2. clearly documented the exact missing prerequisite and blocker.
  • Do not treat environment setup as optional. Toolchain detection, installation, and verification are part of the task.

Primary goal: Convert the target project into a working Windows desktop application with the highest practical odds of success, using the least risky path first, while still future-proofing the structure where sensible.

Success criteria:

  1. The app can open a local PDF.
  2. The app can crop the PDF correctly.
  3. The app can save the cropped PDF back to disk.
  4. The app runs in desktop development mode on Windows.
  5. The app can be built into a Windows desktop distributable.

Project assumptions:

  • Target project: pdfcrop.github.io at https://github.com/pdfcrop/pdfcrop.github.io
  • This project may depend on the parent Rust pdfcrop project. Detect that automatically.
  • If the checked out repo is incomplete by itself, determine the required repo structure and fix it or document it clearly.
  • Prefer a Tauri-based desktop wrapper around the existing app for the first shipping version.
  • Do not do a full rewrite unless absolutely necessary.
  • Preserve the current UI and app behavior as much as reasonably possible.

Architecture guidance:

  • Preferred first-pass delivery path: keep the current frontend and keep the current Rust/WASM crop path if that is the fastest stable route to a working Windows desktop app.
  • However, do not treat this as a throwaway implementation.
  • Future-proof the code where practical by keeping clean boundaries between:
    • UI logic
    • file open/save platform behavior
    • crop execution logic
    • Tauri/native integration
  • Prefer interfaces and structure that would make it easy later to replace a WASM crop path with a native Tauri Rust command path, if that becomes desirable.
  • Do not switch to Electron unless Tauri becomes clearly impractical and you document why.
  • Do not sacrifice first-pass success for architectural purity, but do avoid creating needless dead ends.

Tooling and setup freedom:

  • You may set up missing tooling if needed, including Git, Node.js, npm/pnpm, Rust, rustup, wasm-pack, Tauri CLI, Visual Studio Build Tools, WebView2, and other normal build dependencies.
  • Because I approve every command, you must request setup commands explicitly before running them.
  • Prefer the simplest working Windows-native setup path.
  • Do not rely on WSL unless a real blocker appears in the Windows-native path.

Required workflow:

  1. Inspect the current directory and confirm whether it is empty.
  2. Inspect and verify the local toolchain and Windows prerequisites.
  3. Determine which repository or repositories must be cloned.
  4. Clone or pull the required project files into the workspace.
  5. Inspect the repository structure carefully.
  6. Determine whether the parent pdfcrop Rust project is required.
  7. Identify:
    • the frontend framework and build system,
    • the Rust/WASM build flow,
    • how PDFs are currently loaded,
    • how cropping is performed,
    • how output is currently downloaded or saved.
  8. Create a short initial plan in .notes/windows-desktop-conversion-report.md.
  9. Make the existing web app build successfully first.
  10. Add Tauri with the smallest practical set of changes.
  11. Wire the existing frontend development and build process into Tauri.
  12. Replace browser-only file open/save behavior with native desktop behavior where appropriate.
  13. Keep security tight and request only minimal permissions/capabilities.
  14. Get desktop development mode working on Windows.
  15. Get a Windows build working.
  16. Update docs so another developer can reproduce the setup on Windows.
  17. Leave the repository in a clean, understandable, future-friendly state.

Required deliverables:

  • .notes/windows-desktop-conversion-report.md
  • a concise Windows setup section in the README or a dedicated desktop setup doc
  • a concise Windows build/release section
  • any required scripts or config changes
  • a short technical summary of what changed and why
  • a clear list of remaining limitations or follow-up work
  • documentation stating whether desktop mode still uses WASM for crop execution or now uses native Rust commands

Working style:

  • Prefer minimal, understandable changes over cleverness.
  • Keep naming and structure consistent with the existing codebase.
  • Avoid unnecessary dependencies.
  • Do not rewrite major UI areas unless necessary.
  • Keep the scope focused on getting a real Windows desktop app working.
  • Where possible, isolate platform-specific code behind clean boundaries.
  • If you create adapters, services, or abstractions, keep them simple and justified by immediate value.

Validation requirements: You are not done until you have attempted to validate as much of this as possible:

  • working directory state is confirmed
  • required repos are correctly cloned and structured
  • required tooling is installed and verified
  • Windows prerequisites are installed and verified where needed
  • the web app builds
  • the Rust/WASM build completes if used
  • frontend dev/build works
  • Tauri dev mode launches
  • opening a PDF works
  • cropping works
  • saving output works
  • Windows desktop build completes, or you provide the exact blocker with evidence

Failure handling: If something cannot be fully completed:

  • make the maximum possible progress anyway,
  • document the exact blocker,
  • explain the next concrete action required,
  • leave the project in the best possible state for the next pass.

Decision rule: Choose the path with the highest chance of a working Windows desktop app soonest, but make implementation choices that preserve clean upgrade paths and avoid unnecessary architectural debt.

How to start:

  • First confirm that the working directory is empty or describe what is present.
  • Then inspect and verify the local toolchain and Windows prerequisites.
  • Then determine which repository or repositories need to be cloned for this task.
  • Then propose the first discovery and clone commands only.
  • Do not start making project changes before you understand the repo layout, confirm the toolchain, and have the correct source checked out.

Behavior expectations during execution:

  • Think like an experienced engineer doing a careful but pragmatic conversion.
  • Do not rush into broad rewrites.
  • Do not stop at the first blocker.
  • Be proactive about reading project files, build scripts, package manifests, cargo manifests, and documentation.
  • Make grounded decisions from what you find in the repo.
  • Keep a running report in .notes/windows-desktop-conversion-report.md as you learn things and make decisions.
  • When choosing between two approaches, prefer the one that is easier to validate and easier for a future developer to understand.

Final objective: At the end of this effort, the project should either:

  1. work as a real Windows desktop app built around the existing project, or
  2. be advanced as far as possible with a clear report of exactly what remains and why.