From Contract Work to Commercial License — bateson's Management Decisions and Phase Strategy

This article is written for executives and business owners responsible for management decisions, investment judgment, and sales funnel design around bateson—a booking engine. Engineering implementation details—adapter pattern, tenantId, headless UI—are in the sister pillar 「Designing a Booking Engine from Scratch — From Contract Work to Commercial License」. This article contains no code.

A contract-built codebase can be promoted to a commercial license. But you don’t need to “rebuild it from scratch as a general SaaS right away.” All that is needed is to embed 4 principles that keep the door open to commercialization as decisions at the Phase A stage.

3 key takeaways:

1. Contract work (delivering an artifact) and commercial licensing (providing usage rights) are not mutually exclusive. With the right Phase A decision, you can keep the path open to running both in parallel.
2. The 4 principles are not engineering conventions—they are structured management decisions. “Separate customer-specific implementations,” “make tenant separation implementable later,” “keep external vendors swappable,” “make brand elements injectable”—these are not design rules first; they are decisions that keep commercialization options open.
3. The key to differentiating from Cal.com / Calendly is not building a “single-function scheduling SaaS” but designing the booking tool as the entrance to the sales funnel.

bateson’s name comes from Gregory Bateson (ecologist and communication theorist). “The difference that makes a difference”—the booking tool doesn’t hold meaning on its own; it makes a difference in the context of the entire business. That is the design philosophy.

Why Promote a Booking Tool to a Proprietary Product — The Strategic Value of Contract Assets

The Management Value of Implementation Assets Accumulating as a Side-Product of Contract Work

Continuing contract development causes reusable implementation assets to accumulate in your own codebase—separate from the artifacts you deliver to clients. Code written to solve a specific client’s problem often turns out to apply to other clients as well. Booking flows, invoice generation, notification delivery, approval workflows—among functions repeatedly built under contract, many are fundamentally reusable.

Most organizations treat these assets as “reference implementations to reuse” and stop at using them again for the next project. That captures half the value.

The other option: grow these assets into commercial license products. A shift in business model from delivering artifacts to clients (their code) to continuously providing usage rights. Running contract work’s immediate revenue in parallel with commercial licensing’s mid-term asset building becomes a growth path.

bateson is what makes this decision process visible, using the booking engine in src/lib/bateson/ as a concrete example. “We started by building a booking tool just for Yakumo’s use,” and implemented it with a structure that doesn’t close off future commercialization options.

Mid-Term ROI Comparison: Leaving the Side-Product Alone vs. Developing It for Commercialization

Comparing the mid-term ROI of this choice. Because concrete numbers (implementation effort, projected license revenue) vary greatly by business scale, client count, and organizational capacity, we present a qualitative comparison.

ROI of leaving it alone (reuse as reference implementation):

• Short-term benefit: Faster implementation for the next project
• Mid-term downside: Slightly different implementations for each client proliferate, and maintenance costs accumulate
• Scale characteristic: Depends on human effort, so costs grow linearly with the number of contract projects

ROI of commercializing (license product):

• Short-term downside: Investment in design discipline at Phase A (strict application of the 4 principles described later)
• Mid-term benefit: License revenue accumulates, assets separated from contract work
• Scale characteristic: Even as client count increases, engine costs don’t change (non-linear)

Which is right depends on business phase and organizational capacity. But “keeping the option open at the Phase A design stage” is achievable at small cost relative to what it buys in mid-term optionality. Whether the door is open when you later decide to explore commercialization depends solely on Phase A design decisions.

Brand Strategy Significance of an AI Agent Development Organization Building a Booking Tool

Why does an “AI agent development organization” build a booking tool? This might seem odd.

The answer is in brand strategy. Yakumo is an organization centered on AI agent development. What clients expect is “the experience of an organization that actually runs AI at the core of its business coming in to improve our operations.”

bateson functions as a demo proving that experience. The booking engine itself is developed and operated AI-driven, and when clients make an inquiry through bateson, they are already touching a product from an AI agent development organization. It becomes proof that “we don’t just talk about it—we build it and run it.”

