Peko

Peko started as a technical idea I thought was interesting and turned into a much bigger application development and deployment platform. The pitch was simple. You write a web app, and Peko gives you back a real native app for each platform without you having to touch any of the platform-specific parts.

The conversion is the easy half. What made it hard was everything it had to hide. Store screenshots, remote Apple builds (because you cannot build for Apple platforms anywhere else), signing, per-platform build infrastructure, deployment. So most of what I actually built was infrastructure, not product.

I started it in December 2020 and worked on it in some form until August 2026. The public git history is much shorter than that because the repositories got restructured near the end, but Peko is most of the time I have spent building software.

Peko apps are written in Pekoscript, a statically typed language I designed and wrote the compiler for. Type checker, LLVM 18 backend, linker across five platforms, CLI, language server. About 89,000 lines of Rust.

It is the part of all this I am proudest of.

The one design decision I would defend anywhere is splitting the system into two pipelines that never touch each other.

The prebuild pipeline compiles the native runtime. It runs rarely, by hand, on a machine with a full native toolchain, and it spits out one fully linked binary per platform and architecture into a private artifact store.

The assembly pipeline turns a developer's build into a shippable app. It runs constantly, on the build host, and it contains no compiler at all. It injects assets, writes manifests, compiles resources, and signs. It takes seconds.

A developer never sees either one. They install an npm package and run peko deploy. Keeping the compiler out of the path that runs on every single deploy is the whole reason that was possible.

A native runtime in C and C++ with a real backend per platform. Objective-C for Apple, Java for Android, Win32 and COM for Windows, GTK for Linux.

A Rust workspace holding the developer CLI, the build server, an assembler, the bundlers, and codegen. An interface definition that generated both sides of the JavaScript to native bridge, so the two could not drift apart. A typed JavaScript SDK shipped as the peko npm package, which was the only public piece.

Then the surrounding stuff. A web app, a studio app, the remote build platform, and the developer tooling.

Not because it broke and not because it got too hard. I stopped because after five and a half years I still could not convince myself the opportunity was good enough to justify another five.

The technical problem stayed interesting the entire time, which is exactly the trap. I had built something difficult, and difficulty kept feeling like proof that it mattered. It is not proof of anything except that it was difficult. The questions I had never really answered were about who needed this badly enough to pay for it and switch to it, and the longer I looked at those the worse I felt about them.

So I put it down. The site is still up and the repositories are still there. I am not maintaining it and I would rather say that than pretend otherwise.

I picked Peko because it was technically interesting. That is a fine reason to build something and a bad reason to start a company, and for a long time I did not notice I had swapped one for the other. Everything after that followed from it.

Because the problem stayed interesting, difficulty started feeling like validation. Every hard thing I solved made me more confident and none of it said anything about demand. I was collecting proof that I could build it and treating it as proof that I should.

The effort ratio was backwards the whole way through too. Almost everything went into execution and almost nothing into whether the thing deserved executing. By the time I looked at that properly I had five years of infrastructure sitting on a question I had never answered.

Putting it down was harder than any of the engineering. The pull to keep going was not really about Peko. It was about not wanting five and a half years to have been a mistake, which is the exact reasoning that turns five years into ten.

So the question I used to ask was what can I build. Now it is what is actually worth building, and those produce very different project lists. In practice it means running the order backwards from how I used to. Find real work that real people do, understand it in detail before proposing anything, find where it hurts, work out whether the pain is worth money to someone. Only then build something narrow at it.

The loan processor research is the first time I have run it that way and it is deliberately still on the understanding step. It might end with nothing there, which would be a real answer and a much cheaper one than last time.

The site and the code are both still online if you want to see what it actually was.