Economics of Code #1

Since January 2025, I have been doing “low-code vibe coding”, which is my word for combining AI coding and applying low-code patterns. The impact on speed and throughput has been remarkable. The client is happy, and there have been a lot of behavioral changes.

My big learning is that speed solves so many issues.

Invoicing, pricing, estimates, and testing all changed. I might move away from project pricing and adopt an outcome and consumption pricing model. Still thinking…

Would it be possible to hire a senior solutions provider and pay a base retainer and a percentage of the token spend to support or operate? I'm unsure, but anything that better aligns the founders and outcomes is interesting.

Historically, I have done too much code that was out of scope because I dread telling a client that a great idea is out of scope. Saying ‘no’ never improves the working relationship (with a client). However, in reverse, doing hidden (i.e., unpaid or valued) work challenges the advising model.

This has been the underlying question in so many calls.

My code brain keeps noticing how things change when one key aspect of the unit economics of the cost of code ownership changes. Here are some behaviors I have noticed that are changing (at least for me).

Legacy Math #1: Redoing Work

In the old math, code cost too much to waste (time), so we did not build real, working prototypes. We loved the idea, but the time and effort did not pay off. Several times, I have gently forced a client to build a working prototype, but the perceived cost has made it a failed effort. The client does not value it, and the cost to the project makes it challenging to get good feedback.

In retrospect, this might be due to the time between the working prototype and the production version.

Legacy Math #2: Build to Learn

In the old math, we did not build the same thing in different ways to see how using an app would educate the UI/UX. We hired someone to be the UI/UX expert? Why? Is it because we needed to get it right first, or because of code costs?

Legacy Math #3: Single Customer Solutions

We (collective we) tend not to build a solution for a single customer using old code math. Sales processes require fast turnaround, and tech teams do not react well to one-off solutions.

In my last company, I dreamed of moving the innovation control and focus of the developer’s workflow to the product owners. Product owners sit between sales, leadership, and the customer. They have a very granular understanding of what is needed. I moved as much as I could out of code-level setup and into low-code so that product owners could create and independently deploy.

Economic Filter

I read Paul Krugman's newsletter on Substack, which makes me think I know something about economics. I don't. But I do know the cost of code I can not resell. When my last startup was winding down, I did call with potential buyers. Those were painful, code without contacts, and the team had zero market value.

Launch By Lunch - AI Accelerator

Two weeks ago, we launched an AI Accelerator for non-technical features. Tomorrow, our first cohort of founders and CEOs will get started.

We sold out quickly and are planning to run another set.

If you are interested, get on the waiting list. The current cohorts are designed to provide a community for the learning process. We plan to run team programs to take an existing founding team through the same process.