How we work
Our standards, written down and published
Both sides of Codentures run on the same idea: the standard is written down. Here is what code passes before it ships, and what an engineer passes before you meet them. “Rigorous” is a claim; a published process is evidence.
At a glance
- engineering principles behind every engagement
- 6
- engineering principles behind every engagement
- stages in the delivery quality standard
- 6
- stages in the delivery quality standard
- verification layers for every engineer
- 4
- verification layers for every engineer
Engineering principles
Six principles, and the reasoning behind each
Quality never routes through one person
On delivery work, every change is reviewed against a written engineering standard by a second senior engineer. That is what lets us run several engagements at once without the quality bar becoming a scheduling problem. On talent engagements, your team is the review layer by design.
Decisions are written down as they are made
Significant architecture choices get a short record: context, options considered, decision and expected consequences. The engineer who inherits the system in two years can see why it is shaped the way it is.
The smallest thing that could work, first
We do not introduce a message broker to solve a query problem, or a microservice to solve an organisational one. Architecture sized above the problem is a cost clients pay every day afterwards.
Accessibility and security at design time
Both are cheap as defaults and expensive as retrofits. We build to WCAG 2.2 AA and validate input at server boundaries as standard, not as a line item you can decline.
Bad news travels immediately
A slipped estimate reported in week two is a planning problem. The same slip reported in week eight is a trust problem. We have the difficult conversation while it is still cheap.
Handover is the definition of done
An engagement finishes when your team can run the system without us: documentation for whoever inherits it, a working session rather than a document dump, and an open list of known limitations.
Software delivery
The delivery quality standard
What has to be true at each stage before work moves to the next one.
Step 1: Discover
We read the system and talk to the people who live with it before proposing anything. Most bad estimates are discovery failures, not engineering failures.
- Codebase, data model and deployment path reviewed directly
- Constraints written down, including the organisational ones
- The problem restated in our words, so misunderstandings surface now
Step 2: Architect
Architecture decisions are made deliberately, recorded with the alternatives considered, and revisited when the reasoning stops holding.
- A short decision record per significant choice: context, options, decision, consequences
- Design sized to the problem, not to the latest trend
- Security and accessibility considered at design time, where they are cheap
Step 3: Build
Work is delivered in small, reviewable increments against a written engineering standard, with a second senior engineer reviewing every change.
- A written standard covering structure, testing, error handling and logging
- Peer review by a second senior engineer on every change
- Automated tests written alongside the code
- Trunk-based flow with CI running on every change
Step 4: Validate
Before anything ships we check it against what was asked for, and against the non-functional requirements that are usually skipped.
- Automated test suite plus targeted manual verification
- Accessibility checks against WCAG 2.2 AA, automated and by keyboard
- Input validation, authorisation and dependency review at the server boundary
- Performance measured under production-like conditions
Step 5: Deploy
Releases are automated, reversible and uneventful. A deployment that depends on someone remembering a step will eventually fail.
- Pipeline-driven releases through Azure DevOps or GitLab CI
- Infrastructure and configuration in version control
- A rehearsed rollback path before the first production release
- Secrets held in a managed store, never in the repository
Step 6: Hand over
An engagement is finished when your team can run the system without us. That is our definition of done.
- Documentation written for the engineer who inherits the system
- Decision records explaining why the system is shaped the way it is
- A working session with your team, not a document dump
- Known limitations and deferred work named openly
Technology talent
The talent pipeline
The network runs continuously, not per request, which is what makes a one-to-four-week start possible. The four verification layers sit inside stages two to five. Full detail on the talent page.
Step 1: Role brief
We write the role down before we look at anyone: the stack, the seniority genuinely required, the team the engineer will join, and the budget.
- Stack, domain and the parts of the system the engineer will touch
- The seniority the role actually needs, including when that is less than requested
- Who reviews their work on your side
- Time-zone overlap, start date and expected duration
Step 2: Sourcing from an established network
Candidates come from a network we run continuously, not a search we start when you call. That is what makes a one-to-four-week start possible.
- Referrals from engineers already working with us, our highest-signal channel
- Direct outreach to engineers in Portugal, across the EU and in India
- Developer communities in Braga, Porto, Lisbon and our India network
- Applications through our engineering network page
Step 3: Technical assessment
A structured technical assessment against documented criteria for the tier, run the same way for every candidate so results are comparable.
- Depth in the specific stack, not a general programming quiz
- Reading and reasoning about code they did not write
- How they handle being wrong, and whether they say so early
- Written communication, because most of the working relationship is written
Step 4: Reliability and references
Competence is the baseline. The failure that costs clients money is unreliability, so we check for it deliberately.
- Reference conversations with people who managed their work directly
- A track record of finishing engagements they started
- Availability and competing commitments, stated plainly
- Right to work and contracting status for the location involved
Step 5: Shortlist and introduction
We put forward a small number of candidates we would stand behind, each with a written scorecard. You interview and decide.
- A focused shortlist rather than a volume of CVs
- A written scorecard per candidate, including our reservations
- Your own interview, always; we never ask you to hire on our word alone
Step 6: Contract, onboarding and check-ins
We handle contracting, IP assignment, invoicing and compliance, support the first weeks of onboarding, then stay in touch for the life of the engagement.
- Contracting through our Portuguese company, with IP assignment and confidentiality from day one
- One invoice to you, whatever the engineer's location
- A structured check-in at 30 days, then at regular intervals
- Replacement sourcing if the match does not work
Technology
What we work in
Grouped by what it does. We list a technology only if we would staff a production engagement with it today.
Backend & services
The centre of gravity. Most of what we are asked to fix or build lives here.
- .NET
- C#
- ASP.NET
- REST API design
- GraphQL
- Background & event processing
Web & interface
Server-rendered where it should be, interactive where it needs to be.
- Next.js
- React
- Angular
- TypeScript
- Accessible component systems
Mobile
iOS and Android from one codebase, with native code where the device demands it.
- React Native
- TypeScript
- Kotlin
- Java
- Android Jetpack
- Native modules & SDK bridges
- Offline-first sync
- Bitrise
Data
Including the unglamorous part: making an existing database stop being the bottleneck.
- PostgreSQL
- SQL Server
- Azure SQL
- PgBouncer
- MongoDB
- Redis
- Power BI
Cloud & platform
Azure-weighted, with AWS where the client is already there.
- Microsoft Azure
- AWS
- Azure Functions
- Docker
- Infrastructure as code
Integration & messaging
Systems that have to talk to systems nobody controls.
- Event Hubs
- Service Bus
- Logic Apps
- Azure Data Factory
- Webhooks
- Retry & idempotency design
Identity & access
Single sign-on that survives an enterprise security review.
- Entra ID
- Okta
- SAML 2.0
- OAuth 2.0
- OpenID Connect
- SSO integration
AI & LLM engineering
Model APIs treated as production dependencies, with cost and quality visible.
- OpenAI
- Anthropic
- Azure OpenAI
- Real-time voice AI
- Open-source models
- pgvector
- AI-assisted development
Payments & platforms
Any third-party system, held to the same discipline: payments, real-time media, messaging, learning.
- LiveKit
- WebRTC
- Stripe
- Adyen
- PayPal
- Twilio
- SendGrid
- SCORM / AICC / xAPI
Delivery tooling
How the work actually reaches production.
- Azure DevOps
- GitLab CI/CD
- Turborepo
- Trunk-based development
- Automated testing
Put our standard to work on your system
Tell us what you are dealing with. We will recommend the right way of working and tell you what the first step involves.