~120MB
ClaudeView resident memory
Service · Windows apps
Native Windows apps that launch instantly.
Plenty of desktop software today is a browser in a trench coat: half a gigabyte of memory to show a window that takes five seconds to open. Building something that actually feels native is a different job.
Cold start under a second
Signed installer
Self-updating
What ships — and what it costs the machine
WebView2 is a tool, not an architecture. It gets used for the panes that benefit and nowhere else.
.NET 8
C#, WPF, and WebView2
6–14wks
Scope to handoff
~5/yr
Client builds we take on
The gapBrowser in a trench coat What native buys you
A window is not an app. Users can tell.
Shipping a web app inside a desktop frame is the fastest way to a build. It is also why so much desktop software now feels slower than it did a decade ago.
- Half a gigabyte resident to show one window
- A cold start you can count out loud
- Scrolling and text rendering that feel almost right
- An entire browser engine shipped per app, then again per update
- OS integration bolted on afterwards, if at all
- Cold start under a second on ordinary hardware
- A footprint measured in tens of megabytes, not hundreds
- Real tray, shell, and file-association integration
- A signed installer and silent self-updates
- WebView2 for the panes that genuinely earn it, and nothing more
How it runs
A build you can install every week.
Week 0
Scope call
We start with whether the thing is worth building at all. If we are the wrong shop for it, we would rather say so in week one than in week nine.
Weeks 1–2
A thin slice, end to end
One real path all the way through the system. Ugly, but running and instrumented, so the unknowns surface while there is still time to do something about them.
Weeks 3–11
A demo you can poke at, not a status update
Something real every week. Nothing gets saved up for a reveal at the end, so a change of direction costs a conversation instead of a change order.
Final week
Handoff with runbooks
Code, deploy steps, and what to do when it breaks at 3am. We stay available for follow-on work, but we do not build in a dependency on us.
Half a gigabyte of memory to show a window that takes five seconds to open.Concept211 · Windows desktop apps
Photo by Nikita Kachanovsky on Unsplash
Built with
The stack behind our own desktop app.
ClaudeView runs on exactly this. The failure modes are ones we have already hit on our own release channel.
WindowsTarget platform
.NET 8Runtime
TypeScriptWebView2 panes
Claude SDKAgent SDK
Proof · our own build
Read the case study
ClaudeView is this service, shipping to real users.
A native Windows workspace for Claude Code
Our own answer to the bloated-desktop problem: one workspace around the Claude Code workflow in roughly 120 MB instead of a full editor, with a signed installer that updates itself. It is the reference build for everything on this page.
~120 MBResident memory
.NET 8C#, WPF, WebView2
Self-updatingSigned installer
Before you ask
Questions we get every time.
The things people ask on the first call, answered before you have to ask them.
Ask us something elseWhen do you need a native app instead of a web wrapper?
Two situations come up. You have an aging desktop app that still works but is painful to maintain and looks its age, or you want a new native tool and do not want to ship a heavyweight web wrapper to get it. If instant launch, a small memory footprint, or real OS integration (tray, file associations, shell context menus, background services) matter, native is the answer. If none of them do, we will tell you to build a web app instead.
What stack do you build on?
C# and .NET 8 with WPF for the native interface, and WebView2 where an embedded web surface genuinely earns its place. This is the same stack behind ClaudeView, our own native Windows app, so these are patterns we run in production rather than ones we are learning on your project.
What does the build include?
A native application with a modern interface, fast cold start, and a small footprint. That includes a proper MSI or MSIX installer, code signing, and self-updating so users are never stranded on an old version. It ships as software you own, with source and runbooks.
How long does a desktop build take?
Six to fourteen weeks from first scope to handoff, with a working build you can install every week. Modernizing an existing app usually lands at the short end because the domain logic already exists and the job is the shell around it.
Work with us
Start a project Have a Windows app to modernize?
Or a native tool to build without the browser-in-a-window baggage. Either one is the work we take on, and you own the source at handoff.