I am now a Lovable Certified Partner

I am now a Lovable Certified Partner. It is a small thing on a page and a fairly practical thing in the work, so it is worth writing down what it does and does not mean.

Lovable is the tool I use to build most of what sits in the Building section of this site: PriceCopilot, Private Vault, Ecosystem Navigator, Pair-the-Plant, a program platform, a couple of calculators. I am not a developer and I have not become one. What I have is a working method for turning a problem I understand into something people can open in a browser in a few days, and the certification is a check on that method rather than on my ability to write code.

The reason I bothered with it is the same reason I keep building instead of writing about building. Most of my work is program design: accelerators, cohorts, partnership pipelines, community formats. In every one of those, the difference between a good idea and a real one is whether someone can put a working thing in front of a user this month. Being able to do that myself changes what I can promise a founder, a partner, or an institution, and it changes how honest I can be about what AI tooling does and does not solve.

What the certification says in practice: I know the platform well enough to take a product from an empty project to something deployed, with a database, auth, payments, and email where those are needed, without a technical co-founder standing next to me. It also means I have seen the limits from the inside. There are problems where the right answer is still a real engineering team, and I would rather say that in the first meeting than discover it in month three.

The thing I keep repeating to founders here: the constraint is almost never the tool. It is that nobody has written down who the first user is, what they do today instead, and what would make them stop doing that. Tooling collapses the build time from months to days, which is enormous, and it does nothing at all about that first paragraph. I have abandoned more of my own projects because of a weak first paragraph than because of anything technical.

For people I work with, three concrete effects. First, prototypes come out of conversations faster, so we argue about a working screen instead of a slide. Second, when a program needs internal software, an application flow, a mentor matching tool, a reporting view, we can build it rather than budget for it. Third, when I advise on AI adoption inside an organization, I am describing work I do every week, not a category I read about.

If you are non-technical and wondering whether this path is real: it is, with one condition. You have to be willing to own the whole thing, including the parts that are not fun. Data, permissions, what happens when the output is wrong, who gets the email when something breaks. The tooling gives you the build. The responsibility is unchanged.

If you want to build something and you are not sure whether it should be a prototype, a product, or a spreadsheet, write to me. That conversation is usually shorter and more useful than people expect.