Technical Risk and Scale Readiness Sprint
A fixed-scope senior assessment of the systems your business runs on: the architecture, the cloud platform and its cost, the security posture, the way software actually gets delivered, and where AI has entered without anyone deciding that it should. You get a prioritised roadmap with owners and sequencing, not a document describing your own company back to you.
Who the sprint is for
It suits a company with something real in production and something specific at stake. Typically 10 to 150 people, a product that has found its market, and an engineering team of three to forty.
Marketplaces and platforms
Where transaction volume is growing faster than the architecture was designed for.
B2B SaaS moving upmarket
Where the buyer is now an enterprise with a security team and a questionnaire.
Fintech-adjacent businesses
Carrying payment, identity or sensitive financial data without a dedicated security function.
Digital platforms with key-person risk
Where one long-standing supplier or one long-standing engineer holds most of the knowledge.
Investors and acquirers
Underwriting one of the above, before the money moves.
When the sprint is the wrong purchase
Cheaper to say now than to discover in week three.
- You have fewer than about five engineers and one obvious problem you can already name. Pay for the fix, not for the assessment.
- Nothing is in production yet. There is not enough evidence to review, and what you need is an architecture conversation, which is an hour rather than a sprint.
- The software runs and nobody left can safely change it. That is a code audit and takeover at 2,500 euros, a narrower and cheaper answer.
- You want to know which AI use cases are worth funding. That is the AI audit, which looks for opportunity. The sprint looks at AI as risk and governance. Different question, different room.
- You need a signed certification or a penetration test. Those are formal, specialist engagements. We will tell you which you need and what it involves.
What usually triggers it
Nobody buys an assessment because the quarter is going well. Seven triggers cover almost every sprint we are asked about.
- An enterprise customer sent a security questionnaire and the honest answers are not the ones you want to give.
- The cloud bill has grown faster than revenue for two or three quarters and nobody can attribute the increase.
- A funding round, an acquisition, or a board that has started asking about technical risk in writing.
- Delivery has slowed noticeably and adding people has not helped.
- A CTO or lead engineer has left, or is about to, taking the mental model with them.
- An incident: an outage, a data scare, a near miss that exposed how much was undocumented.
- An expansion into a new region has raised data residency, latency and compliance questions the current design never had to answer.
Scope: eight workstreams
Every sprint covers these eight. Depth is agreed at scoping: a sprint triggered by a security questionnaire goes deeper on two of them and confirms the rest.
Architecture and scalability
The real constraints: data model, coupling, statefulness, the queue or table everything waits on, and which two or three seams are worth cutting first.
Cloud platform maturity and cost
Provisioning and environments, deployment and rollback, observability, and the actual line items driving spend, with what is safely removable and what is load-bearing.
Security posture and review readiness
Exposure surface, secrets handling, dependency and patch hygiene, logging and audit trails, incident readiness, and what an enterprise questionnaire will find. Readiness, not certification.
Identity, access, SaaS and operational controls
Who can reach production and how that is granted and revoked, joiner-mover-leaver in practice, multi-factor coverage, and the SaaS estate nobody owns.
Engineering delivery model
Branching, review latency, environments, test coverage where it matters, release cadence, and where decisions actually get made or stall.
Technical leadership and team
Whether the structure has a decision-maker in it, key-person risk, the hiring bar, and the gap between what the team is asked to own and what it can.
AI use, supplier risk and governance
Which AI tools are in use, sanctioned or not, what data reaches them, what your suppliers' AI features do with your data, and the smallest governance baseline that would actually hold.
Vendor and third-party risk
Concentration, contractual exit, code and data ownership, and what happens operationally if a supplier disappears next month.
How it is done: read-only access to code, cloud console and monitoring; interviews with engineers, product and leadership; and the artefacts that already exist, including the security questionnaire, the cloud bill and the board pack. We do not run intrusive testing and we do not touch production.
What you get
Six outputs. The roadmap is the point, and the rest supports it.
Executive findings briefing
A live session for founders and leadership, and the document behind it. Written for someone who does not read architecture diagrams.
Technical risk register
Each risk with its likelihood, its business consequence, an owner and an effort estimate. Sortable, not narrative.
Prioritised 30/60/90-day roadmap
Sequenced by dependency and by what actually unblocks the business, including what to deliberately not do in the next quarter.
Architecture and operating-model recommendations
The two or three structural changes worth making, and the ones that are not worth it yet.
Board or investor summary
Where relevant, two pages that survive being forwarded without you in the room.
Leadership workshop
Optional, and on site where the dates line up.
This is a roadmap, not an audit report. The test we hold ourselves to is simple: your team should be able to start work on the Monday after the briefing without another meeting to decide what the document meant. Findings without sequencing, owners and effort are a description of your problems, and you already have one of those.
Timeline
| Stage | Duration |
|---|---|
| Scoping call and access setup | Before day one, usually a week |
| Interviews and system review | Days 1 to 5 |
| Analysis, cost modelling, drafting | Days 6 to 9 |
| Findings briefing and roadmap walkthrough | Day 10 |
| Written deliverables handed over | Within 3 working days of the briefing |
Two to three calendar weeks end to end for a typical engagement. What stretches it is rarely the analysis: it is access to systems and the availability of the people who know how things actually work. We name both at scoping instead of pretending they are free.
What is not included
Stated plainly, because the gap between an assessment and a formal audit is where expectations go wrong.
- Penetration testing, or any intrusive security testing.
- Formal certification, or a guarantee of passing any audit or questionnaire.
- Legal, tax, immigration or regulatory advice, in any jurisdiction.
- Implementation. The sprint produces the roadmap, and execution is a separate engagement, by your team or ours.
- A full code-quality review of every repository. We sample deliberately and say what we sampled.
- Recruitment, though we will describe the roles the roadmap implies.
On-site workshops
The sprint runs remote-first and does not require anyone to fly. Two parts are better in a room when the timing allows: the interviews, which go further face to face, and the findings briefing, where the arguments actually happen. Add the on-site component at scoping and we will align the sprint with a visit.
We are an engineering studio in Bordeaux, France, and we travel for the sessions that earn it. For clients in the Gulf we schedule these against planned Dubai visits, and the dates are agreed before the engagement starts.
Pricing
Fixed-scope engagement, priced after a short scoping conversation. The price depends on how many systems are in play and how deep two or three of the workstreams need to go, and quoting before knowing that would be a guess with a number attached. You get the figure in writing, alongside exactly what is in and out, before you commit to anything.
Where a scope is genuinely fixed we publish the price rather than hiding it behind a form. The code audit is 2,500 euros flat, and our UAE build bands start at AED 20,000. Both are on their pages.
Frequently asked questions
How is this different from your code audit?
The code audit answers whether this software can be safely changed, and by whom, at a fixed 2,500 euros. The sprint answers whether the business will survive its next year of growth, across architecture, cloud, security, delivery, AI and suppliers. Different question, wider scope. If you only need the first, buy the first.
Will you need production access?
Read-only access to code, cloud console and monitoring is ideal. We can work from architecture documentation and interviews alone, the findings are simply less specific, and we will say where.
Can you do this under NDA?
Yes, as standard.
Who do you need from our side?
Roughly six to ten hours in total across the engineering lead, one or two engineers, product, and whoever owns the cloud account. Plus a founder or CEO for an hour at the start and an hour at the briefing.
Does the roadmap assume we hire you to deliver it?
No. It is written to be executed by your own team and says so explicitly. If we are the right people for part of it, that is a separate conversation and a separate proposal.
We are an investor. Can you run this before we invest?
Yes. The risk register and the two-page summary are written for that use, and we will be explicit about what we could not verify in the time available.
Do you certify us as secure?
No. Nobody honest does that from an assessment. We tell you what an enterprise reviewer will find, what to fix first, and what to write down. Formal certification and penetration testing are separate specialist engagements.
What if the findings say we should not do the thing we were planning?
Then that is the finding, and it is the most valuable one you can buy. We would rather say it in week two than watch it cost you a year.
Find out what you are actually dealing with
Tell us what triggered the question: the questionnaire, the cloud bill, the board, the departure. We will tell you whether a sprint is the right shape, what it would cover in your case, and what it costs, before you commit to anything.