Contract vs. Product — A Mid-Term Business Strategy Beyond the Either/Or

The Structural Difference Between Contract Work and Commercial Licensing

Organizing the structural differences between the two business models:

Contract work’s greatest strength is immediate revenue and client learning. Deep understanding of client business challenges through projects accumulates knowledge that feeds into the next proposal. Commercial licensing’s greatest strength is scalability and asset building. A product built once scales with more clients at low marginal cost.

“Which is better” is a meaningless question. The optimal allocation changes by business phase and organizational capacity.

Advantages and Traps of Running Both in Parallel

Running contract work and commercial licensing in parallel has synergies and common pitfalls.

Synergies:

• Contract projects become dogfooding (self-use) environments for the commercial license product
• Commercial product track record becomes proposal material for contract work
• Client feedback from contract work feeds directly into commercial product improvement
• Contract revenue self-funds investment in product development

Common traps:

Trap 1: “Earning from contracts meanwhile” becomes the subtext, and product investment stays perpetually deferred. Contract work has immediately visible cash flow; commercial licensing is a mid-term investment. Continuously choosing “focus on current contracts” means the Phase B-D decision day never comes.

Trap 2: Customer-specific contract requirements keep getting incorporated into product code, filling the product with special-case implementations. Every time a client says “please do it this way,” making changes to core means everything becomes a liability when multi-tenanting at Phase B.

Trap 3: “Running both” looks like “neither done right.” The question “are you a services company or a product company?” will always come from investors, recruits, and partners. Having a clear answer to this keeps organizational decision-making consistent.

The Rationale for Phase Strategy: Earning from Contracts While Preparing for Product

The rationale for Phase strategy when running both in parallel is the structure: “Phase A design investment is the only way to keep the door open to Phase B-D.”

How you designed at Phase A determines the breadth of options afterward. When the Phase B multi-tenanting decision arrives, that difference appears as management cost. An implementation honoring the 4 principles can transition to Phase B in days from decision to implementation; an implementation not honoring them can’t even estimate the Phase B investment.

The Phase A decision is not “a decision to build the current product”—it is “a decision to preserve future options.” Whether this is clearly held as a management decision is the fork in the road for organizations running contract work and product in parallel.

Phase A → D Management Decisions — A Guide for Staged Investment

Full Picture of Phase Definitions and Management Decisions

Organizing the 4 stages of bateson and their management decisions:

Phase A: Investment Decision and Short-Term ROI

The Phase A decision is the smallest investment: “implement the booking engine as a side-product of a contract project.” Build the booking tool your own /contact flow needs, with a design that keeps commercialization options open.

The short-term ROI is “improving Yakumo’s own order flow.” Freed from pasting Google Calendar links and manual scheduling emails, the flow from inquiry → booking → upfront information gathering is automated. This is value recoverable from Phase A alone, as an improvement to contract project order efficiency.

The additional investment to honor the 4 principles is limited relative to the overall Phase A contract cost. The functional outcome doesn’t change. What changes is the structure of “where customer-specific requirements are housed”—the deliverable to clients is the same, and what changes is the extension room inside.

Phase B: The Multi-Tenanting Trigger

The trigger for the Phase B decision is “the second external client.” More precisely: when the number of clients for whom the Phase B investment pays back becomes visible.

Phase B completes tenant separation across all APIs and allows multiple clients to run on a single engine. Recovering this investment requires some level of license-providing clients. The risk-minimizing judgment is to confirm “are there prospects for multiple external clients before moving to Phase B” before proceeding.

Put the other way: if Phase A’s 4 principles are honored, the state of “being able to move immediately when we decide to proceed to Phase B” is maintained. Whether the door is open depends on Phase A design.

Phase C / D: ROI Decision Axes for Repository Extraction and Commercialization

Phase C (repository extraction) and Phase D (commercialization) involve larger management decisions.

Phase C is the decision to “recognize the engine as a separate business.” Technically it’s work to remove dependencies on corporate-site and make the engine independent, but the management meaning is “creating the starting point of the product business.”

