中文/EN
Home / Methodology

Delivery methodology

How a vague business requirement becomes a system that runs for years and that your team can fully take over. Seven stages, each with a principle, how we work, what you receive, and how it is accepted.

7 stages24h written proposal100% source & docs handed over
01

Scoping

A requirement you cannot state is a requirement you cannot build

How

  • Business interviews: who does what in which situation, and where it breaks
  • Redraw the current process exactly as it is, including spreadsheets, group chats and phone calls
  • Roles and boundaries: who initiates, who approves, who only reads, who owns the data
  • Define success: the observable changes that prove it worked

Deliverables

  • Requirement spec
  • As-is process map
  • Role & permission matrix
  • Draft acceptance criteria

Accepted when

Scope list confirmed in writing; later changes go through a change order

02

Solution & architecture

Architecture decides most of your cost later

How

  • Prototype the critical flows and walk real data through them before deciding
  • Present a comparison table for technology choices (cost, risk, maintainability, lock-in), not one answer
  • Fix the data model and interface boundaries first, to stop late cross-contamination
  • Set non-functional targets up front: concurrency, latency, availability, data volume
  • Decide the deployment shape too: public cloud, on-premise, or hybrid

Deliverables

  • Solution brief
  • Architecture diagram
  • Technology comparison
  • NFR table

Accepted when

Review passed, scope and timeline locked, no casual changes afterwards

03

Engineering & code quality

You are buying a system, not a set of pages that happen to work

How

  • Coding standards and naming conventions live in the repository
  • Every merge goes through code review, and the author cannot review their own change
  • Static analysis and dependency vulnerability scanning run in CI and block merges
  • Consistent commits and branches, so history stays traceable
  • Unit tests on critical modules, integration tests on core paths

Deliverables

  • Source repository
  • Engineering standards
  • Scan & review records
  • Test coverage

Accepted when

Every merge passes scanning and review; the gate is enforced, not optional

04

Testing & acceptance

Every stage must be acceptable, and nothing advances until it is

How

  • Unit, integration and end-to-end layers, with end-to-end covering the main journeys
  • A test case library mapped one-to-one to requirements
  • A pre-production environment mirroring production, and a full run before go-live
  • An acceptance checklist per milestone, ticked line by line
  • If acceptance fails we rework, and rework is not an extra charge

Deliverables

  • Test report
  • Test case library
  • Milestone acceptance checklist
  • Pre-production rehearsal record

Accepted when

You confirm each milestone in writing; only then does the next stage and the next payment start

05

Security & data

Least privilege, and every action traceable

How

  • Least-privilege roles by default
  • Sensitive fields encrypted at rest and in transit; no secrets in the repository
  • Audit logs for key actions: who, when, what changed
  • Backup policy plus scheduled restore drills (an untested backup is not a backup)
  • On-premise deployment available when data must not leave your network

Deliverables

  • Permission matrix
  • Audit design
  • Backup & restore drill record
  • Security baseline checklist

Accepted when

Privilege-escalation tests pass; a restore drill succeeds and is recorded

06

Go-live & handover

You are buying the ability to run it, not just the system

How

  • Deployment document covering environment, steps and rollback
  • Runbook covering daily checks, common faults and what to do
  • Accounts, cloud resources, domains and keys all transferred into your name
  • One training session for your team, with a written record
  • A real release rehearsed together with your team

Deliverables

  • Deployment guide
  • Runbook
  • Training record
  • Source code & IP

Accepted when

Your team performs a release on their own, with us on call

07

Care & continuous improvement

Go-live is the beginning

How

  • One year of care included: defect fixes, small changes, backups, checks, security updates
  • Incidents handled by severity, with response times written into the contract
  • Scheduled checks with a report; performance and security updates kept current
  • No silent changes: everything goes through a change order with impact noted in advance
  • Every incident gets a review, and the improvements get closed

Deliverables

  • Response commitment
  • Check reports
  • Change log
  • Incident reviews

Accepted when

Every incident review produces improvements, and those improvements get closed

CHECKABLE

The standards, line by line

These are the lines we hold ourselves to on every project. They are checkable, and they go into the contract.

  • Coding standards live in the repository; the author never reviews their own change
  • Static and vulnerability scanning run in CI and block merges
  • End-to-end tests cover the main journeys, mapped to requirements
  • Every milestone has a written acceptance checklist; nothing advances without it
  • Rework and defect fixes are not extra charges
  • Least-privilege roles, and privilege-escalation tests must pass
  • Backups are restore-drilled on a schedule; an untested backup is not a backup
  • Logs record who changed what and when — auditable and traceable
  • Source, docs, accounts and keys are all transferred into your name
  • Changes go through a change order with impact noted in advance — nothing ships silently
  • One year of care: defect fixes, small changes, backups, checks, security updates
  • Severity-based incident response, with a review and closed improvements

Put these standards to work on your process.

Walk us through your process once. We will run it through the seven stages and give you a written conclusion within 48 hours.

Quality & after-sales