01 / THE PREMISE
The business is familiar.
The software can be simpler.
Companies differ. But the fundamentals of serving a customer repeat: define a product, take an order, deliver a service, send a bill and resolve a problem. The belief behind Tolsbuilds is that we should stop treating every one of those foundations as a unique invention.
Start with focused capabilities and explicit connections. Make them quick to deploy, easy to replace and understandable enough that one person can follow what is happening. The dream is a telco operated from a Mac through straightforward tools.
This experiment concentrates on the business support layer. Network activation stays behind a separate provisioning boundary, with a simulator planned for the fictional operator.
02 / THE ARCHITECTURE
Own the data.
Connect the capabilities.
Each domain owns its records and business rules. Customer references connect the first CRM, case and order journey; a screen in one application does not make it the owner of another application’s data.
First integrated prototypes
The source documentation identifies the integrations. The inventory is a code review, not a new live test of the server.
Target design · connectors to be built
The entry point changes. Domain ownership and business execution remain in the systems. The dedicated MCP connectors are future work.
Look inside the domain boundaries
| Domain | What it owns | Keep the boundary clear |
|---|---|---|
| Customer CRM | Customers and customer product instances | Product definitions belong in the catalog. |
| Product Catalog | Product definitions, SKUs and specifications | Commercial pricing and offers are not yet modeled. |
| Order Capture | Sales workspace, orders and snapshots | Order records remain separate from CRM customer records. |
| CaseMax | Cases, interactions, audit and time | Local customer IDs and snapshots map to the CRM master. |
| Permission Management | Customer consent, terms and agreement receipts | CRM and order adapters are still to be completed. |
| Identity & access | Identity references and application access | User Registry is not SSO. Employee roles are separate from customer consent. |
| Content & delivery | TolsCMS: pages and versions. TolsBuilder: local release operations. | The CMS owns content. It does not own products, prices or orders. |
The documented data stores are PostgreSQL for the business applications and SQLite for TolsCMS and the local TolsBuilder tool. A private read adapter currently reads registry and order data; it is a read-only bridge, not a shared owner of the data.
CRM and catalog REST interfaces are mainly read-oriented today; changes run through interface actions. Replacing those interfaces will also require explicit write operations and identity contracts.
CaseMax has its own event ledger and transactional outbox. A suite-wide event transport and the future communication flows remain separate work. A case event history is not the same as a delivered platform event bus.
03 / DEPLOYMENT & SCALE
Small releases.
A clear way forward — and back.
The delivery goal is a repeatable path: choose a version, check it, deploy it, confirm it is healthy and know how to roll it back. TolsBuilder is the local Mac prototype for making that work understandable through SSH and familiar controls.
Independent deployments let one capability change without replacing the entire landscape. Clear boundaries also give us a place to scale a workload when it needs more capacity.
The current demo shares a server. Load testing, horizontal scaling and failure recovery still need engineering and proof. TolsBuilder’s first adapter targets CaseMax 5.x; it does not yet deploy the whole suite.
04 / AI & MCP
The goal is to make these
interfaces unnecessary.
AI helps build the software now. The larger ambition is for AI to operate it: understand an outcome, find the relevant capabilities and coordinate the work through a set of MCP connectors.
Model Context Protocol (MCP) gives AI applications a standard way to connect to external tools and data. Here, the plan is to expose meaningful business operations and release tools through that connection.
BUSINESS OPERATIONS“Find the customer, explain the order and prepare the next action.”
BUILD & DELIVERY“Prepare the next release, run its checks and deploy it.”
UNDERSTAND & OPERATE“Show me what changed and why this flow stopped.”
Illustrative target workflows. These are not connected commands or a live AI demo.
The connectors should call explicit service operations. The systems retain the facts, permissions, rules and audit history. AI becomes a way to work across them, instead of another place where business logic quietly accumulates.
When the same capabilities can be built, composed and operated this way, a separate interface for every task becomes optional. That is the real destination of the project.
05 / A BUSINESS TO BUILD AROUND
ByteMe makes it concrete.
ByteMe is the fictional broadband operator used to bring the journey together. The plan is a living demo with synthetic customers, products, orders and service events — eventually extending through usage, bill cycles, communication and selfcare.
Tolsbuilds explains the work. ByteMe will demonstrate the business using it. The shared /byteme entry, customer website and provisioning simulator are planned; real customers, payments and network activation are outside this demo.
06 / WHERE IT STANDS
An experiment in progress.
- Available prototypesCustomer CRM, CaseMax and Order Capture have deployed entry points.
- Being builtProduct Catalog, customer permissions, employee access, content tools and the local deployment tool are at different stages.
- The directionDedicated MCP connectors, common sign-in, event-driven communication, billing and the broader ByteMe journey.
Implementation, deployment and a verified end-to-end flow are different milestones. The application directory keeps those stages visible.
Explore the applications