Six engagements, chosen by your situation.
Each one is defined the same way — challenge, approach, deliverables, what we need from you, and how long it should take.
Start from where you are.
Most organizations start with the Sprint and decide the rest with evidence in hand.
Entry point
Opportunity & Architecture Sprint
“We need to validate an opportunity before we commit to building.”10 business daysFull detailCloseA decision-ready technical direction: what to build, in what order, at what risk, with what team — or a defensible recommendation to reshape, buy, partner, or stop.
The opportunity matters, but scope, feasibility, architecture, security exposure, cost and sequence are all still assumptions. Committing a delivery budget now means committing to whichever assumption happens to be loudest.
A contained decision engagement. We align the business outcome, map users, workflows, systems and data, model the threats, compare architecture options against real constraints, and produce a staged plan a board can act on — including the option not to build.
- Activities
- Executive intent and success-measure workshop
- Workflow, system, data and integration mapping
- Security, privacy and operational risk review
- Architecture option comparison with explicit trade-offs
- Delivery slicing, dependency and effort analysis
- Executive readout and decision recommendation
- Deliverables
- Executive decision brief
- System context and architecture blueprint
- Data and integration map
- Threat overview and risk register
- Architecture decision records
- Prioritized delivery roadmap with milestone gates
- Indicative team shape and effort range
- What we need from you
- An accountable executive sponsor for the duration
- Access to the people who run the affected workflows
- Current system, data and integration documentation where it exists
- Known constraints: regulatory, contractual, operational, budgetary
- Risks of inaction
- A platform decision gets made implicitly by the first team to start writing code.
- Security and data constraints surface after the architecture is difficult to change.
- Budget is approved against a scope nobody has tested against the operating reality.
- Security
Threat modelling and data-handling review are part of the engagement, not a later phase. Findings are recorded in the risk register with owners.
- Entry conditions
- There is a named business outcome, even if the solution is unclear.
- An executive sponsor can commit to the sessions.
Secure Product Pilot
“We need to turn a prototype into something real without building a throwaway.”4–8 weeksFull detailCloseEvidence a leadership team can act on, and a codebase that continues into production instead of being rewritten.
The organization needs evidence quickly. A demo would be faster, but a demo cannot answer whether the idea survives real users, real data and real security requirements — and it usually has to be thrown away.
One bounded use case, built on production-aware architecture. Success criteria are agreed before the build, a security baseline is applied from the start, and the engagement ends in an explicit scale or no-scale decision supported by evidence.
- Activities
- Use-case bounding and success-measure definition
- Production-aware architecture for a narrow slice
- Security baseline: identity, access, data handling, secrets
- Build, instrument and release to a defined user group
- Real-user testing and measured evaluation
- Scale, reshape or stop recommendation
- Deliverables
- A working pilot in a controlled environment
- Evidence report against the agreed success measures
- Risk assessment and outstanding security work
- Path to production with effort and sequence
- What we need from you
- A defined user group willing to use the pilot in real work
- Access to representative data, or an agreed anonymization approach
- A decision owner for the scale or no-scale call
- Risks of inaction
- A convincing prototype creates commitment to an architecture that cannot go to production.
- The pilot proves interface appeal rather than operational value.
- Security and data questions are deferred until procurement raises them.
- Security
Identity, access and data-handling decisions are made before the first release, and the residual risk is documented in the evidence report.
- Entry conditions
- The use case and its users are identifiable.
- Someone owns the decision the pilot is meant to inform.
Enterprise Platform Development
“Our existing platform cannot scale with the business.”Phased delivery, cadence agreed per programmeFull detailCloseA platform that can be operated, extended and audited by the organization that owns it.
Operations depend on systems that were never designed for the current load, integration surface or compliance expectation. Every change is expensive, and the cost of a failure is now measured in business hours rather than tickets.
Domain and workflow modelling first, then platform architecture, then progressive delivery. Integrations, quality engineering, observability and deployment discipline are part of the build rather than a hardening phase at the end.
- Activities
- Domain, workflow and role modelling
- Platform architecture and integration design
- Progressive delivery in production-shaped increments
- Quality engineering and automated verification
- Observability, deployment and rollback controls
- Adoption, enablement and documentation
- Deliverables
- A maintainable operational platform with defined service objectives
- Architecture documentation and decision records
- Automated test and deployment pipeline
- Runbooks, monitoring and rollback procedures
- Ownership and handover model
- What we need from you
- Product and operations stakeholders available through delivery
- Access to the systems the platform must integrate with
- Agreement on service objectives and acceptance gates
- Risks of inaction
- Operational load grows faster than the system's capacity to absorb it.
- Institutional knowledge stays trapped in manual workarounds.
- Each integration increases fragility instead of capability.
- Security
Security requirements are defined before implementation and verified before release, within the agreed system scope.
- Entry conditions
- The target workflows and their owners are identified.
- There is a decision path for integration and data access.
AI & Data Intelligence
“We need AI that is useful and governed, not a demonstration.”Scoped per use case after readiness reviewFull detailCloseAutomation or decision support that is measurable, governed, and used in real work.
Data is difficult to trust, and AI initiatives sit beside the work rather than inside it. The result is a capability nobody depends on and a risk surface nobody has measured.
Start from use-case economics and data readiness. Build governed pipelines, design the evaluation before the model choice, define human oversight and cost ceilings, and integrate the output into the workflow where the decision is actually made.
- Activities
- Use-case economics and readiness assessment
- Data lineage, quality and access review
- Governed pipeline and retrieval design
- Evaluation design and measurement harness
- Human oversight, escalation and audit paths
- Model and agent observability, with cost controls
- Deliverables
- Decision-support or automation integrated into a real workflow
- Evaluation harness and baseline results
- Data lineage and access documentation
- Oversight model: who reviews what, and when
- Operating cost and monitoring model
- What we need from you
- Access to the data the decision depends on
- Domain experts who can define a correct answer
- An owner for the operating and oversight model
- Risks of inaction
- Decisions are made on numbers whose lineage nobody can explain.
- Model behaviour changes without anyone detecting it.
- An ungoverned integration exposes data the organization is accountable for.
- Security
Data boundaries, retention and access are agreed before any pipeline is built. Model behaviour is evaluated and monitored rather than assumed.
- Entry conditions
- There is a decision or workflow the capability must improve.
- Someone can define what a good outcome looks like.
Product Security & Hardening
“Our product needs to hold up under security review.”Scoped after review boundary is agreedFull detailCloseA product whose security posture can be described precisely, with the highest-exposure items closed first.
The product works. What is unclear is how it behaves under adversarial conditions, what its dependencies bring with them, and which of its assumptions a reviewer will reject.
Architecture and threat review, then dependency, access and configuration review, then verification. Findings are prioritized against business exposure, and improvements are implemented within an agreed scope with evidence recorded.
- Activities
- Architecture and threat review
- Identity, access, secrets and configuration review
- Dependency and vulnerability management review
- Test strategy and verification gaps
- Release, environment and rollback controls
- Prioritized remediation with implementation
- Deliverables
- Prioritized risk register with business exposure
- Implemented improvements within the agreed scope
- Verification evidence for what was changed
- Operating recommendations and residual risk statement
- What we need from you
- Source access, or a defined review boundary
- Environment and deployment documentation
- An owner for accepting residual risk
- Risks of inaction
- Procurement stalls on questions the team cannot answer with evidence.
- A dependency or access decision made early becomes a disclosed incident later.
- Remediation lands in the middle of a launch instead of before it.
- Security
This engagement is not an independent audit or a penetration test. Where independent assessment is required, it is scoped with a named qualified partner and reported separately.
- Entry conditions
- There is a defined product and review boundary.
- Someone can accept or reject residual risk.
Managed Engineering Team
“We need a stable long-term delivery capability.”Rolling engagement with review cyclesFull detailClosePredictable throughput, retained product knowledge, and transparent long-term ownership.
Capacity is the visible problem; continuity is the real one. Rotating contractors produce output without retaining the product knowledge that makes the next decision cheaper.
A stable multidisciplinary unit with named engineering leadership, defined product outcomes rather than ticket throughput, published delivery metrics, maintained documentation, and joint governance with the client.
- Activities
- Team shaping against product outcomes
- Engineering leadership and technical governance
- Delivery cadence, metrics and reporting
- Documentation and knowledge retention
- Joint prioritization and roadmap review
- Operational support and incident learning
- Deliverables
- A stable delivery unit with named leadership
- Published delivery and quality metrics
- Maintained architecture and operating documentation
- Joint governance cadence and roadmap
- What we need from you
- A product owner with decision authority
- Access to users and operational context
- Agreement on outcomes and reporting cadence
- Risks of inaction
- Product knowledge leaves with each contract.
- Delivery velocity is reported but not governed.
- Nobody is accountable for the system between projects.
- Security
The team operates inside the client's access model, with agreed environment separation and offboarding procedures.
- Entry conditions
- There is a product or platform with a continuing roadmap.
- A client-side product owner is available.
Six engagements, side by side.
Durations are the proposed design until they are written into a scope.
| Engagement | Best when | Primary output | Stage | Duration |
|---|---|---|---|---|
| Opportunity & Architecture Sprint | Direction is unclear and the wrong foundation would be costly | Decision pack: blueprint, risks, roadmap | Before delivery commitment | 10 business days |
| Secure Product Pilot | Value must be proven before a platform investment | Working pilot plus measured evidence report | Validation | 4–8 weeks |
| Enterprise Platform Development | Core operations depend on systems that cannot keep up | Operated platform with ownership model | Build and operate | Phased delivery, cadence agreed per programme |
| AI & Data Intelligence | AI or analytics must become dependable operational capability | Governed capability with evaluation evidence | Validation through operate | Scoped per use case after readiness review |
| Product Security & Hardening | A product is entering procurement or carrying unmeasured risk | Risk register plus implemented improvements | Pre-launch or pre-procurement | Scoped after review boundary is agreed |
| Managed Engineering Team | Delivery must continue reliably beyond a single project | Accountable delivery unit and governance | Operate and extend | Rolling engagement with review cycles |
Six stages. A gate at the end of each.
Every engagement runs on this track and enters it at its own stage.
Discovery
Are we solving the right problem?
Define outcomes, workflows, constraints and stakeholders.
Architecture
What must be true for this to work?
Set boundaries, data ownership, threats and architecture options.
Design
Will people understand and adopt it?
Design and validate workflows, interfaces, accessibility and content.
Development
Can it be built safely and predictably?
Build production increments with automated verification and security controls.
Deployment
Is production ready?
Prepare environments, monitoring, rollback, training and cutover.
Support
Is the value being sustained?
Review service health, incidents, performance, cost and roadmap.
Security inside every engagement.
Every control is labelled by maturity, so nothing reads as more established than it is.
- 12Current practice
- 4Engagement-scoped
- 3Planned maturity work
Sudens does not currently hold, and does not claim, ISO 27001, SOC 2, HIPAA or any other certification, and does not present a cloud provider's certifications as its own.
Read the security practice- L1GovernanceWho is accountable for security decisions?
- L2DesignWhat can go wrong, and what does the architecture do about it?
- L3BuildHow is the software and its supply chain controlled?
- L4VerifyWhat evidence exists that the controls work?
- L5ReleaseHow does change reach production safely?
- L6OperateHow would you know, and what would you do?
- Current practice
- Engagement-scoped
- Planned maturity work
Evidence, when it is approved.
Approved case studies will link back to the engagement used. Until then, this is the standard they have to meet.
Statistics- 01Every measure states its scope
- 02Attribution is approved in writing
- 03Nothing is published to fill a layout
- 04Technology is metadata
Let's make the expensive decisions early.
Tell us what has to work. We reply with a written next step.
- D-01Executive decision brief
- D-02System context and architecture blueprint
- D-03Data and integration map
- D-04Threat overview
- +4more Sprint deliverables