Software services
Software engineered around the problem
We design, build, modernise and support the systems businesses run on: .NET and Azure at the core, integration, identity and AI around them, data underneath. Our team, our accountability, your outcome.
At a glance
- service lines, delivered under one engineering standard
- 7
- service lines, delivered under one engineering standard
- documented delivery stages, discovery to handover
- 6
- documented delivery stages, discovery to handover
- client engagements delivered
- 20+
- client engagements delivered
Service lines
What we build, modernise and run
Each service line has its own page with the approach, deliverables and the client work behind it.
Custom software & product engineering
Web platforms, APIs and SaaS products designed, built, tested and shipped by one accountable engineering team.
- A product in users' hands without building a team first
- A codebase your own engineers can extend with confidence
- Predictable releases instead of launch-week heroics
Application & cloud modernisation
Legacy .NET and SQL Server estates modernised in reversible steps, starting with a fixed-scope architecture and performance assessment.
- Faster, safer change on a system the business depends on
- Lower hosting and licensing cost after migration
- A modernisation roadmap leadership can fund with confidence
Integration & event architecture
Partner APIs, event processing and data pipelines designed to keep working when the systems on the other side do not.
- Fewer incidents caused by systems you do not own
- Faster onboarding of new partners and data sources
- Finance and operations teams who trust the numbers
Identity & single sign-on
Single sign-on, federation and access control that pass an enterprise security review, integrated with Entra ID, Okta and other providers.
- Enterprise deals unblocked at the security review stage
- New tenants onboarded in hours, not sprints
- Identity risk reduced to documented, tested behaviour
AI, payment & platform integrations
LLM and real-time voice AI features, payment gateways, video, messaging and enterprise LMS integrations, engineered as production dependencies.
- AI features that stay fast and affordable at real usage
- Payment and payout records finance can trust
- Provider outages absorbed rather than passed to customers
Mobile app engineering
iOS and Android apps in React Native or native Android, built offline-first and released through automated pipelines, on a backend we can build too.
- One codebase serving iOS and Android users
- An app that keeps working when the signal does not
- Predictable store releases instead of release weekends
Dedicated delivery teams
A Codentures team with a named technical lead that owns a product area: architecture, peer review and delivery included.
- Roadmap capacity without a hiring programme
- Architecture that still holds up in year two
- Visibility leadership can rely on every week
Need engineers inside your own team instead? That is technology talent: verified contract engineers who work under your direction.
Accountability
What changes when Codentures owns the outcome
Every delivery engagement makes the ownership split explicit before work starts, so there is never a question about who is accountable for what.
Codentures owns
- Architecture decisions and their consequences
- Code quality, enforced by a written standard and peer review
- Scope, sequencing and transparent status reporting
- Testing, accessibility and security of everything we ship
- A documented handover your team can run with
You own
- Business priorities and acceptance
- Access to the people who know the current system
- Scope and trade-off decisions only you can make
Delivery process
Six stages, each with something you can read
Every stage produces a written artefact. A process whose only output is a status meeting is not a process.
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
Client work
Recent delivery engagements
Delivery work is quoted as a fixed price or a monthly team rate once scope is understood. Most engagements begin with a short, fixed-scope assessment so that the proposal that follows is based on evidence rather than assumptions. See all client work.
- FintechUS
Peer-to-peer currency exchange platform
A US fintech company
A secure peer-to-peer currency exchange platform with regulated fund transfers, a KYC-compliant document workflow and a full Azure delivery pipeline.
- Two financial-provider integrations
- KYC-compliant document workflow
- EdTech
Multi-tenant learning and fundraising platform
A corporate learning provider
A multi-tenant SaaS platform spanning corporate training delivery, fundraising campaigns and executive analytics, with payment processing and BI reporting.
- Three product domains under one tenancy model
- Executive analytics in Power BI
- Video SaaS
Live video streaming and collaboration platform
A real-time collaboration product
A live streaming and real-time collaboration platform delivered to a hard deadline, integrating three video providers over SignalR-based messaging.
- Three video-provider integrations
- Real-time collaboration via Azure SignalR
Questions
Software delivery questions we are asked most
How is delivery work priced?
Scoped projects are quoted as a fixed price after a scoping conversation. Dedicated teams are priced as a monthly team rate that includes the technical lead, architecture ownership and peer review. Many engagements begin with a short, fixed-scope assessment so that the main proposal is based on evidence.
Who owns the architecture decisions?
Codentures does, on delivery work; that is the substance of what you are buying. Decisions are recorded in short decision records naming the context, the options considered, the choice and its consequences, so your team can later see why the system is shaped the way it is.
Will you recommend a rewrite?
Rarely. A rewrite discards working behaviour nobody has written down, including edge cases that took years to discover. We recommend one only when the existing system genuinely cannot carry the requirement, and we will tell you when targeted changes are the better investment.
Who owns the code and intellectual property?
You do. Statements of work assign the intellectual property in the work produced to the client on payment, and every engineer on a Codentures engagement is bound by written IP assignment and confidentiality terms from their first day.
What happens at the end of a delivery engagement?
A documented handover: documentation written for whoever inherits the system, the decision records behind its design, a working session with your team, and an open list of known limitations and deferred work. The engagement is finished when your team can run the system without us.
Tell us what you are building
An idea, a struggling system or a database that will not scale. The first conversation is technical, free, and ends with a clear recommendation on scope and next steps.