Phase D requires billing model, target market, sales strategy, and support structure. Whether to operate as SaaS, release as OSS and monetize through services, or use a closed license—these strategic decisions can be deferred through Phase A-C. Lock them in after gaining hands-on feel through dogfooding.

There is absolutely no need to finalize Phase D strategy at Phase A. All that Phase A needs is “design decisions that don’t close off Phase D options”—and those are already implemented as the 4 principles.

The 4 Principles That Keep the Door to Commercialization Open (Read from a Management Perspective)

The 4 principles are engineering conventions, but behind them are management decisions. Engineering implementation detail is delegated to sister tech pillar. Here we organize what each principle protects as a judgment.

Principle 1: Structural Separation of Customer-Specific Implementation

Management meaning: Keep “that customer’s specific requirements” from contract work from directly contaminating the product core.

Doing contract work produces various special requests from clients. “Our company needs at least 2 people in every meeting,” “please change the confirmation email subject format,” “please make the cancellation deadline 5pm the day before”—incorporating these directly into core produces accumulated special implementations that can’t be used with a different client.

Principle 1 “keeps the structure that doesn’t pollute core” so that both flexible response to contract requirements and product generality are maintained simultaneously.

Principle 2: Keeping Tenant Separation Post-Implementable

Management meaning: Preserve the freedom to execute Phase B (multi-tenanting) at the timing of a management decision.

Build in the prerequisite for multi-tenanting—a mechanism to identify “which client’s data this is”—into the design. At Phase A, it’s fine for all clients to run on the same “Yakumo tenant.” What matters is ensuring there is a place for a client identifier in the engine’s calling interface, so that Phase B doesn’t require rewriting every function.

Whether to pay this cost at Phase A or not directly affects mid-term optionality.

Principle 3: External Vendor Replaceability

Management meaning: Avoid vendor lock-in and maintain the flexibility to adapt to commercial deployment clients’ requirements.

External systems the booking engine depends on—calendar (Google / Outlook), email (Gmail / SendGrid / Resend), storage (Sheets / Postgres / DynamoDB), scheduler—may differ by client.

“Yakumo uses Google Workspace, so we depend directly on Google Calendar” means deploying to a client using a different calendar requires a full rewrite. Principle 3 abstracts external dependencies behind interfaces so that different implementations can be added later.

In design terms it’s called an “adapter” pattern for making external dependencies swappable, but the management meaning is “flexibility to adapt to clients’ existing systems.”

Principle 4: Brand Element Replaceability

Management meaning: Minimize the cost of brand adaptation by being able to change confirmation email copy, notification text, logos, and colors per client.

In contract work, it’s natural for a client’s brand name, logo, and specific text to be in confirmation emails. Embedding these directly in core means modifying core every time a different client needs serving.

Making templates injectable separates “the engine’s skeleton” from “the client’s brand elements.” When deploying to a different tenant at Phase D, only the templates need to be swapped.

A Booking Tool Built by an AI Agent Development Organization — Strategy for Positioning It as a Funnel

The Management Decision to Build In-House with Cal.com / Calendly on the Market

The booking SaaS market has plenty of options. Cal.com (OSS / full REST API), Calendly (commercial SaaS), TimeRex, Spir—including Japanese-language options, there are sufficient alternatives.

So why build in-house?

Not because of feature gaps. Existing SaaS covers almost everything functionally. The difference is “whether it can be integrated into the sales funnel.”

A neutral SaaS like Cal.com is dedicated to the booking function. Post-booking client experience—what materials to auto-send, how to connect to post-booking operational flows, what follow-up to run using booking data—is outside the SaaS’s responsibility.

Cal.com and Calendly are the best choice for organizations that want to focus on “just the booking workflow.” We have no intent to deny in-house development. Yakumo chose to build in-house because we wanted to implement the intent of the sales funnel design.

The Funnel Design: Booking Tool Introduction → Operations Improvement → AI Agent Development Order

The sales funnel bateson aims to enable is three stages:

Step 1: Contact as a booking tool Clients encounter bateson as “an alternative to Cal.com / Calendly.” They use it from our /contact for inquiry bookings and introduce it with the goal of improving operational processes. At this stage, it’s recognized as a “booking tool.”

