Our standards

Know what goes into the delivery.

These practices guide our work. Your engagement agreement records the deliverables, acceptance criteria, ownership terms, and support commitments for your project.

The path to release

Built is just the beginning.

01 Architecture & code review
02 Security & access checks
03 Workflow & acceptance tests
04 Release approval & handoff
Review and testing are part of the delivery plan.

Ownership and handoff.

The agreement defines ownership of custom deliverables and identifies third-party licenses. The handoff includes source code, documentation, and an inventory of the accounts and services needed to run the system.

Security review.

  • Review authentication, access permissions, payment handling, and sensitive data flows.
  • Check for exposed secrets, vulnerable dependencies, and relevant code security issues.
  • Keep credentials out of source code and document the configuration.
  • Record findings and unresolved limitations; scope specialist assessments when needed.

Testing and acceptance.

Define acceptance criteria during discovery. Test business rules, critical workflows, failure cases, and integrations. Required checks must pass before release, with review and testing included in the agreed schedule.

AI-assisted development.

AI can help produce drafts and repetitive implementation. Engineers remain responsible for the architecture, review, test coverage, and acceptance of changes. A working demonstration alone is not the release criterion.

Data handling.

Agree environments, access permissions, and any use of third-party tools before handling client data. Use synthetic or minimized data where possible. Document retention, deletion, and ongoing access as part of handoff.

Documentation and support.

Provide architecture notes, deployment instructions, routine operating tasks, and known limitations. Fixed-scope production builds include 30 days of defect coverage; maintenance and ongoing support have a separately agreed scope.

Why review matters

Research informs the process.

Studies of AI-generated code reinforce the need to test security as well as functionality. Their results describe particular tasks, models, and evaluation methods; they do not establish a failure rate for all software or predict a specific project’s outcome.

SusVibes · December 2025

In the linked version of the study, SWE-agent with Claude 4 Sonnet passed functional tests on 61% of 200 security-relevant tasks. It passed both functional and security tests on 10.5%. The tasks were selected from previously vulnerable implementations.

Read the original paper, version 1

Veracode · 2025 report

Across more than 100 models and 80 coding tasks, 45% of generated samples failed the study’s security checks. This is a result for that test set, rather than a measure of all deployed applications.

Read Veracode’s findings

Practical questions.

Does scanning guarantee the software is secure?

No single scan or review can guarantee that. We combine design review, automated checks, targeted testing, and documented findings. Additional independent assessment can be included in the scope.

Can another developer maintain the software?

The handoff is designed to support that: source code, architecture notes, configuration details, and operating instructions. Third-party services and licenses are identified so ongoing dependencies are clear.

How do changes affect a fixed price?

The written scope and acceptance criteria define the commitment. New requirements are assessed and agreed before implementation, including any effect on price or timing.

Discuss your project