Garrick van Buren

• A customer
• An offer
• A way to take payment

The rest you can pick up along the way.

LLMs will become small enough and cheap enough and most computers powerful enough that they’ll be readily and easily embedded into most software. General purpose LLM providers – OpenAI, Anthropic, etc – will largely exist as research organizations. On a day-to-day basis we’ll interact with LLMs more, but they’ll be run & maintained by the same companies that maintain the software wrapped around the LLMs. LLMs will be invisible,

[In collaboration with Ivan Stegic]

“Context is that which is scarce” – Tyler Cowen

Product companies have an allegiance to the product. 

Service companies have an allegiance to the customer.

Both are legitimate vows. 

Both, unexamined, become traps.

The coastline paradox — the more accurately you measure the coastline, the longer it grows — is the most precise metaphor for this trap.

The closer you get to matching your offering to your customer’s precise shape, the more shape there is to trace. It never bottoms out. Their coastline is infinite.

Too often product leaders are hesitant to even lower their elevation claiming ‘it doesn’t scale’ – despite the competitive advantage waiting in the details.

The customer faces the same question from the other side. 

Before choosing a vendor, someone at the customer has to decide:

Do we want to invest our competitive advantage in this JobToBeDone?

• If yes – let’s get a tailored-fit solution to start and consider building out an internal team.
• If no, we’ll adapt to the undifferentiated product and focus time, energy, and budget elsewhere.

The customer who chooses a product company isn’t settling. They’re making a deliberate choice not to compete on CRM, project management, email clients, calendaring, document management, accounting, or hosting. The customer choosing a service company is betting a custom solution will serve them better. Both are allegiances to a strategic outcome for their organization.

---

Let’s imagine a customer’s organization as terrain as dramatic as mountainsides and fjords. 

A product company operates at elevation, let’s call it satellite view; coastlines are visible, yet smallest inlets untraced. The higher the elevation, the more customers fit, but only in the most abstract manner. Despite the abstraction, the edges of the product are firm, which makes on-the-ground implementation awkward. Accommodations within the organization will need to be made and the pricing reflects the mismatch. 

A service company descends, and gets closer to the customer’s actual shape from the beginning. The promise: we will tailor to you, as perfectly as your budget will support. Higher price, because every engagement, every organization is unique, and little can be repurposed elsewhere.. 

The trap isn’t in which model is chosen, it’s in unexamined drift away.

---

Product companies don’t decide to become service companies. They inadvertently drift there, one big logo at a time. First, the product gets built for one prestigious customer’s inlets. Eighteen months later it perfectly fits this one customer and everyone else with increasing awkwardness..The portfolio quietly churns.

Service companies fall into the mirror image. The stated allegiance is to the customer — but the actual allegiance, in practice, is to the ongoing relationship. They seem identical until the desired outcome is achieved. Then they diverge.

Allegiance to the relationship says: Stay, find more to do, trace more coastline.

Allegiance to the outcome says: You’re done. Leave.

Consultant: noun, someone who comes in to fix a problem but ends up becoming part of it.

The service company’s trap is confusing being needed with being effective.

---

There’s a third allegiance, and it’s the one worth keeping: allegiance to the outcome.

For the product company, it’s answering every anchor customer request with a simple question: Does this serve the outcome we promised the portfolio, or just this one? 

For the service company, it holds the line against indefinite engagement. The practitioner who leaves when the work is done is being faithful to the outcome, not disloyal to the relationship.

Both take discipline.

The competitive advantage for a product company lives in controlled descent, going just a little deeper into the customers’ shape than the competitors; dedicated Customer Success, dedicated account executives, custom onboarding, custom implementation. Deliberately priced. 

The danger is reactive descent, subletting office space from the customer.

Back in the 1900s when I was in 4th grade, the teacher gave us an exercise: Successfully get a robot to sharpen a pencil.

Now this was public school in rural Wisconsin, we didn’t have robots. What we did have was other 4th graders. So, once you hand wrote out your instructions and handed them to the teacher, a fellow student randomly selected a set of instructions and executed them.

Perfectly to the letter.

To inevitable failure and laughter from the entire class.

For even at 9 years old, we make assumptions about the important parts of a task, and we leave out substantial context; either because we don’t appreciate it or we take it for granted.

For the past 4 years, I’ve been managing DÉJÀ BRÜ via WordPress, WooCommerce, a Trello board, and a series of Google Sheets. It’s a small competition, so it works well enough. But this year, the fragmentation got to me, so two days after the competition was over I opened up Claude and started vibe-coding a homebrew competition management app.

Since Claude Code starts a $20/month, I just started with the chatbot, and had it generate a shell script to generate the app, then about half way through the week, I paid the $20 and it sped things up considerably.

But let’s set the full context.

