The Core ecosystem
Prototype in days. Harden once. Reuse with control.
The cost of producing software has fallen. The work required to trust it has not. Core Purpose Tech keeps the parts that should be solved once—delivery controls, identity boundaries, shared utilities, and maintenance discipline—while each product remains responsible for the domain it serves.
Shared foundations
04
Independent products
03+
Operating model
Harden once
Platform ensures stability. Identity isolates tenant boundaries. Utilities handle transport. Bug Buster automates triage.
The changed economics
Two days can prove the idea. They cannot prove the operation.
AI-assisted development has made a realistic prototype faster and cheaper. That brings user testing forward. It does not make identity, failure behaviour, deployment, recovery, or ownership disappear. Those are the parts a prototype was never built to answer.
A prototype can prove
- Whether the workflow makes sense to a real user
- The vocabulary people use for the work
- Which assumptions should change before the model hardens
Production must establish
- Identity, permissions, and data boundaries
- Failure behaviour, recovery, and observability
- Automated evidence for changes and deployments
- Clear ownership after the first release
The shortcut is preserving hardening work that can be reused safely.
System map
Shared foundations below. Domain ownership above.
Products adopt the capabilities they need. The line between the two layers is deliberate: common technical responsibilities may be shared; the rules of the organisation remain local.
Independent domain products
Domain product
Garage CRM
Rental operations shaped around enquiries, offers, reservations, assets, and the decisions that move each state.
Domain product
Grand Total
A separate operational platform that adopts the shared foundations without surrendering ownership of its own domain.
Selective adoption
Client systems
New and existing systems can adopt the capabilities they need as versioned dependencies rather than inheriting an all-or-nothing stack.
Shared foundations
Foundation 01
Core Platform
A governed starting point for software that has to keep working.
Read boundary ↓Foundation 02
Core Identity Hub
One stable identity boundary, without one permission model for everything.
Read boundary ↓Foundation 03
Core Utilities
Shared technical capabilities with policy and observation in one place.
Read boundary ↓Foundation 04
Bug Buster
A common path from reported problem to bounded, evidenced change.
Read boundary ↓Foundation 01
Core Platform
A governed starting point for software that has to keep working.
Core Platform carries the repeatable technical work behind a production system: backend conventions, automated builds, test gates, deployment patterns, observability, and security controls. A new product starts with those decisions made and visible instead of rediscovering them under launch pressure.
What belongs here
- Shared backend and service conventions
- Build, test, security, and deployment gates
- Operational telemetry and release evidence
The boundary
It does not own the client's domain model. Each product still proves its own business rules and failure cases.
Foundation 01
Read full architecture: Core Platform
Read articleFoundation 02
Core Identity Hub
One stable identity boundary, without one permission model for everything.
The hub separates applications from the identity provider selected by the organisation. Its provider boundary is designed for MitID, Microsoft, Google, and other identity providers, while giving each product a stable internal identity. Directory and lifecycle synchronisation remains a separate capability (supporting SCIM where available) and depends on the selected provider.
What belongs here
- Provider adapters and single sign-on
- A consistent identity presented to connected products
- User lifecycle and profile synchronisation boundaries (SCIM)
The boundary
Knowing who a person is does not decide what they may do. Roles, tenancy, and domain authority remain with the product that owns the decision.
Foundation 02
Read full architecture: Core Identity Hub
Read articleFoundation 03
Core Utilities
Shared technical capabilities with policy and observation in one place.
Embeddings, model access, OCR, transcription, and similar services recur across several domains. Core Utilities defines consistent interfaces and a common place for provider policy, metering, and operational signals without taking over the product's use case.
What belongs here
- LLM gateway and provider routing
- Embeddings, OCR, and transcription services
- Shared policy, metering, and operational visibility
The boundary
Prompts, retrieval choices, and business decisions stay in the product. A shared utility should not become a distant owner of application logic.
Foundation 03
Read full architecture: Core Utilities
Read articleFoundation 04
Bug Buster
A common path from reported problem to bounded, evidenced change.
A small product integration is the intended entry point to one triage and maintenance path. Bug Buster can work from reported defects, pull-request findings, and lint failures; it prepares bounded fixes where the evidence is clear and escalates risks introduced by the proposed change.
What belongs here
- Shared intake across reports and pull requests
- Lint correction and bounded preparation of fixes
- Escalation of regressions and newly introduced risk
The boundary
It does not make every reported issue safe to automate. Ambiguous, high-impact, or weakly tested changes stop for human investigation.
Foundation 04
Read full architecture: Bug Buster
Read articleHow improvement moves
Available everywhere is not the same as deployed everywhere.
A shared improvement still has to cross a product boundary deliberately. That distinction keeps reuse from becoming hidden coupling, and it gives each product a chance to prove that its own rules still hold.
- 01
Need found
A product exposes a need that recurs elsewhere: a provider adapter, a stronger build rule, or a common utility.
- 02
Boundary chosen
The reusable responsibility moves into the shared foundation. Product-specific behaviour stays with the domain product.
- 03
Evidence built
The change passes the foundation's own tests and release controls before any product is asked to adopt it.
- 04
Product verifies
A consuming product adopts the change deliberately as a versioned dependency and runs the tests that protect its local rules and users.
- 05
Ready for adoption
Other products can now adopt the improvement without repeating its design and hardening work.
Proof in different domains
Shared foundations must leave product rules intact.
Garage CRM and Grand Total are separate domain products, not demonstrations of a generic template. The cases below show the same boundary in other settings: common infrastructure underneath, explicit domain decisions above.
Core Utilities
Operating AI under your own control
The provider-neutral gateway pattern behind shared model access, routing, policy, and observation.
Explore caseDomain ownership
Operational AI inside a real workflow
A domain system remains responsible for the decision while shared AI infrastructure supports the work.
Explore caseCore Utilities
Secure retrieval from internal knowledge
Shared infrastructure and access boundaries applied to information that cannot be treated as public context.
Explore caseLimits
What the ecosystem does not remove
Reuse relocates work and responsibility. A weak shared boundary can now affect every product that depends on it.
- A shared foundation creates a dependency and therefore needs ownership, versioning, and a controlled rollout path.
- A shared defect can reach more than one product. Compatibility checks and staged adoption matter more, not less.
- Common pipelines establish a minimum; they do not replace the tests that protect each product's business rules.
- Single sign-on establishes identity. It does not make permissions interchangeable between products.
- AI can accelerate analysis, implementation, and maintenance. It does not remove review, traceability, or accountable release decisions.
From foundation to useful work
Start the next product with the common risks visible.
With recurring production responsibilities already visible, the first weeks can focus on the organisation's process and users without forcing every product into the same model.