Step 2: Operational visibility As booking data accumulates, you can see “what kinds of inquiries come in,” “what clients want what,” and “how much human effort goes into post-booking follow-up.” bateson doesn’t just provide booking functionality—it can connect this information to your own business flow.

Step 3: Connection to AI agent development orders This leads to proposals that “this business flow can be agent-ified.” Organizations that have adopted the booking tool are already “in a system designed by an AI agent development organization.” The context for making AI agent development proposals is at a completely different temperature.

For this sequence to work, booking data needs to be connected to your own business flow. A neutral SaaS cannot make this connection. This funnel design is only possible with an in-house build.

The Essence of Differentiation Is the Destination of Data

The essence of differentiation is not a feature list—it is where data connects.

bateson, at booking confirmation, processes in one shot: recording to Google Sheets, auto-sending a confirmation email, auto-selecting materials, and scheduling reminder registration. All this data exists within your own business flow and can be leveraged as proposal material for AI agent development.

A SaaS like Cal.com holds booking data within the SaaS. Data can be retrieved via API, but it’s different from data “natively connected” to your own business flow.

The cost of building both engines in-house is higher than using a combination of general-purpose SaaS. But the fact that “an AI agent development organization designs its own business flow with AI” is itself persuasive to clients.

mcluhan and bateson — Building a Sales Funnel with 2 Engines (Business Perspective)

Role Division of the 2 Engines

Yakumo combines two engines to constitute a sales funnel.

mcluhan (owned media operations engine) handles customer acquisition. Technical and case articles Yakumo writes generate search and social inflow, creating contact with potential clients. mcluhan is the engine automating the writing, quality control, publication scheduling, and article quality audit of those articles.

bateson (Booking Engine) handles order acquisition. When a client attracted by mcluhan wants to “make an inquiry,” bateson’s booking flow receives them. From booking confirmation to follow-up as a lead with elevated order probability, bateson constitutes the order process.

What the 2-engine parallel operation is trying to achieve: “an organizational model where AI agents handle everything from customer acquisition to order acquisition in one integrated flow.”

Business Meaning of 2-Engine Parallel Operation

Why build 2 engines separately? Wouldn’t 1 CMS + 1 booking SaaS be enough?

The answer to this is “degree of adaptation to your own business context.”

A general-purpose CMS (WordPress / Contentful) and general-purpose booking SaaS combination provide their respective functions independently. “Writing articles” and “receiving bookings” are disconnected.

When mcluhan and bateson operate together, the information encountered in articles, the context of which articles the client read, and the service interest areas they entered in the contact form—all connected as a booking comes in. Sales staff can go into the meeting already knowing the client’s interests.

The cost of building both engines in-house is higher than combining general-purpose SaaS. But the fact that “an AI agent development organization designs its own business flow with AI” is itself proof of capability to clients.

Full Order Process Picture and the 2 Engines’ Responsibility Boundaries

If you are reading this article now, you are reading the output of owned media managed by mcluhan. And if you make an inquiry from the contact form below this article or at /contact, you enter the booking flow managed by bateson. The 2-engine linkage is a structure you can experience at this very moment, reading this article.

Axes for Deciding Between Commercialization and Continuing Contract Work — Design as Mid-Term Business Strategy

Honestly Evaluating the Option to Continue Contract Work

In contexts discussing commercialization, contract work tends to be treated as a lower-tier option—but that is wrong. Contract work has strengths that commercial licensing doesn’t.

Benefits of continuing contract work:

• Immediate revenue, certain cash flow
• Deep domain knowledge accumulated through deep client engagement
• Market validation done at clients’ project cost
• Ability to avoid risk before PMF (Product-Market Fit) is proven

Drawbacks of continuing contract work:

• Scale is limited because it depends on human effort
• Revenue goes to zero if clients leave
• Client requirements pull your organization and building your own technical assets gets deferred

There are rational reasons to choose contract work. “Not at the PMF stage yet,” “can’t see the client count for commercial deployment,” “can’t make mid-term investments due to insufficient capital”—all of these are legitimate decisions.

Axes for Deciding to Commercialize