Between 2000-2010, I taught myself PHP, MySQL, Ruby, Rails, and Javascript. I had a shelf of books covering all 5. If you dig back into this blog, you’ll find loads of posts from that era.

However in the intervening years, I’ve done little programming either for myself or others. Turns out, even maintaining a development environment takes deliberate effort. I grew tired of chasing the latest hotness (e.g. Node.js). I grew weary of managing server up-time and fixing bugs. So I stopped.

Then, in fall of 2021, I got an idea for an app to help me organize my genealogy research, so I dusted off my Rails skills and started building. When I completed the research project, I turned the app off and haven’t visited it since.

So, it’s been 5 years since I’ve used any software I’ve written and at least a decade since anyone else has.

Seems like it might be time.

As of this writing, I’ve spent $20 and Claude Code has helped me with 3 apps.

• A homebrew competition management app (~12hrs, from scratch, currently deployed on a test server)
• A homebrew recipe management app (~6hrs; from scratch, currently migrating my recipes into it, still local)
• The aforementioned genealogy research app (~3hrs; updating to Rails 8, and adding mapping, still local)

And that’s just been in the last week.

I’m absolutely left with the sense that vibe-coding is a misnomer, it’s more like technical writing, more like clearly articulating how to sharpen a pencil to a 4th grader.

Here’s my initial prompt for the competition management app:

create a ruby on rails app for beer judging.
2-3 judges per flight of 5-6 entries. homebrew competition, bjcp-sanctioned, but arbitrary styles could be select, from full BJCP to just a single historic style not recognized by the BJCP. actors: judges, entrants, stewards, organizer roles; cellar, judge coordinator, event coordinator, admin. entrants submit their own entries, some competitions may be paid, others may be free entrants get downloadable scoresheet PDF, publicly available leaderboard. devise for auth, unless Google OAuth would be easier. payment via Paypal. full rails with views. probably Heroku for deployment. the minimum I'd like; entrants enter beers, judges can register, organizer and assign beers to categories, organizer + judge coordinator can assign judges to flights while avoiding any potential entry conflicts, judges can evaluate a beer, entrants can see evaluation within their account.

As you can see, I had some requirements.

Now, there have been a few pleasant surprises at what Claude implements outside of my request (feature or bug?), and those suggestions usually force me to really consider what I want and how I want it to work. I find Claude’s code is readable and I’m comfortable making edits to it.

I tried Cursor for one of these vibe-coding sessions and found that while the code was somewhat higher quality (more readable, more concise), Cursor was a far worse business analyst, asking fewer clarifying questions, stubbing out worse features unprompted.

By the time Weekend Update started on Saturday night, I had deployed the homebrew competition management app to a test server and shared a link with my co-organizers. However, that in itself took 3 hrs – which is well within my past estimates of deployment taking 50% of the development time to date.

In the end, the primary reasons I hadn’t committed to building any of this software before: opportunity cost.

Why build custom software if Google Sheets works?

Why build custom software if stable, maintained, equivalents exist for $30/year.

I’m not sure that having an expert Rails developer at my fingertips for $20/mn substantially changes that. If anything, all this highlights is that writing the software was never the hard part – having an incentive to maintain it is.

And none of these 3 apps yet have that.

To this point, when I asked Claude to:

help me create a shell script to generate a ruby on rails app for managing homebrew beer, mead, and cider recipes

It’s initial response was:

Before diving into script generation, a few probing questions to make sure this is actually worth building right:

What's the actual gap? Brewfather, Beersmith, and Brewtarget already exist. What do they not do for you?

What's the scope? "Managing recipes" is vague. Are you tracking ingredients, fermentation logs, batch history, tasting notes, calculated ABV/IBU/SRM, scaling, something else?

Who's using this? Just you locally, or are you thinking multi-user, hosted, shared recipes?

Why Rails specifically? For a personal recipe manager, Rails might be overkill. Have you considered the tradeoff vs. a simpler tool?

Even Claude itself is aware of opportunity cost and was comfortable discouraging me right from the start. Not a bad thing to start with, “hey, have you actually tried the existing options?”

I have, and are my preferences worth the trade-offs? Unlikely. But here we go!

And now I’ve hit my rate limits without even knowing what they are, and it looks like they won’t reset for 4-5 days. Jeebus. These tools are highly unstable. More and more like the toy giraffe I evoked a year ago, the more you engage with them, the worse they are.

After being rate-limited on Claude yesterday, I did the next obvious thing and loaded up GitHub CoPilot, paid $10 to keep going. Quality seems just as good – if not slightly better, as CoPilot actually cares about specs and tests.

