Your app. Your servers. Your rights.

I build software with a system I made, called Fran.

Not an autocomplete and not a chat window that emits files. Fran takes a stated intention and carries it through: it works out what needs building, writes it, reviews it, argues with its own review, tests it, ships it, and then watches what it shipped. It has been doing that against a fleet of real products that real people use.

I am writing this down now, publicly, because I am about to go quiet. In August I start a full-time job that has nothing to do with this. The work continues at nights and weekends, at the pace nights and weekends allow. So this is a dated marker: here is what exists, as of today.

The name is for Frances Allen, who made compilers rigorous. It is the pitch, more or less: Fran does not invent your product or your taste. Fran compiles them, and then makes them hold.

What you get

It builds the thing. This is the least interesting part in 2026 and I won't spend words on it. Machines write working code now.

It builds it ready for real users. This is where most AI-built software falls down, and it's worth being precise about what "ready" means, because the word has been spent. It means the second browser tab works. The empty state was designed rather than forgotten. The error state tells you something. A different user — not the one the machine imagined — sees their own data and nobody else's, and that is checked on every change rather than hoped for. Features ship with evidence: real users driven through a real browser, doing the things your users will do.

It leaves you standing on ground built for machines. Most AI tooling treats your codebase as an archaeological dig — read it, guess, hope. Fran writes down what your product is supposed to do as checkable statements, keeps the design a declared system rather than a pile of accumulated CSS, and keeps the shape of your deployment a fact rather than folklore. The effect is that every future request lands on ground the machine can stand on. The second year of work is cheaper than the first, instead of more expensive.

And it keeps working after launch. The brain doesn't stop at ship. It keeps reading the running product — noticing, proposing, fixing. On my own platform a warning fired at three in the morning, the system diagnosed it against its own rules, wrote its own fix, and shipped it through the same gates as any feature. I read about it the next day. That is what you keep paying for.

What you own, and what you rent

This is the part that makes Fran different from everything else in this space, and it is a deliberate choice rather than a limitation.

Every tool racing toward "production-ready" shares one incentive: they host you. Your application lives on their platform, your data sits in their account, and their margin is your rent. Export is an afterthought, because lock-in is the product.

Fran starts from the opposite end. When the work is done, everything is yours. Cancel the subscription and the application keeps running — you lose the brain, not the business. What you keep is a complete, documented, boring-in-the-good-way system that any competent team can pick up.

The keys matter more than they look. The AI works on your API keys, always. I never hold them, never proxy them, never log them. That means your product knowledge never subsidises anyone else's model, and it means an entire category of failure — success bankrupting the supplier — is impossible by construction rather than by promise.

That this is real

Everything above would be thought-leadership if I hadn't been running it. As of today, all of it checkable:

• More than 600 pull requests written by machines, reviewed, and merged, across 30 repositories. Not suggestions — merged code in products that are live.
• Five products in production, plus a mobile application that passed both Google Play and Apple App Store review and is live to the public: Giftdays — gift coordination for families.
• The others, unlinked because they are mid-work or invite-only: a Swedish language-learning product, a party-game platform, a deckbuilding workspace, and a subscription-billing service.
• Requirements that don't rot. Each product carries its rules written down and tied to the code that implements them, re-checked automatically against the live codebase. When code and intention drift apart, that becomes a bug report rather than a surprise eighteen months later. As of today, one product's rules read: 13 proven against the running system, 1 failing — held open and visible rather than quietly fixed. A rule with no evidence is never silently green.
• Production problems get caught before they are outages. The rules that gate a feature are the same rules that watch the running system.

One honest note on that list, because it changes how you should read it: those links prove the products are real and shipped. They can't prove what built them — from outside, nobody can tell a machine-built application from a hand-built one, which is arguably the whole point. What I can offer is this page, dated, and the fact that I put my name on it.