Alex Hormozi's $100M Offers Applied: Packaging Expertise as a One-Person Technical Shop

I just finished $100M Offers by Alex Hormozi. This is the companion to my $100M Leads breakdown, which was about generating attention. This one is about the harder question: once people find you, what exactly are you selling them?

My situation: I’m an independent engineer building production AI tools, publishing deep technical content, contributing to open source, and offering consulting. I have real expertise. I even have real revenue channels — consulting, a freemium SaaS product, an AI-operated Etsy shop. But I don’t have an offer. The difference, according to Hormozi, is everything.

Below is every concept from the book ranked by how directly it applies to where I am right now. Each section ends with a status tag and a next step.

The framework in 30 seconds

Hormozi’s core argument: most businesses compete on price because their offer is a commodity. A “Grand Slam Offer” is so differentiated that price comparison becomes impossible. You build one using three tools:

1. The Value Equation: Value = (Dream Outcome x Perceived Likelihood of Achievement) / (Time Delay x Effort & Sacrifice). Maximize the numerator, minimize the denominator.
2. The Delivery Cube: Map every problem your client faces, then generate solutions across multiple dimensions (DIY vs. done-for-you, one-on-one vs. group, etc.). Trim to the highest-value, lowest-cost combinations.
3. Enhancers: Scarcity, urgency, bonuses, and guarantees turn a good offer into an irresistible one.

The sections below are ranked by leverage and urgency for my specific situation.

1. I have offerings but no offer

This is the biggest gap.

Right now I have four separate things someone could pay me for: consulting on Claude Code and MCP, contract development using AI-paired workflows, a freemium SaaS product (Stylize MCP Server), and an autonomously-operated Etsy shop (ShopForge/ChateaucoreWalls). Each one exists independently. None of them are packaged together. None of them have a name. There’s no single page on my site where someone can see the complete picture and think “yes, that’s what I need.”

Hormozi draws a hard line between a service and an offer. A service is “I’ll consult with your team on MCP integration.” An offer is a named, bundled package that promises a specific outcome, includes bonuses that handle adjacent problems, has a guarantee that removes risk, and is priced to reflect the value of the transformation rather than the hours involved.

I’m selling services. The book says that’s leaving most of the value on the table.

Status: This is the core problem. Next step: design one complete offer targeting the audience I know best (engineering teams adopting Claude Code/MCP), using the Delivery Cube exercise from the book.

2. The Value Equation says I’m leaving money on the table

Value = (Dream Outcome x Perceived Likelihood) / (Time Delay x Effort & Sacrifice)

Let me run my current consulting through this:

• Dream Outcome: High. Teams want to ship faster with AI tools, and that’s a real competitive advantage right now.
• Perceived Likelihood: This is my biggest asset. I contributed to the official Anthropic MCP SDK. I’ve reverse-engineered Claude Desktop’s undocumented internals. I’ve built production MCP servers deployed on GCP. I’ve published more public documentation about these tools than almost anyone outside of Anthropic. When I say “I can help you integrate this,” the evidence is overwhelming.
• Time Delay: This is where I’m losing value. Consulting is open-ended. There’s no defined timeline to a result. “We’ll work together until it’s done” sounds flexible but actually reduces perceived value because the buyer can’t visualize when they’ll have the outcome.
• Effort & Sacrifice: Also a problem. Consulting requires the client’s team to do significant work. That’s appropriate, but from a value equation perspective, it increases the denominator.

The fix according to Hormozi: restructure the offer to compress the timeline (“your team will have a production MCP integration in 2 weeks”) and reduce client effort (“I’ll build the first server, your team just reviews and deploys”). Same expertise, higher perceived value, higher price.

Status: I understand the math. Next step: define specific timelines and deliverables for my consulting work instead of selling open-ended hours.

3. Charge premium prices

This chapter hit hard because the argument isn’t about greed. It’s about the economics of delivery.

Hormozi’s logic: if you charge $500 for something, you need 200 clients to make $100K. You can’t give 200 clients great service. If you charge $10,000, you need 10 clients. You can give 10 clients incredible service. Higher prices fund better delivery, which creates better results, which justifies higher prices. It’s a virtuous cycle.

The inverse is also true: undercharging creates a death spiral where you take on too many clients, deliver mediocre results, and burn out.

I haven’t published my rates, but I know from the Leads post that I’m positioned in a niche where few people have my depth. Hormozi’s point is that the market will tell me if my prices are wrong — the signal is that nobody says yes. If some people say no and some say yes, the price is right or too low. If everyone says yes, the price is definitely too low.

I have no data yet because I haven’t done enough outreach to know. That’s the honest answer.

Status: Theoretical. I agree with the logic but haven’t tested it. Next step: set a price for my first packaged offer that feels uncomfortably high, then see what happens.

4. Name it and frame it

Hormozi’s formula for naming an offer: it should describe the result, the timeframe, and the container. “6-Week MCP Integration Sprint” is an offer. “MCP Consulting” is a commodity.

Right now my site says “Working Together” and lists three bullet points. That’s closer to a menu than an offer. The name should do the selling before anyone reads the details.

Some directions worth exploring:

• Result-oriented: Something that communicates “your team will be productive with AI tools” rather than “I know about AI tools.”
• Time-bounded: Adding a timeframe (sprint, intensive, accelerator) signals compressed time delay, which the Value Equation says increases perceived value.
• Container-oriented: Is this an engagement? A program? A partnership? The container shapes expectations.

I’m not going to force a name before I’ve designed the actual offer. But this is something to return to once the Delivery Cube exercise from section 1 is done.

Status: Waiting on #1. Next step: name the offer after designing it, not before.

5. The Delivery Cube

This is the most actionable exercise in the book. For each problem your client faces, generate solutions across these dimensions:

Then score each solution on cost-to-deliver vs. value-to-client. Keep the high-value, low-cost items. Cut the rest.

For my audience (engineering teams adopting Claude Code/MCP), the core problems are:

1. They don’t know what MCP can do for their workflow
2. They can’t get their first MCP server into production
3. Their team is using AI tools inconsistently
4. They’re hitting undocumented bugs and behaviors
5. They don’t know how to evaluate whether AI tooling is actually improving velocity

Here’s where I can start filling in the cube. The blog and open source already cover the DIY column — people who can figure it out themselves using my published work. The gap is everything else: structured done-with-you and done-for-you options.

Some high-value, lower-cost ideas from the exercise:

• A template MCP server customized to their stack (done-for-you, one-time). I’ve already built the generic version with MCP API Bridge. Customizing it is marginal effort for me, high value for them.
• Async code review and architecture guidance via Loom or written reviews (done-with-you, weekly). Scales better than live calls.
• A Claude Code configuration and workflow audit (done-for-you, one-time). I’ve already done this for my own projects extensively.

Status: Exercise not yet completed. Next step: fill out the full cube, score each item, and use the results to assemble the offer from #1.

6. Bonuses over discounts

Hormozi’s rule: never lower your price. Instead, add bonuses that increase the perceived value of the package. Each bonus should solve the next problem the buyer will face after the core offer delivers.

If the core offer is “I’ll help your team get MCP into production,” the next problems are:

• “How do we maintain and extend it?” — Bonus: 30 days of async support after delivery.
• “How do we onboard the rest of the team?” — Bonus: a written runbook customized to their setup.
• “How do we know it’s working?” — Bonus: a monitoring and metrics template for their MCP servers.

Each of these is low-cost for me to produce (I’ve already built most of this for my own work) but high-value for the buyer because they remove the anxiety about what happens after the engagement ends.

Status: I have the raw material. Next step: formalize bonus ideas once the core offer is designed.

7. Guarantees

Hormozi outlines four types:

1. Unconditional: Full refund, no questions asked. Highest risk for the seller.
2. Conditional: Refund if they meet specific conditions and don’t get the result. “If your team completes all the exercises and you don’t have a production MCP server in 2 weeks, I’ll work for free until you do.”
3. Anti-guarantee: “All sales are final. This is for serious teams only.” Signals confidence.
4. Implied: Social proof and credentials serve as the guarantee. My open-source contributions and published research function this way already.

For my situation, a conditional guarantee is probably the right starting point. It signals confidence in my ability to deliver (which I have) while protecting against clients who don’t actually do the work. And it addresses the biggest objection a buyer has: “what if it doesn’t work?”

The question I don’t have an answer to yet: what specific, measurable outcome can I guarantee? “Production MCP server” is concrete. “Improved team velocity” is not. The guarantee has to be tied to something I can control.

Status: Framework is clear. Next step: define a guarantee once the core offer and its deliverables are concrete.

8. Scarcity and urgency

Hormozi distinguishes between real and manufactured scarcity. Manufactured scarcity (fake countdown timers, “only 3 spots left” when there are unlimited) erodes trust. Real scarcity works because it’s true.

I have real scarcity: I’m one person. I can only take on a small number of engagements at a time. This doesn’t need to be manufactured — it just needs to be stated. “I work with two teams per quarter” or “next availability is [month]” is honest and effective.

Urgency is trickier. The AI tooling landscape moves fast, which creates genuine urgency (teams that wait 6 months will face a different and potentially harder integration landscape). But “the ecosystem is moving fast” is a weak urgency claim because the buyer has heard it before. Better urgency comes from specifics: “Claude Code 4.0 just shipped MCP streaming, and teams that integrate it now have a 6-month head start on their competitors.”

Status: Real scarcity exists naturally. Next step: find ways to communicate it honestly without it sounding like a sales tactic.

9. The Virtuous Cycle of pricing

This concept ties together several chapters: charge more, deliver more value per client, get better results, use those results as proof to charge more. It’s the opposite of the race to the bottom.

I’m at the very beginning of this cycle. My open-source work and blog posts establish credibility. My first few consulting engagements will establish results. Those results become case studies (like the ShopForge and ShopSmith case studies I’ve already published for my own projects). Those case studies justify higher prices. Higher prices fund deeper engagements. Deeper engagements produce better case studies.

The risk Hormozi warns about: if you start too low, the cycle never spins up because you’re too busy serving low-paying clients to invest in the quality that would justify higher prices. Starting at a premium price — even before you feel “ready” — is the leverage point.

Status: Cycle hasn’t started. Next step: this depends on setting the right initial price point (#3) and landing the first packaged engagement (#1).

10. The “commodity” trap

A short chapter but an important one. Hormozi’s test: if a prospect can compare your offer to another provider’s offer on a feature-by-feature basis, you’re a commodity. The fix is differentiation through bundling, naming, guarantees, and bonuses — everything above.

Right now, someone could compare “Bryce Watson, MCP consultant” to any other consultant who claims MCP expertise. They’d compare hourly rates and pick the cheaper one. But if the offer is a named package with a specific outcome, timeline, guarantee, and bonus stack, there’s nothing to compare it to. That’s the entire point of this exercise.

Status: Currently a commodity by this definition. Everything above is the fix.

The plan, sequenced

Phase 1: Design the offer (now)

Phase 2: Price and position

Phase 3: Iterate

Phase 1 can start immediately. It depends on the Delivery Cube exercise and decisions about packaging, not on any external infrastructure. This is different from the Leads plan, where the email platform was a hard blocker. Here, the blocker is clarity about what I’m actually selling.

The single most important shift: stop thinking in terms of “I offer consulting” and start thinking in terms of “I sell a specific transformation with a name, a timeline, a guarantee, and a price.”