Update March 7: I canceled my Claude subscription. After sitting rate-limited for a work week, and pondering how much that was like waiting for scheduled computer time back in the 1900s, I had a list of things I wanted Claude’s help with, and for each thing the responses were so mid, and immediately hit rate-limiting again as I rebuilt context. I’ve kept the GitHub CoPilot subscription for the time being.

TLDR; Investor-focused accelerator programs no longer serve founders or investors.

Over the past 6 months, I’ve been hired by two different pre-seed accelerator programs to look at founder outcomes and make recommendations for improvements. In total I talked with 25 founders (growing, pivoting, sustaining and shuttered) and a handful of early stage investors, and I reviewed the current status of portfolio companies going back a decade.

In both, I found the same systematic mismatches between what founders need, what investors want, and what programs actually teach. But, this post isn’t about picking on these specific programs.

Over the years, I’ve been directly involved with a half a dozen accelerator programs and advised nearly 100 early stage founders. All of these programs were modeled off the playbook YCombinator drafted twenty years ago; select 12 promising startup teams, run a 12-week batch, provide mentor networks, teach founders to pitch investors, culminate in Demo Day, hope everyone gets follow on investment. All in exchange for 7% of your company.

Today, similar programs exist in every mid-sized city from Minneapolis to Columbus to Oklahoma City to Mobile to Appleton. Some programs are no equity, some are fully remote, some run 6 months or a year, but they all have the same key characteristics and they’re all investor focused.

But, the seed stage investor appetite has shifted pretty hard since 2022. Investors stopped attending Demo Days and programs have pivoted to “showcase events” open to the general public. More honest for sure, but a quiet admission a core value proposition of the program has evaporated.

“Founders need to talk to customers” & “Founders need to run napkin math.” – Investors that want solid fundamentals.

Founders across these programs were expecting continuous introductions to investors, and in general – they didn’t arrive. Perhaps because the investors still interested seed stage companies are looking for the fundamentals; early revenue, sales velocity, and unit economics – and the program managers knew it was too early.

“It took us a year after program to get the company ready for investment.” – One founder still surprised at the gap.

Yet, accelerators are still focused on pitching. I talked with two dozen founders, each winning numerous pitch competitions yet struggling to get a single customer sale.

This last point aligns with the most consistent regret I heard from founders – successful & unsuccessful, “I didn’t talk to enough customers.”

The cause:

• not knowing how to define their customer,
• not knowing how to find them once defined, and
• not knowing how to have a customer discovery conversation with them once they did.

A program that’s focused on the things today’s investors want, would look very different. No Demo Day, no pitching, no mentors. 100% customer pipeline-focused, napkin math-focused, early sales-focused.

Progress on these things will serve founders whether they pursue outside funding or not, and they’ll be a much stronger signal to potential investors in any market.

Cyberstarts.com is a potential model; tightly focused domain (cybersecurity only), pre-existing network of executive buyers (60 CISOs), rolling admissions.

Regional programs have geographic customer advantages in something – manufacturing, agriculture, healthcare, mining, aerospace. Build buyer networks in these domains. Connect founders to the five local mid-size customers they need to build sustainable businesses – and teach them how to develop those long-term, win-win relationships.

Claude and I talk regularly.

I’ve reached the end of multiple context windows with Claude.

I credit Claude with helping me articulate the long running thread through my career and personal interests (e.g “Find what we forgot”) and clarifying the current positioning of my business (e.g. “When technology breaks your revenue model – call me.”). Once every couple of days I’ll paste an email draft into Claude and say, “I’m having a difficult time saying what I’d like to say succinctly.” and I’ll often take the suggestions.

Additionally, I have a long running chat in Gemini where it scores and ranks companies I offer it against the characteristics of my best clients.

I have the same 4,000 characters of instructions in both Gemini and Claude.

I don’t use ChatGPT anymore.

I would characterize my current usage as:

• Rubber ducking
• Summarizing qualitative patterns
• English-to-English translations
• Ensuring I’m being comprehensive / appreciating conventional wisdom.
• Raising the minimum quality of communication

Overall, I’d characterize this as “Help me minimize common mistakes”. Claude calls it “Sharpening“.

The more I work with Claude, the more it feels like the Mirror of Erised, simply reflecting back whatever you give it in a more narcissistic package.

There’s still nothing new here and I’m still of the position that “AI is amazing about the thing I know nothing about….but it’s absolute garbage at the stuff I’m expert in.”

An Increasingly Worse Response

I don’t pay for Claude, which is to me is a sign it’s not yet become an indispensable co-worker. The reports I’ve read of Claude CoWork and other ‘agentic assistants’ mainly make me wonder why the human operator even bothered with automating the task in the first place.

The greatest value of CoPilot and Claude Code seem to lay in an assumption that all software must start from scratch in Node. As soon as you say, maybe I don’t need to start from scratch, suddenly an entire world of options opens up. Admittedly, they’re not distinct applications that can be discretely monetized. On the flip side, someone else is maintaining the system, has already fixed and squashed thousands bugs you’ve yet to even experience.

