How we work, and what makes a client relationship hold over years
We document our internal standards, how we run engagements, and what both sides need for a partnership to work. Our engagements with Forbes 500 company in FMCG and Tesco in retail have run since 2008, and with Credit Agricole Bank Polska in a regulated, audit heavy environment.
Trusted by global and local brands since 2008
Why the way a supplier works internally decides how an engagement goes
The key factors for a successful engagement are set before work begins. It depends on who is assigned, if their work is reviewed, and whether knowledge is shared or kept private. These details are often hidden, so people usually describe them with vague words instead of facts.
Many technical leaders know these problems well. When suppliers change, important knowledge is often lost and has to be rebuilt, sometimes after something goes wrong. Architecture can drift because no one is responsible for it over time. Strategy documents are delivered and filed away, while the system itself keeps changing on its own.
A partnership is a set of internal standards that happen to be visible from the client's side.
The standards we hold ourselves to, on client and internal work alike
We apply the same six conditions to every project, whoever the client is. A standard that changes under deadline pressure was never a standard.
REVIEW
Nothing ships unreviewed. Code review is mandatory, and the reviewer is recorded, not just the approval.
DONE
A definition of done, in writing. Tests, documentation, deployable, reviewed, including the evidence a regulated client will be asked to produce.
RECORD
Decisions outlive the people who made them. Architectural decisions are recorded with the reasoning behind them, in a form that survives an audit or a change of supplier.
SECURITY
Controls run continuously rather than before a release. Threat modeling, dependency and secrets scanning, and access reviews, with the evidence retained where your regulator or your own risk function expects it.
HIRING
The bar is set at recruitment. Senior engineers on client work, cleared for client environments where clearance is required.
CONTINUITY
When our people stay, their knowledge stays. Fortune 500 company and Tesco have been clients since 2008, and the systems from the Credit Agricole work are still running today. Multi-year ownership of an audited platform is only possible when the same engineers are still on it.
What clients can expect, and what we will not do
If commitments are only stated in positive terms, it is hard to hold anyone accountable.
Will not
Will
Disappear after delivery.
Hold named accountability for agreed systems, including those under audit or availability commitments.
Bill hours without owning outcomes.
Keep knowledge in the team and in writing.
Let documentation lapse into tribal knowledge.
Grow the relationship only as fast as trust earns it.
Compete with an internal team for the same ground.
Hand back cleanly, at any point, if it ends.
Treat maintenance as a side responsibility.
Operate what we build, not just design it.
What a partnership requires from both sides
The word partnership is used so often it has lost its meaning. In practice it means both sides carry responsibilities. A supplier who never asks you for anything is not a partner.
What we bring
What we need
A named team, not a pool of resources.
Someone on the client side who can make a decision.
Accountability for whether the system works, rather than for hours logged.
Access to business context, not only to tickets, including the constraints set by risk, compliance and procurement.
Knowledge written down instead of held in individual heads.
Information about a problem early rather than late.
Honest feedback, including when we think a request is a bad idea.
Willingness to accept that sometimes we will advise against building something.
Get a free consultation with our experts and CTO
Let's talk about current challenges and see where we can help.
How an engagement runs, from arrival to steady state
Five moments test a relationship: when the team arrives, when routines are set, when scope changes, when something breaks, and when the work ends. Each stage is a checkpoint for the client, not just another step in a project plan.
1
Week 1 to 2. Arrival
Access and security onboarding completed against your process rather than ours, an architecture walkthrough, and named contacts on both sides. First analysis comes from dependencies observed in production rather than taken from existing diagrams. Leaves behind: a written system assessment and the first low risk commits.
2
Week 3 to 4. First delivery
Findings are presented, including the uncomfortable ones, and priorities are agreed on risk rather than wish list order. The first delivery confirms cadence and the definition of done in writing, running through the change and approval path you already use rather than a parallel one. Leaves behind: a prioritised risk register, agreed working arrangements, running code.
3
The working rhythm
Written reporting covers done, next, blocked and current risks, on a cadence that fits your own governance cycle. We use your tools where they exist. Overlap hours and on call are agreed, and a named engineer handles the work rather than a ticket queue. At this point you have a supplier who manages themselves and does not need supervising.
4
When something goes wrong
A slipping deadline is raised when it becomes likely, not when it becomes certain. An incident gets a named responder and incident command, you are informed during rather than afterwards, and a postmortem follows in writing. Scope changes are priced and agreed before they are built. The incident record is produced in a form you can pass straight to your risk function. No surprises in an invoice or a steering meeting.
5
Handover, whenever it comes
Documentation, runbooks, decision records and known issues transferred within a few weeks, along with credentials, infrastructure and repository ownership, in a form a successor supplier or an auditor can use. A client who is free to leave at any point stays by choice. That is the intent.
Where an engagement can begin, from a single audit to full ownership
Every organization needs a different level of support, and we usually figure that out in one conversation. Support is a spectrum, not a menu. Most clients start with a project and expand as trust grows.
What the platform stack we operate actually includes
Regulations, security expectations and audit questions are not paperwork handled alongside the build. They are requirements, and they get built. That applies whether the obligation comes from your regulator, your own risk function, or a customer's vendor review.
What is asked for Access is restricted to authorised users, and someone can prove it was. What gets built
Least-privilege IAM
Role design
Privileged access
Segregation of duties
Joiner, mover, leaver process
Access recertification
What CODEWAVE is responsible for, and what stays with the client
Long-term engagements only work if they do not turn into hidden dependencies. We are clear about the line from the start rather than offering reassurances later.
Architecture
CODEWAVE holds Architecture stewardship. Stays with the client The architectural decisions that matter strategically, including anything with regulatory, data residency or audit implications.
Operations
CODEWAVE holds Operations: on call, incident response and capacity, including for platforms with stated availability commitments. Stays with the client The option to bring the work in house, or move it, at any time.
Knowledge
CODEWAVE holds Continuity of knowledge across people and time, documented in a form an auditor or a successor supplier can use. Stays with the client Ownership of the code and the intellectual property.
Direction
CODEWAVE holds Day-to-day accountability for agreed systems. Stays with the client Final authority over direction, including which markets the roadmap serves and which obligations it has to meet.
How the relationship develops over time
Accountability is not instant. It is built in stages.
Year 1 Embed and understand
We learn your systems, your business and your constraints from the inside, including how change is approved, how access is granted and what you report on. Everything learned is written down, so the knowledge sits with the team rather than with one person.
Years 2-3 Shared roadmap
We take ownership of outcomes rather than tasks. Planning covers regulatory change and market expansion as much as features, and technical decisions are made together with your team.
Year 5 and beyond Stewardship compounds
Systems are updated, audited and adapted as the business changes, through regulatory change, market expansion and platform migrations. We keep knowledge current so you never become dependent on us.
Credit Agricole: Trust and accountability in a regulated, long-horizon environment
Governance-heavy delivery and ongoing operation.
Platforms operated for retail, banking and FMCG clients since 2008
Have questions about How we Work?
Talk through a possible engagement.
We offer a technical conversation about what you are building, what might be stuck, or what is not working, and we will give you an honest opinion about whether we are the right team for the job.
