PayPaw — financing
Money and financing decisions live outside ZibiWorks. Payment state must reconcile with orders.
Meet ZibiWorks
A field guide to ZibiWorks, the fictional company the whole series follows. Skim it in a few minutes, and come back to it whenever a later decision refers to “the business.”
ZibiWorks designs, manufactures, sells, connects, and services robotic companion animals. It grew from a scrappy startup into an established business, and its software grew along with it.
How it got here
Section titled “How it got here”The launch went well, growth was fast, and capabilities piled up faster than architectural discipline. ZibiWorks isn’t in crisis. The company it is today is simply not the company its software was built for.
timeline
title The ZibiWorks growth story
Startup : One product : One app, one database, one team
Traction : Launch exceeds expectations : Sales climb
Expansion : Retail partners : More device models : Connected features
Today : Established business : Large platform : Pressure building
What makes a Zibi unusual
Section titled “What makes a Zibi unusual”A Zibi is three things at once: a manufactured physical product, a connected device, and a personalized experience. A lot of the architectural difficulty later comes from those three identities sharing one platform.
flowchart TB
P["Physical Product<br/>manufactured, boxed, shipped"]
D["Connected Device<br/>telemetry, firmware, connectivity"]
E["Personalized Experience<br/>personality, behavior, voice"]
C(["A Zibi"])
P --> C
D --> C
E --> C
Business Domains and Capabilities
Section titled “Business Domains and Capabilities”These are the major areas of business responsibility ZibiWorks operates in today. A domain is a broad area of the business, and each domain contains more specific capabilities: the work performed within it. Neither concept says anything yet about how the software should be divided.
Because ZibiWorks builds a physical product, Manufacturing & Supply Chain is part of the business domain map alongside commerce and Zibi-specific responsibilities.
Commerce
- Product & Catalog
- Pricing & Promotions
- Customer & Household
- Order Management
- Payments & Billing
Physical Operations
- Manufacturing & Supply Chain
- Inventory & Fulfillment
- Shipping & Returns
Zibi-Specific
- Zibi Lifecycle
- Zibi Experience
- Zibi Operations
The Zibi-specific domains are a good example of capabilities sitting inside a broader domain. Each domain below holds the more specific work it is responsible for:
Zibi Lifecycle
ConnectivityFirmware
Zibi Experience
Zibi BrainZibi VoiceZibi MobilityZibi Personality
Zibi Operations
TelemetryZibi HealthDiagnostics
Business Domains ≠ Software Services
Section titled “Business Domains ≠ Software Services”A partner ecosystem
Section titled “A partner ecosystem”ZibiWorks does not operate alone. These five representative partners each show a different kind of relationship, and each kind creates a different integration pressure. More partners appear later, when a specific installment needs them.
flowchart LR
CW(["ZibiWorks"])
PayPaw["PayPaw"]
HWC["Handle With Care"]
PawCircuit["Paw & Circuit"]
RoboMotion["RoboMotion Systems"]
HomeSphere["HomeSphere"]
CW --- PayPaw
CW --- HWC
CW --- PawCircuit
CW --- RoboMotion
CW --- HomeSphere
Handle With Care — specialized logistics
A specialist carrier for fragile robots, with its own handling and tracking rules rather than commodity shipping.
Paw & Circuit — retail channel
A large retailer with its own systems. Catalog, inventory, and orders sync over decidedly un-modern protocols.
RoboMotion Systems — supplier
Supplies mobility hardware. Brings purchase orders, shipping notices, and quality signals into the supply chain.
HomeSphere — external ecosystem
The smart-home platform Zibis plug into. Authorization, scopes, and rate limits ZibiWorks does not control.
How the teams are organized
Section titled “How the teams are organized”The domain map describes the business, but it does not describe how ZibiWorks’ teams are organized today.
Teams and ownership at ZibiWorks grew around features and historical projects rather than around business domains. Some capabilities span several teams. Some ownership still follows the shape of the old code. The result mostly works, and it does not cleanly match the domain map above. The point here is only to record that these seams exist.
What’s driving change
Section titled “What’s driving change”There is no single emergency. Several pressures are building at once.
Slower delivery
Many teams in one codebase; risky deployments; slow test suites.
Entangled capabilities
Business areas that should move independently are coupled together.
A growing fleet
More connected Zibis means more telemetry, firmware, and operational load.
Multiplying integrations
Every new partner and channel is one more external relationship to keep working.
Reporting on top of operations
Analytics lean on the systems that run the business, and the two are in tension.
Where it might go next
Section titled “Where it might go next”Possible future directions, and not a roadmap. These are places pressure could lead. None of them is guaranteed. If one does emerge, it will arrive as new architectural pressure, not as a plan decided in advance.
Today
- Current business domains
→
pressure may lead to
(not a roadmap)
Possible horizon
- Zibi Fleet Management
- Partner Platform
- AI & Behavioral Intelligence
- Device Platform Services
- Subscription & SaaS Management
Next: what did they actually build?
Section titled “Next: what did they actually build?”This was the business. The obvious next question:
What did ZibiWorks actually build to support all of this?
The Starting Point →The system ZibiWorks actually built to run this business. It is the starting point every later decision responds to.