OOretz Factory ← All case studies

⚠

Illustrative draft — not a real build report. The numbers below are placeholders for what a build report would look like on this surface. The factory has produced multiple verified end-to-end runs on the web pipeline — see Recipe Manager Web for the first one, and /factory/proof for the live list — but this desktopcase study uses a roadmap surface that has not produced a verified artifact yet. We’ll replace these numbers with real ones once a desktop run completes.

Case study · Finance & accounting

Building Check Writer Pro — illustrative build report

PLACEHOLDER. This page describes what a successful build report would look like for a Windows desktop MICR check writer. The numbers below are illustrative — the desktop pipeline has not produced a verified artifact yet (Windows bridge provisioned-but-stopped, no end-to-end desktop run on prod). The web pipeline ships verified runs daily; see /factory/case-studies/recipe-manager-web for the first one and /factory/proof for the live list.

OOretz internal — illustrative draft (desktop surface, no verified build yet) · published 2026-04-12

AI calls

87

across all phases

Lines of code

4,217

C# + XAML

Build attempts

3

2 repair cycles

Wall-clock time

12 min

6.4 bridge min

The prompt (verbatim)

$Build a Windows desktop MICR check writer. Vendor book, two-approver workflow for amounts over $10,000, stub history, daily Excel export. Use WPF + .NET 10. Bank-grade print quality required.

What the manifest extracted

Entities4

Workflows3

Surfacesdesktop

Capabilities requiredwindows-build · print-driver · excel-export · role-separation

Timeline (12 min total)

00:23

Intent parse → AppManifest

4 entities, 3 workflows extracted on first try

00:03

Capability resolution

Windows bridge required (print driver dependency)

00:18

Scaffold WPF project

Materialized 8 boilerplate files from template

02:32

Generate entity classes (Vendor, Check, Approval, AuditEntry)

All 4 entities written with EF Core mappings

03:11

Generate WPF views + view models

12 views, 12 view-models, MVVM wiring complete

01:28

Generate MICR print driver

Custom System.Drawing print handler with E13-B font

00:47

First build attempt

2 compile errors: missing using for System.Printing, type mismatch in ApprovalDialog

00:31

Repair cycle 1

AI fixed both errors

00:41

Second build attempt

1 compile error: unused IDisposable in PrintQueueManager

00:22

Repair cycle 2

AI wrapped resource in using block

00:38

Third build attempt

Build succeeded — 0 errors, 4 warnings

00:12

Launch verification

App started, main window rendered, screenshot captured

00:28

Package + sign

Self-contained EXE, 84 MB, SHA-256 in proof pack

Verification

Compile result: failed after repair
Build attempts: 3
Repair cycles used: 2
App launched: yes ✓
Screenshot captured: yes ✓

Final artifact

Surface: Windows desktop EXE
Size: 84 MB
SHA-256: sha-pending-real-run
Runs on target: yes ✓
Downloadable: yes

What we learned

✓ What worked

WPF MVVM scaffolding template was the right call

We had a pre-built WPF + EF Core + MVVM project template that the factory used as a starting point. This meant the AI never had to generate the boilerplate it gets wrong (csproj files, App.xaml.cs wiring) and could focus on the domain code.

✓ What worked

Per-entity generation > whole-app generation

Generating Vendor / Check / Approval / AuditEntry one at a time (with relationship context) produced clean code. An earlier experiment asking the AI to generate the whole app at once produced spaghetti.

✗ What didn't work

First MICR font selection was wrong

The AI initially used E13-A (which doesn't exist as a Windows font). The repair cycle had to fix this to E13-B + fallback to system OCR-B. Documenting this in the error catalog so future MICR prompts get it right first time.

✗ What didn't work

Print driver lambda capture caused IDisposable warning

PrintQueueManager held a PrintServer in a lambda — never disposed. The compile-fix loop caught the warning but the AI's first repair just suppressed the warning instead of fixing the leak. Second repair got it right.

? What surprised us

2 repair cycles is enough — even though we allow 5

We capped retries at 5 because we expected complex apps to need 3-4 cycles. In practice, the AI usually fixes everything in 1-2 cycles or never. The cap is there to bound cost, not to enable convergence.

? What surprised us

Total wall time was 11 minutes, not 5

We advertise ~5 min for desktop apps. This one ran 11 minutes because the MICR print driver generation took longer than expected (88s) and we had two repair cycles. We've updated our pricing page bridge-minute estimates accordingly.

Try this build yourself

The exact prompt from this case study is in our launchpad. Click below to drop it into the operator pre-filled.

Launch this prompt →Other starter prompts