Organizing criteria for the decision to proceed with commercialization (Phase B onward):

Prerequisites (questions to confirm before Phase B):

1. Are Phase A’s 4 principles honored? (Is the technical door open?)
2. Is there a prospect of second and subsequent external clients?
3. Can you sketch a timeframe / revenue scenario for recovering the multi-tenanting investment?
4. Is there an organizational structure that can take responsibility for the product business?

Decision axes:

• “There is a function you repeatedly build under contract, and there are other clients who would want a general version” → Start exploring commercialization
• “The value source is complex customization only achievable under contract” → Continuing contract work is rational
• “Similar products exist in the market, but there is differentiation from functions specialized for your own use case” → Niche commercialization is possible

Organizational Design When Running Both in Parallel

If you choose parallel operation, the most important organizational design question is to clarify “who the product decision-maker is.”

When contract and product businesses coexist within an organization, priority conflicts arise. “An urgent contract project came in so product development stopped” is the most common dysfunction in parallel organizations.

Solutions vary by organizational scale and phase, but the minimum needed is “a mechanism to protect the time investment in product.” How many hours per week to dedicate to product development, who makes the decision when Phase B trigger arrives—deciding these in advance is the condition for parallel operation to function.

Summary — A Guide to Management Decisions for Commercializing Contract Assets

Contract Asset → Commercial License: All Comes Down to Phase A Decisions

Summarizing what has been emphasized throughout this article at the end.

The decision to promote contract assets to commercial licenses only exists at Phase A design time. Whether to proceed through Phase B-D is a subsequent management decision, but whether the option to proceed is preserved depends on Phase A design.

Phase A’s 4 principles—separation of customer-specific implementation / post-implementability of tenant separation / external vendor replaceability / brand element replaceability—preserve greatly expanded mid-term optionality with only a very slight increase in Phase A implementation cost.

The 4 Principles Are Structured Management Decisions

Reading the 4 principles purely as “good engineering design” makes them less meaningful to management. Re-reading them through a management lens:

• Principle 1 (separation of customer-specific implementation) = “Respond flexibly to contract requirements while maintaining core generality”
• Principle 2 (post-implementability of tenant separation) = “Preserve freedom in timing the Phase B management decision”
• Principle 3 (external vendor swapping) = “Maintain commercial deployment flexibility to adapt to clients’ existing infrastructure”
• Principle 4 (brand element replacement) = “Minimize the cost of per-client brand adaptation”

These are not technical constraints—they are design policies that preserve business options. When the engineering team needs to explain “why we need to honor these” to management, the above re-readings are useful.

The Differentiation of a Parallel Funnel Built by an AI Agent Development Organization

mcluhan (owned media) × bateson (booking) 2-engine parallel operation functions as proof that “rather than just talking about AI agent development, Yakumo designs its own order process with AI agents.”

When a client makes an inquiry from bateson’s booking form, they are already inside “a system designed by an AI agent development organization.” This embodies the stance of “speaking with implementation, not just words.”

bateson’s Phase B-D Roadmap and Publication Timing

As of May 2026, bateson has progressed to what is equivalent to Phase A complete. Phase B (multi-tenanting) will be decided based on feedback from external clients.

For how the 4 principles are implemented in code—adapter type definitions, tenant identifier design, dependency injection structure for core logic—the sister tech pillar 「Designing a Booking Engine from Scratch — From Contract Work to Commercial License」 provides detailed coverage.

Inquire about this topic: For consultation about bateson’s design decisions or commercialization of contract assets, please book via Yakumo’s /contact. The inquiry is handled through the booking flow managed by bateson. Reading Yakumo’s owned media, then inquiring via bateson—you are experiencing the 2-engine sales funnel in real time.

This article is written within the owned media pipeline Yakumo operates, with AI agent assistance. The self-referential structure—building the article-writing system (mcluhan) and the booking-receiving system (bateson) in-house and operating the business with them—is what underpins Yakumo’s differentiation.

Sister tech pillar: bateson adapter / tenantId design in detail (tech cluster) Related: Structural design of mcluhan owned media engine / How we pulled an AI-generated blog in 5 days