COMMERCIAL ENGAGEMENTS
Batisha Labs structures custom business systems, automation and AI work around the operating problem, the system boundary and the outcome the business needs. Scope comes before price so the proposal can make the work, responsibilities, costs and handover explicit.
FROM PROBLEM TO ENGAGEMENT
Start with the operating problem. Review fit and context, define the system boundary, then agree on the scope and commercial proposal before implementation.
Architecture, implementation, configuration, integration, testing, documentation and handover are included only where the approved scope says they are. Implementation follows approval and any agreed payment gate.
See the delivery methodENGAGEMENT SHAPES
These are general engagement shapes—not fixed products, packages, plans or pricing tiers. The appropriate shape follows the operating problem and actual scope.
The correct system boundary is not yet clear.
Understand enough of the workflow or system to define a responsible next step.
MAY INCLUDE
May stand alone. Implementation is not automatically assumed.
The problem can be bounded to a clear workflow or system.
Implement a defined outcome inside an explicit boundary.
MAY INCLUDE
A defined operating problem, with an explicit work boundary.
Multiple systems, workflows or authority boundaries interact.
Coordinate a broader connected implementation while keeping complexity, dependencies and governance visible.
MAY INCLUDE
Broader coordination across connected system boundaries.
SCOPE + PRICE
Custom engagements are scoped against the operating problem, system boundary, implementation work, testing and handover requirements.
How many operating paths must be understood or changed?
What platforms interact, and how reliable are those connections?
What information moves, where does it live and what condition is it in?
Who controls the relevant systems, accounts, environments and decisions?
What logic, models, exceptions and human approval gates are required?
What happens if the system is wrong, delayed, unavailable or over-authorized?
What evidence, environments and release conditions are required?
What must the client receive and understand at transfer?
Actual price and payment terms are set in the commercial proposal after the required scope is understood.
COMMERCIAL CLARITY
A clear proposal does more than state a price. It makes the approved work, dependencies, cost responsibilities, payment structure and handover conditions visible before implementation.
01 / DEFINED BOUNDARY
Approved scope and deliverables define the professional work: architecture, implementation, configuration, integration, testing, documentation and handover only where included.
02 / SEPARATE COST CATEGORY
Third-party technology costs may include software subscriptions, hosting, AI/model usage, APIs, messaging, CRM, automation platforms and storage. Responsibility for these costs is made explicit.
03 / PROJECT-SPECIFIC TERMS
Professional fees, price and payment schedule are set in the commercial proposal after the required scope is understood. Payments follow the agreed commercial structure.
04 / VISIBLE DEPENDENCIES
Assumptions, exclusions, ownership, responsibilities and known dependencies make the engagement boundary visible before implementation.
05 / AGREED REVIEW METHOD
The proposal makes the project-specific acceptance method and testing expectations explicit where applicable.
06 / DEFINED TRANSFER
Handover conditions and the included material define what the client receives and understands at transfer.
Third-party technology is a separate cost category unless the proposal explicitly states otherwise.
Payment methods and any initial payment are confirmed in the applicable proposal or invoice. Where an initial payment is required, implementation begins after it is received.
SHARED CLARITY
Batisha Labs can start from an imperfect current state. The engagement still needs enough business context and decision access to define what should actually be built.
MAKE THE WORK BOUNDARY VISIBLE
CONTEXT + ACCESS + DECISIONS
Client-owned systems and accounts are preferred where practical. Handover contents depend on approved scope.
CHANGE + UNKNOWNS
Custom work may reveal dependencies not visible during initial scoping. A changed operating problem, new system, integration, deliverable, requirement, risk or material assumption can change the approved work.
Batisha Labs makes the impact visible before additional work is treated as included.
DEFINE THE END STATE
The scoped implementation work has been performed.
The agreed checks have been run.
The applicable project-specific review / acceptance method has been satisfied.
The agreed in-scope material has been transferred or made available.
Where applicable: configuration, documentation, system maps, workflow logic, operating instructions, source material, code where included and known dependencies.
OPTIONAL CONTINUITY
Only where a separate support / continuity arrangement exists. Some engagements end at handover; others may justify separately scoped support, monitoring, improvement or extension.
SEPARATE RELEASE STATE
Public release or deployment is a separate state. Acceptance does not mean the system has been publicly released.
START WITH THE OPERATION
You do not need to know which Batisha Labs service category applies. Describe what happens today, what is not working, which systems or people are involved and what the business needs to improve.
