About

One engineer, three attempts, eighteen years.

Frames Studio asks you to accept an unusual claim: that your application should live in a database and run without a build step. That is a reasonable thing to be skeptical about, and skepticism is easier to resolve when you know who is making the claim.

The person

Mitchell Maynard.

I build and operate cloud and on-premises software out of the Phoenix area. Azure App Service, Static Web Apps, Azure SQL, Application Insights. Kubernetes, K3s, Helm, Docker. SQL Server, PostgreSQL, DuckDB, and the migrations between them. Enterprise authentication, LDAP, and single sign-on, which is where most integration work actually goes to die.

The relevant detail is that I run the things I build. I am the one on the VM at 11pm when a container will not start, when a connection string is wrong, when a schema drifted between environments. Frames Studio is shaped by that. Every part of it that looks like a strong opinion is an opinion I earned by losing an evening to the alternative.

I write SQL first and reach for abstraction second. That is not a philosophy so much as a habit, but it explains most of the architecture on this site.

Provenance

This is the third attempt.

  1. 2008

    Minuteman

    I started building a database-driven runtime. It was wrong about a great many things and right about one: the toolchain was already too large in 2008. We shut it down in 2013, for reasons that had to do with timing and nothing to do with the idea.

  2. 2013–now

    framesWork

    The idea became framesWork, which has run in production for years at a publicly traded enterprise serving tens of thousands of internal users. Real workloads, real uptime, real engineering teams that stopped writing Dockerfiles and never asked for them back. That is the proof point, and it is operational rather than theoretical.

  3. 2026

    Frames Studio

    The same architecture, rebuilt as a public platform available to developers outside one enterprise. I am building it solo, with Claude as a collaborator. There is no team to scale, no roadmap to fundraise against, and no headcount to justify.

Eighteen years is a long time to hold the same opinion. I am aware of how that reads. The honest version is that I have been wrong about the timing three times and have not yet been persuaded I was wrong about the shape.

The book

Writing the argument down.

There is a book in progress that makes the case at length, in the voice of a principal engineer talking to another engineer rather than a vendor talking to a buyer. It opens with The Toolchain Is the Tax and works toward From Single Component to Production in 30 Minutes, which is the same claim this site makes, shown step by step instead of asserted.

It is not finished and there is no publication date yet. When there is one, it will be on this page.

Fair questions

Things you should press me on.

A solo-built platform with an unusual runtime deserves harder questions than a familiar one. These are the ones I would ask, and I would rather you ask them before you build anything than after.

  • What happens to my application if you stop? Your code is rows you can select. It is Python, HTML, CSS, and JavaScript in text columns, not a proprietary binary format. Ask me for the export and read it.
  • How do I debug something I cannot see on disk? Reasonable. Ask for the DevTools walkthrough rather than taking my word for it.
  • What is the actual isolation between tenants? Ask to see the lookup, the tenant precedence, and where it is enforced. It is one query and I will show you the query.
  • What is genuinely worse here than on a normal stack? There are real answers to this and I would rather give them myself than have you find them in month three.

Contact

Get in touch.

The most direct way to a real conversation is to tell me what you would point this at. I read every request myself.

Request Access

Code is at github.com/wraptor66.