Architecture
The patterns and boundaries the system follows, and where they apply.
How we work
From requirements to operation
Engineering work succeeds when decisions, delivery, and operational responsibility stay connected. We agree the outcome, the scope, and who owns each part of the work before implementation begins.
Define the work before committing to delivery
We establish the business objective, intended users, operating environment, existing dependencies, and constraints. Requirements include how the system will perform, be secured, and be maintained, as well as what it will do.
Where important questions remain unanswered, an initial definition and design phase can establish the basis for a delivery commitment.
In practice · Case study 04One authorization service for many applications, built in Rust with CasbinMake the engineering decisions explicit
We assess the options, document the architecture and major trade-offs, and identify integration risks. The design establishes the applicable standards, verification approach, and operational requirements.
In practice · Case study 09A pipeline engine that runs, pauses and resumes data workflowsBuild with visible progress
Delivery is organized around agreed milestones and acceptance criteria. Reviews show what has been completed, what has changed, and what needs a decision. Changes to scope, cost, or timing are discussed before they become commitments.
In practice · Case study 02A booking and operations platform for sports facility owners in the UAEVerify readiness for production
Readiness is assessed against the agreed requirements and release criteria. Depending on the system, this can include functional testing, integration checks, performance evaluation, security review, and verification in its intended environment.
Deployment, monitoring, recovery, and handover responsibilities are established before release.
In practice · Case study 01Building a test suite that makes releases predictable for a growing AI and data platformEstablish responsibility after launch
We agree who operates the system, how support and incidents are handled, and how future changes are prioritized. Continued operation and improvement can form part of the engagement or be handed over to your team through an agreed transition.
In practice · Case study 10Live run monitoring and cancellation across server instancesEvery change traces back to why
Each requirement links to the objective it serves, the design that answers it, the code that implements it and the tests that prove it. When something needs to change, we can see what it affects before it is changed.
- Objective
- Requirement
- Design
- Code
- Test
- Release
Standards agreed before we start
At the outset we agree the standards the work will meet. They are written down, applied throughout and checked at review.
Testing
What is tested at each level, and what must pass before a release.
Code review
Who reviews, against which checklist, before anything is merged.
Security
When security review is required, dependency and secret scanning, and sensitive areas.
Branching and release
Branch rules, protected branches and how changes reach production.
Documentation
What is documented as the work happens: interfaces, decisions and runbooks.
Deployment
Environments, migration review and when changes may be released.
Process depth
How formal requirements, design and approvals need to be for this system.
Process sized to the system
A prototype does not need the ceremony of a regulated system. We agree the depth at the start and adjust it as the work matures. Choose a level to see what changes.
- Suits
- Most business systems and products
- Requirements
- A requirements document with acceptance criteria and constraints
- Design
- An architecture overview and decision records
- Verification
- Code review, unit and integration tests, and a release checklist
- Your approvals
- Scope, design, milestones and release
Choose how responsibility is shared
Advisory
Your organization
Implementation and operation
CharCentric
Technical direction and review
Advisory
We provide technical direction and review. Your team owns implementation and operation.
Embedded
Your organization
Team context and shared coordination
CharCentric
Defined engineering remit within your team
Embedded
We work within your team with an agreed technical leadership or engineering remit. Responsibilities and decision authority are defined together.
Managed
Your organization
Agreed inputs and acceptance
CharCentric
Delivery responsibility for the agreed scope
Managed
We take delivery responsibility for an agreed scope, with explicit milestones, acceptance criteria, and operating boundaries.
Scope, decision authority, and operating responsibilities are agreed for each engagement.
Using AI with engineering accountability
We establish which tools may be used, which information they may access, and how their outputs will be reviewed. AI-assisted work follows the same engineering and acceptance requirements as other work.
Written task
Scope, limits and acceptance checks are written down first.
Separate workspace
AI works on its own branch with limited access.
Automated checks
Tests and verification run before anything is committed.
Engineer review
An engineer reviews the change like any other.
Merge
Only reviewed changes reach the main line.
Principles we agree with you and apply
- Which AI tools are used, and what information they may see, is agreed with you first.
- AI works on separate branches and does not change the main line directly.
- AI tools get the least access the task needs, and no access to secrets or production credentials.
- Changes pass automated checks before they are committed.
- An engineer reviews AI-assisted changes before they are merged.
- AI runs are logged, so what was done, and with what, can be traced.
Common questions
How formal will the process be?
As formal as the system needs. A prototype needs less ceremony than a regulated or hard-to-change system. We agree the depth at the start and can adjust it as the work matures.
How are changes to scope handled?
Changes are discussed before they become commitments. We explain the effect on cost, timing and risk, and nothing changes until you agree.
Can you work inside our existing team?
Yes. In the Embedded mode we work within your team under an agreed technical leadership or engineering remit. In the Managed mode we take delivery responsibility for an agreed scope.
Do you use AI on our project?
Only as agreed with you. We agree which tools may be used and what they may access, and AI-assisted work goes through the same reviews and acceptance as any other work.
What do we have at the end?
The working system, and the documentation, runbooks and access needed to operate and change it, whether we continue to operate it or hand it over to your team.
What happens after launch?
You can run the system yourselves, or we can operate it for you under an Operate retainer: monitoring, incident response, security and software updates, a monthly allowance of engineering hours for improvements, a monthly report and quarterly reviews. It runs for 12 months at one of three service levels, chosen by how critical the system is and how quickly urgent issues need a response. At renewal you can move operation to your own team, with a handover included. For a system we did not build, we start with a Technology Action Plan.
Discuss your initiative
Tell us what you need to build, improve, or operate. We can establish the next useful step together.