Check readiness
A buyer starts with repo context, workflow context, and a controlled fit conversation.
Investor briefing
AI can create code faster than teams can safely absorb it.
AI can produce code faster than teams can review and trust it. SDF is the product for governed AI-assisted delivery: the SDF CLI installs the repo-local Front Door and runs the verification loop that gives each change scope, receiver-owned guidance, evidence, configured checks, limits, and human review before the team decides what ships. The current engagement path is Assessment, First Governed Change, then Team Operating Model.
Current stage: assisted, human-reviewed, no automatic approval or merge.
Why now
AI-assisted engineering turns review into the bottleneck.
The urgent gap is no longer code generation. Teams can already generate more code.
The hard part is knowing which AI-assisted work is scoped, tested, owned, secure-aware, maintainable, scalable, and ready for review.
That creates urgency now: leaders need controlled speed, not a pile of faster PRs with weaker context.
Software Dark Factory starts where the risk becomes concrete: the repo, the PR, the test suite, and the delivery workflow.
Why SDF is different
SDF turns AI-assisted work into checked, reviewable governed changes.
AI tools write code. CI checks some outcomes after code exists. SDF structures the work before review: the SDF CLI runs the local verification loop, the installed Front Door carries repo-local guidance, and intent, acceptance criteria, evidence, verification results, risks, limits, and handoff context travel with the change.
The review, merge, release, deployment, and product judgement stay human. SDF makes the work easier to understand and trust; it does not certify correctness, automate approval, or replace engineering judgement.
The founder advantage is practical: years of full-SDLC delivery plus current dogfooding across the SDF CLI, this GTM app, and Explore My Profile. The dream outcome is agentic speed with clean, secure, scalable, sustainable, reviewable code.
Read founder memoProblem and buyer pain
AI can produce code faster than teams can review and trust it.
CTOs, VPs Engineering, and technical founders want AI speed, but they still own production quality, customer trust, security posture, and delivery accountability.
The risk is not only bad code. It is unclear scope, weak tests, missing ownership, hidden assumptions, security-sensitive boundaries, and changes that reach review without enough evidence.
- More PRs arrive with less shared context.
- Reviewers need evidence, not just agent confidence.
- Leaders need ownership and limits to stay visible.
- Teams need controlled speed, not weaker review.
The wedge
Assessment, First Governed Change, then Team Operating Model.
Start with a founder-led assessment. If the repo and workflow are a fit, choose one bounded change that is useful enough to matter and small enough to review.
The first proof is one First Governed Change: scoped intent, acceptance criteria, one durable evidence archive, receiver-owned verification results, limits, and human review attached to the work.
If the proof is useful, the Team Operating Model adapts what proved helpful to the team's repo, stack, playbooks, review process, and risk profile.
- Assessment shows what is ready, risky, missing, and safe to try first
- One bounded First Governed Change proves the path in real review
- The evidence.md archive gives buyers a useful proof loop
- The Team Operating Model adapts the parts that proved useful
- Optional ongoing support remains separately scoped
Mechanism
The assessment becomes the start of governed delivery.
The assessment is the handoff between buyer intent and governed action: repo context, workflow constraints, risks, blockers, candidate first changes, and the safe proof path. It moves the conversation from opinion to evidence without granting automated access, triggering hosted scanning, publishing PRs, or mutating a customer repo.
Product loop
Assessment-to-operating-model path
Choose first proof
The assessment identifies blockers, risks, missing evidence, and one safe bounded change to try first.
Run First Governed Change
The SDF CLI runs the local loop through scoped intent, acceptance criteria, one evidence.md archive, verification results, limits, and human review.
Adapt Team Operating Model
If the proof is useful, the operating model is adapted to the customer's repo, stack, review process, playbooks, and risk profile.
Proof so far
Current progress is visible and evidence-led.
Public GTM proof
This site, assessment request capture, repo-context handoff, confirmation flow, and revisit path are live public GTM surfaces.
SDF CLI dogfood
Current SDF work is dogfooded across sdf-cli, GTM, and Explore My Profile, keeping proof tied to the shipped CLI and live receiver use.
Durable evidence model
Each governed change keeps one receiver-owned evidence.md archive with guidance, verification truth, limits, and checked reviewer handoff context.
Local reviewer handoff
The reviewer handoff is generated and checked locally from evidence; SDF does not automatically publish PRs, approve, merge, repair, deploy, or release.
Agent-surface breadth
Controlled runs have covered local and cloud agents, keeping the proof focused on the workflow rather than one tool.
Research Lab now public
The Research Lab makes the learning loop visible while keeping private method mechanics and customer-specific details out of first-touch copy.
Expansion path
Customer value compounds when the proof becomes the operating model.
The First Governed Change is not the end state. It is the proof loop that lets a team see whether governed AI-assisted delivery feels useful in real review.
From there, the Team Operating Model can become the team's repeatable way to route AI-assisted work through scope, evidence, verification, limits, and human review.
Unknown fit → assessment → First Governed Change → Team Operating Model → optional support
Known change → bounded proof → review evidence → adoption decision
Why this team
Founder-market fit: governance from the full SDLC.
Software Dark Factory comes from 20+ years of hands-on startup engineering and from building real agent-first workflows in Explore.
The operating model was shaped through real product builds, public proof projects, and playbook-led engineering practice used under live delivery pressure.
Explore was the proof ground; Software Dark Factory productizes the governance layer extracted from that work.
Founder memo
Read the founder-market-fit memo behind the governance thesis.
Read the founder memoExplore proof ground
Explore remains the original proof ground for agent-first workflow and product discipline.
View ExploreFollow the founder's work on agentic engineering and full-SDLC governance.
Connect on LinkedInBusiness machine
Business model: assessment wedge to operating model.
The first commercial product is trust: an evidence-backed readiness assessment that shows what is ready, risky, missing, and safe to try first.
Revenue can expand when the First Governed Change is useful: Team Operating Model adaptation, team playbooks, review conventions, and optional ongoing support. Managed or licensed paths remain future direction, not a shipped public tier.
Business machine
Assessment-to-product ladder
Founder-led authority
Free readiness check
Founder-led assessment
First Governed Change
Team Operating Model
Optional ongoing support
Future managed or licensed paths only where proven and supported by product direction
Future compounding
Engineering is the first wedge because review evidence is immediate.
Governance defines how work should enter review. Assurance is the evidence that it did.
Repos, PRs, CI, and review gates make the problem concrete. If the governed delivery path proves useful in engineering, the same principle can later inform broader knowledge-work operations without claiming that future layer is shipped today.
Explore the operating model thesis →Investor materials
A compact briefing set.
Investor deck
The deck covers the market shift, SDF CLI product mechanism, readiness wedge, First Governed Change proof, commercial path, proof so far, and current limits.
Download investor deckAssessment journey
High-level view of assessment, one First Governed Change, Team Operating Model adaptation, and optional support without exposing private method mechanics.
View assessment journeyFounder memo
Short founder-market-fit memo connecting full-SDLC operating experience, Explore, and the governance thesis.
Read founder memoThe Operating Model
Quiet strategic reference on how governance can become a mission-led operating model without claiming that future layer is productized today.
Read the operating modelStage discipline
What is not being claimed yet.
The current product motion is local-first, operator-assisted, and human-reviewed. SDF makes AI-assisted work reviewable; it does not automate trust.
Those limits are intentional. They keep the public story grounded while the product proves repeatable customer value.
- No automatic PR publication, approval, merge, repair, deployment, or release.
- No self-serve assessment or hosted enforcement claim yet.
- No dependable automatic AI usage or cost capture.
- No correctness certification, security certification, or measured-savings claim.
- No universal repo coverage or production/customer governance claim.
- Managed SDF remains future direction, not a shipped tier.
The ask
Pre-seed capital, design-partner introductions, and sharp early advisors.
The immediate objective: prove the Assessment to First Governed Change to Team Operating Model path with early engineering teams, turn the assisted journey into repeatable product surface, and package the operating model around real reviewer evidence.
If you work with engineering-led companies that want AI speed without lowering the quality bar, this is the right conversation to have early.