But creating software hasn’t been hard for more than 25 years. There have always been piles of frameworks and environments to accelerate the creation of software; Hypercard, VisualBasic, Ruby on Rails, WordPress, etc, etc.

The challenge is in maintaining it, hardening it, justifying why it should continue to exist – that’s the perennial problem.

And that’s the first question I ask, should we create this custom software at all? Or perhaps we frame the problem differently and solve it in a different way altogether; we can minimize our overall maintenance costs while still getting the same output…or completely eliminate problem.

You’re Not Going to Need It

Recently I upgraded all my Google Homes to Gemini…and now the voice is even more tediously verbose. When I set a timer, I want confirmation not a conversation.

I picked up a copy of Bots when it first came out and was enamored by the promise of software applications appearing so human and useful. This promise, like software maintenance itself has held constant over the past 30 years. Perennially unsolved.

On the news of Netflix acquiring Warner Bros, I’m reminded of how good Netflix has been at innovating their business model.

Over the past 27 years, their business model has changed multiple times and each evolution appears to be in direct response to the bottleneck of growth, from maintaining inventory of DVD to acquiring global streaming rights.

Year	Business Model	Bottleneck to Growth
1998	Sell DVDs over the internet	Need to continually replenish DVD inventory,
1999-2006	Rent DVDs over the internet	USPS delivery & return times
2007	Stream movies over the internet	Acquiring US streaming rights to a massive library of movies
2009	Start producing movies (Netflix Originals)	Number of subscribers watching Netflix Originals
2010-2012	Global expansion; Canada, South America, Europe	Maintaining rights globally
2025	Acquire Warner Bros Discovery

Patrick reminded us a decade ago that Everything Happens in Time, said another way: “everything happens at a time – whether deliberate or not.”

It’s been three and a half years since I wrote about my ever evolving calendaring practice. Everything I wrote about in 2022 is still true. The biggest change has been in that time is my heavy use of cal.com as a scheduling service for conversations with clients, prospects, customers of clients, friends, everyone and everything.

Heavily using a scheduling service like Cal.com is great, but I’ve found it requires a couple of non-obvious changes to my calendaring practice.

1. My commitments are now split across 2 calendars; “Committed” and “Tentative”. As I described in 2022, all my hard commitments – my morning run, prep & next steps for client meetings, travel time to & from in-person meetings, fixed personal commitments – whether to myself or others goes, into “Committed”. Everything else goes into “Tentative”. Cal.com integrates with “Committed”. Yes, this means stuff on “Tentative” may get over-ridden – and that’s OK. If there’s nothing on “Committed”, I’m not wondering how to make the best use of the new found time, I’ve got a plan. There’s probably a cleaner way to solve this, but at this point, it’s working fine.
   
2. Some people prefer I declare the date & time. So, if only to keep things moving, I’ve needed to create an Event Type within Cal.com for the times where I’m handle the scheduling. By scheduling it myself – rather than creating a normal calendar event and inviting the person – I still get Cal.com’s auto-population of a video conferencing URL, reminders the day before, and a rescheduling link.
   
   I have 3 standard durations; 30min, 45min, 60min. At a certain level of clarity, every conversation can fit within a 30min or 45min block.

The great thing about Cal.com (and other scheduling tools) is setting a minimum time between bookings, I set it at 15min, and I’ve found it so helpful that I now even space my own commitments by 15min.

A 5 gallon bucket with a spout that’s also a paint tray and a dustpan.

At the risk of evoking all of my past writing on chindogu, this is a nice reminder that there’s always room for improvement.

It’s just a matter of determining that developing improvement is worth your opportunity cost. It might not be. But that doesn’t mean everything’s been invented.

I’m also reminded of the 2010 Design of the Decade winner, Clear RX prescription bottle design;

I recommend AI: How/Why I Use It in its entirety here are just a couple of my favorite passages:

“As any musician knows intimately, the most interesting part of a new musical technology is its glitches: the inventors of the synthesizer hoped to position it as a replacement for strings or horns, but what we loved is the weird blorps; the amplifier was invented just to make a guitar more audible, but we loved distortion; Autotune et al. were invented to correct bad notes, but we loved crazy space-laser voices.”

“Every day the AIs “improve” their ability to make images (actually, I use one of my go-to AIs because it is hilariously bad). I believe that eventually the uncanniness will be refined away, and AIs will evolve from fascinatingly odd to comprehensively mediocre.”

“Expertise will not be sufficient to make a living…Hacks are in trouble. If somebody is making work that is uninspired, and unindividual, then they can indeed be replaced by a machine that just spits up boring chunks of mid-ness.”