The SDEN
engineering approach.
From scoping to controlled production release: the four deliberate phases SDEN uses on every project, plus the engineering disciplines that keep code shippable and free of debt.
Scoping & architecture
Phase one produces a concrete decision: build, rebuild, or do not start. SDEN delivers the architecture, risk register, and go / no-go recommendation before any production code is written.
Scoping at SDEN is not a discovery call. It is a structured investigation that produces three artifacts: a written problem statement that names the actual job the software has to do, an architecture diagram 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. The phase ends with a go / no-go recommendation that 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 is it stored, and who is allowed to see it? What is the smallest version of this product that could go live, and what is the bar for declaring it 'live'? The phase is paid, time-boxed, and short: typically one to three weeks depending on scope.
What this phase produces
- Written problem statement with measurable success criteria
- Architecture diagram + decision log (ADRs) explaining every non-trivial choice
- Risk register ranked by exploitability and business impact
- Go / no-go recommendation, with the scope we would commit to
Rituals we keep
- One stakeholder interview per accountable decision-maker on your side
- Architecture review with the engineers who would build the project
- Mid-phase checkpoint with a draft of the artifacts
- Final phase review where we present the go / no-go recommendation
What we refuse during this phase
- We will not skip scoping because 'we already know what we want.' We have rescued enough projects to know that statement is rarely true.
- We will not write production code in this phase. Anything we ship here is a thought-prototype, clearly marked as throwaway.
Design & prototyping
Phase two turns the scoping decision into something you can validate before commitment: a real prototype against real flows, with the technology choices made on the record.
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 user 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 users before any production code lands.
The technology choices are made and documented in this phase. We bias toward boring tech (frameworks, databases, hosting providers that the engineering community has already debugged at scale) and we name the reason for every choice. The phase produces a design system (tokens, components, accessibility baseline), the interactive prototype, and a written test plan for the production phase that lists what we will measure, automatically, before we ship.
What this phase produces
- Interactive prototype of the highest-risk user flows
- Design system (tokens, components, accessibility baseline)
- Technology stack decisions with written rationale (ADRs)
- Test plan listing what production will measure before release
Rituals we keep
- Two user-testing sessions on the prototype before phase three begins
- Weekly design review with engineering in the room
- Mid-phase stakeholder demo of the live prototype
- End-of-phase walkthrough of the test plan
What we refuse during this phase
- We will not present a prototype that mocks the failure paths. If the demo breaks when the user makes a mistake, the prototype is incomplete.
- We will not pick a stack because it is trending. The default answer is the boring stack that the team can still maintain in three years.
Development & hardening
Phase three turns the validated prototype into production-grade software: short iterations, code review on every change, security built in from the design stage, and no technical debt left behind.
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 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.
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.' That includes load testing against expected traffic shapes, chaos testing the failure modes the risk register flagged in phase one, security review against OWASP Top 10 and the relevant ASVS level, 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.
What this phase produces
- Production-grade application in your repositories, deployed to staging
- Test suite covering the success paths, error paths, and edge cases
- Security review against OWASP Top 10 and the relevant OWASP ASVS level
- Load and chaos test results against the documented traffic shapes
Rituals we keep
- Two-week iteration cadence with a working build at the end of each
- Weekly demo to the client stakeholder, live on staging
- Code review on every PR, no exceptions
- End-of-iteration retrospective with the engineering team
What we refuse during this phase
- We will not bypass the merge checks under deadline pressure. If the check is wrong, the check is the bug.
- We will not ship code with a known unmitigated high-severity vulnerability. The vulnerability gets fixed; the deadline gets renegotiated honestly.
Delivery & support
Phase four is a controlled production release with the operational artifacts a team needs to run the software once SDEN's role tapers: runbook, monitoring, SLOs, on-call playbook.
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 against the 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, 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. 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 production system jointly with your team, and during which the operational knowledge transfers, not just the code.
What this phase produces
- Staged production release with feature-flag rollout
- Operational runbook for every routine production task
- Monitoring dashboards exposing the SLOs we committed to
- On-call playbook for the incidents the risk register anticipated
- Incident response template and post-mortem culture wired in
Rituals we keep
- Pre-release readiness review against the published checklist
- Staged rollout with documented expansion criteria
- Joint on-call rotation during the support window
- Monthly review of the SLO data during the support window
What we refuse during this phase
- We will not declare a release 'live' before the SLOs have been observed against real traffic.
- We will not abandon the team at handover. The handover is a defined process, not an email with a ZIP attached.
What you should expect
from a real engineering partner.
If you are comparing SDEN to another vendor, here is the buyer's-side checklist we would use ourselves. Ask to see the architecture decision records from a prior engagement (most vendors do not have them; they are the single most reliable proof of senior engineering). Ask who specifically will write your code and whether you can talk to them before you sign. Ask how technical debt is tracked and paid back, and ask to see a recent post-mortem (a real one; redacted is fine; the absence of post-mortems is the tell).
Walk away from vendors who promise fixed-everything against a vague scope, who refuse to put you in contact with the engineers, who treat security as a phase that happens 'before launch,' or who deliver in a way that makes the next vendor's job harder than it should be. SDEN's posture is the opposite of all of those: we are explicit about scope, we put you in front of the engineers, and we leave the codebase in a state any competent team can pick up.
Approach
questions about engagement.
Direct answers to the questions we get asked the most. If yours isn't covered, write to the team.
Paste your URL. Get a
security audit in 20 seconds.
Most agencies talk about secure-by-design. Run a real audit right now. We'll probe your TLS, security headers, cookies, exposed paths, supply chain, and email auth, then narrate the result.
Streaming findings will appear here.
Paste a URL on the left and hit Audit my security.
Got a project worth building?
Tell us about your project. We work with a limited number of clients at a time, and we'll get back to you within 24 working hours with a first engineer's read, no commitment.