How we work,
across every offer.

Scoping at SDEN is not a discovery call. It is a structured investigation that produces a written problem statement naming the actual job the software has to do, an architecture and decision log explaining the technical choices we recommend (and the alternatives we considered), and a risk register that ranks what could go wrong by exploitability and business impact. For AI work it goes further: an honest feasibility read (is this a problem a model can solve reliably, or is it a rules engine wearing an AI costume?), a build-versus-buy call against off-the-shelf options, and a look at whether your data is actually ready to feed a model. The phase ends with a go / no-go we are willing to stand behind in front of your board.

We ask the questions other vendors skip. Who is the accountable decision-maker on your side? What does the work look like for the user the day after launch, not at the demo? What data does the product create, where does it live, and who is allowed to see it, and where does it sit under the EU AI Act's risk tiers? Above all: what does 'good' mean, measured? We define the eval criteria here, in phase one, so 'it works' is a number we agreed on rather than a vibe at the demo. The phase is paid, time-boxed, and short, typically one to three weeks depending on scope.

A demo is a video. A prototype is something the user can actually use, against the actual data shape, on the actual stack we will ship to production. Phase two delivers the latter. The team designs the core flows, builds an interactive prototype for the highest-risk paths (the ones that decide whether the product is usable, not the ones that decide whether it is pretty), and validates them against real data and real users before any production code lands.

For AI, this is where the consequential choices are made and written down: which model, and why; retrieval (RAG) versus fine-tuning versus a plain prompt; a single call versus an agent; and the cost and latency budget each path has to live inside. We bias toward boring tech under the AI (frameworks, databases, and hosting the community has already debugged at scale) and we name the reason for every choice. The phase also designs the eval harness: the graded test set that will tell us, automatically and on every change, whether the AI is getting better or worse. It produces the prototype, a design system (tokens, components, accessibility baseline), and that eval/test plan for the production phase.

Development at SDEN runs in two-week iterations with a working build at the end of every one. Every pull request is reviewed by a second engineer before merge; the merge gate runs the test suite, the eval suite from phase two, the security scanners (SCA, SAST, secret scanning), and the type checker. Branch protection is on, signed commits are on, and no engineer (including the most senior) can bypass the checks. The result is a codebase where the second engineer to read any file already understands it, and where a change that quietly makes the AI worse fails CI instead of reaching production.

Hardening is the part most vendors skip. It is the work that turns 'it runs' into 'it runs in production for the next three years.' For AI that means guardrails on inputs and outputs, cost ceilings so a runaway loop cannot bankrupt the feature, and a security review against prompt injection and the OWASP LLM Top 10 alongside the OWASP Top 10 and the relevant ASVS level. It also means load testing against expected traffic shapes, chaos testing the failure modes the risk register flagged in phase one, and the no-technical-debt clause: we will not ship code we would not be willing to take a 2 a.m. page on. If a deadline forces a shortcut, the shortcut lands in the issue tracker as a P0 and gets paid back before the next feature lands. We document the discipline explicitly in our security engineering posture.

Delivery is staged. The first production release lands behind a feature flag for a single tenant or a small user cohort. We watch the SLOs (and, for AI, the quality and cost numbers) against real production traffic for a defined observation window, then expand to the full audience once the data confirms the system behaves as expected. The release is not a calendar event. It is a measurable state change.

What we hand over with the release is what makes the engagement durable: a runbook for every operational task, a monitoring dashboard that exposes the SLOs we committed to plus the AI's behavior in production (quality, drift, hallucination rate, and spend, not just uptime), an on-call playbook for the incidents the risk register anticipated, an incident response template, and documentation written for the next engineer who joins your team. Crucially, the handover transfers the AI itself: the prompts, the eval suite, and the guardrails, so your team can change the system safely, not just keep it running. SDEN engagements do not end at production. They taper. We commit to a defined support window after launch (usually three to six months, scoped to the engagement) during which we operate the system jointly with your team, and during which the operational knowledge transfers, not just the code.