How we work
The delivery process, written down
Seven phases with explicit entry and exit criteria, two-week sprints producing a deployable increment in your environment, a written definition of ready and definition of done, change control with a costed impact assessment, quality gates enforced in the pipeline, and thirty days of hypercare after go-live. All of it running in your tools, not ours.
- Phase gates with written entry and exit criteria, not milestone theatre
- A deployable increment every two weeks, demoed live and recorded
- Defect versus change decided by a written acceptance criterion
- Thirty days of hypercare with the same team, not a support handover
Process at a glance
- Sprint length
- Two weeks, or your existing cadence
- Increment
- Deployable, in your environment, every sprint
- Reporting
- Weekly written, fortnightly demo, monthly review
- Estimation accuracy
- Within 10 percent on well-understood work
- Change assessment
- Within 3 business days of a request
- Hypercare
- 30 days after every go-live
- Tooling
- Jira or Linear, Confluence or Notion, GitHub, GitLab or Azure DevOps
- Enquiries
- nitesh@redcubical.com
Phases
Seven phases, each with an entry and an exit criterion
A gate is only useful if it can fail. Each of these has criteria written before the phase starts, and we have stopped engagements at a gate rather than proceeding on optimism.
The phases of an engagement
An engagement runs through initiation, discovery, mobilisation, iterative delivery, user acceptance testing, go-live and hypercare, then into steady state. Each gate has written entry and exit criteria agreed in advance. A gate that cannot be failed is decoration, so we name the specific conditions that would stop us proceeding.
| Phase | Typical duration | Entry criteria | Exit criteria | What would stop us proceeding |
|---|---|---|---|---|
| 1. Initiation | 1 to 3 weeks | A described problem, a budget range and a decision-maker identified | Signed statement of work naming scope, exclusions, acceptance approach, commercial model, delivery lead and overlap window | No identified decision-maker on your side, or a scope we do not believe is deliverable within the budget |
| 2. Discovery and architecture | 2 to 5 weeks | SOW signed, access to relevant systems and people granted, existing documentation shared | Requirements elaborated to testable acceptance criteria, architecture decided and recorded, risk register populated, delivery plan with gates, revised estimate as a range | Discovery revealing the scope is materially different from the assumption. We re-plan or stop rather than absorb it silently |
| 3. Mobilisation | 10 working days | Delivery plan agreed, team named, your access provisioning under way | Team onboarded, environments and pipeline running, definition of ready and done agreed, reporting cadence live, first commit merged | Environment or access blockers we cannot work around. We will pause billing rather than bill an idle team |
| 4. Iterative delivery | Variable | At least one sprint of backlog meeting the definition of ready | All in-scope acceptance criteria met and traced, no open critical or high defects, regression suite green, documentation current | Backlog readiness falling below one sprint ahead for two consecutive sprints. That is an escalation, not something to absorb |
| 5. User acceptance testing | 2 to 4 weeks | Feature-complete build in a production-shaped environment, test data ready, your testers identified and available | Agreed exit thresholds met: zero critical, zero high, and an agreed cap on medium defects. Sign-off from your named acceptance authority | Testers not available, or defects arriving faster than they are closed for a full week |
| 6. Go-live | 1 day to 2 weeks | UAT signed off, readiness checklist complete, cutover rehearsed at least once, rollback tested, named rollback decision-maker on the call | Production verification passed, monitoring showing normal ranges, rollback window closed with a documented decision | Any unticked item on the readiness checklist. There is no partial readiness |
| 7. Hypercare | 30 days | Live in production with the delivery team still assigned | Defect arrival rate and performance within agreed thresholds, runbooks validated by your team, exit review documented | Nothing stops hypercare. It extends at our cost if the exit criteria are not met and the cause is ours |
| 8. Steady state | Ongoing or ends | Hypercare exit review signed | Either a support agreement with response targets, or a clean handover with a 30-day question window | We will not leave an ambiguous arrangement where nobody is sure who is on call |
Two things about this table. First, the last column is the one that matters. A gate with no failure condition is a status update. Second, phases four to seven overlap in most engagements: a long programme runs several delivery-UAT-go-live cycles rather than one, each with its own gate.
Sprint mechanics
The two-week cadence, and what ready and done actually mean
Two weeks is long enough to push something demoable through a full quality pipeline and short enough that a wrong turn costs ten working days at most.
How a sprint runs
A two-week sprint with four ceremonies: planning at the start, daily stand-up inside the overlap window, refinement mid-sprint for the following sprint, and demo plus retrospective at the end. The demo shows working software deployed in your environment. If there is nothing to demo, that is the signal to have a difficult conversation in week two rather than month four.
| Ceremony | When | Duration | Who attends | Output |
|---|---|---|---|---|
| Sprint planning | Day 1, start of overlap | 60 minutes | Full team, delivery lead, your product owner | A committed sprint backlog of items meeting the definition of ready, with a stated sprint goal |
| Daily stand-up | Every day, first 15 minutes of overlap | 15 minutes, hard stop | Team and delivery lead. Your product owner optional but welcome | Blockers surfaced and the question queue triaged. Not a status round-robin |
| Backlog refinement | Day 5 or 6 | 45 minutes | Delivery lead, two to three engineers, your product owner | Next sprint candidates meeting the definition of ready, with relative sizing applied |
| Mid-sprint checkpoint | Day 5, in the weekly report | Written, no meeting | Circulated to you | Honest forecast for the sprint goal, with a flag if the commitment is at risk |
| Sprint demo | Day 10, start of overlap | 45 minutes | Full team, your product owner and stakeholders | Working software running in your environment, plus a recording published within 24 hours |
| Retrospective | Day 10, after the demo | 45 minutes | Full team and delivery lead. You are welcome | Two or three dated actions with named owners, published in your workspace |
What is demoed is deployed, in your environment, exercised by a person clicking or calling it. Slides are not a demo. Local-machine screen shares are not a demo. If an item cannot be shown working, it is not done and it does not count towards the sprint.
Definition of ready
An item does not enter a sprint until every line below is true. This is the checklist that prevents the single most common failure in overseas delivery: engineers starting work on something ambiguous while your day is over.
Definition of done
An item is not done until every line below is true. Not "done pending testing", not "done but not deployed". This is the standard we adopt unless yours is stricter, in which case we adopt yours.
- The user or business outcome is stated, not just the mechanism
- Acceptance criteria are written, testable, and specific enough that two people would test them identically
- Dependencies on other teams, third parties or your own systems are identified and confirmed available
- Designs or API contracts exist where the item needs them
- Non-functional expectations are stated where they matter: performance, volume, accessibility, security, data classification
- Edge cases and error behaviour are described, not left to the engineer to invent overnight
- Test data is available, or the route to it is agreed
- The item is small enough to complete inside one sprint. If it is not, it is split
- Relative size has been applied by the engineers who would build it
- No open question that would block a start, and a named person to answer any that arise
- All acceptance criteria demonstrably met, and traced back to the requirement
- Code reviewed and approved by an engineer who did not write it
- Unit tests written, with coverage on changed lines rather than a global percentage target
- Integration or contract tests updated where a boundary changed
- Automated regression suite green in the pipeline
- Static analysis, dependency and secret scanning passed with no unaddressed critical findings
- Accessibility checks passed for user-facing work, against WCAG 2.2 AA as the working standard
- Performance verified against the stated expectation where one exists
- Deployed to a shared environment through the normal pipeline, never by hand
- Documentation and any architecture decision record updated in the same change, not later
- Observability in place: logs, metrics and traces for the new path
- Demonstrated to the product owner and accepted
How we estimate, and how wrong we are
- Relative sizing for sprint work. Story points against a reference item, applied by the engineers who will do the work. Points are for forecasting, never for measuring people. We do not report velocity as a productivity metric and we will not let anyone else do so either.
- Three-point estimation for anything commercial. Optimistic, likely and pessimistic per work package, combined into a range. Quoted as a range, because a single number implies a precision that does not exist.
- Reference class forecasting where we have history. Comparable past engagements beat expert judgement almost every time, and we hold data on our own delivery to draw on.
- Estimates by the doers, reviewed by an architect who was not involved. The reviewer's job is to find the thing the estimator assumed away.
- Contingency disclosed, not buried. On a fixed price we tell you the contingency figure and what it covers, typically 15 to 25 percent by scope clarity.
- Accuracy, honestly. Sprint commitments on well-understood work land within about 10 percent. A three-month project on a familiar stack lands within 15 to 20 percent. Genuinely novel work is minus 25 to plus 50 percent at the outset and narrows sharply after two sprints of real data. Anyone quoting better than that on novel work is guessing with confidence.
- Re-estimation at gates, not silently. If the forecast moves, you hear it in the next weekly report with the reason, not in month five.
Change
Change control, with a worked example
Change control exists so scope can move without trust collapsing. On team-based models the equivalent is backlog reprioritisation at the sprint boundary, which costs nothing commercially.
How change requests work
Any request outside the signed scope is logged, impact-assessed within three business days, priced as effort, schedule and cost, and built only after written approval. Below an agreed threshold, normally two days of effort, your delivery contact approves directly so small changes are not bureaucratic. Nothing is absorbed silently, because silent absorption is how quality quietly degrades.
-
Raised and logged
Either side raises it in your tracker with the requested outcome, the reason and the urgency. Verbal requests are written up by us and sent back for confirmation, because "we agreed it on the call" is the origin of most commercial disputes.
-
Impact assessed
Effort, schedule impact, technical risk, and knock-on effects on already-accepted deliverables. Where a change invalidates completed work, the rework is separated out and named so you can see what the change really costs.
-
Priced with options
At least two options where they exist: full implementation, and a reduced version that protects the date. Where the change could be absorbed by descoping something else, we name the something else rather than leaving you to find it.
-
Approved or declined
Written approval from your named authorised signatory, or from your delivery contact below the agreed threshold. Declining is a normal outcome and does not need a justification.
-
Built and re-baselined
The variation is appended to the statement of work, the plan is re-baselined, the RAID log is updated, and the new date becomes the date. We do not leave two competing versions of the truth in circulation.
| Field | Content |
|---|---|
| Raised by | Client head of IT, on day 4 of sprint 6, in the shared channel and confirmed in writing by us the same day |
| Request | Replace the portal’s email and password login with SAML single sign-on against the client’s Azure Entra ID tenant, for all 4,200 customer users |
| Reason | A security review completed after the SOW was signed now mandates SSO for all externally facing systems before go-live |
| In original scope | No. The SOW specified email and password authentication with multi-factor by one-time code, and expressly excluded federated identity in the exclusions list |
| Effort assessed | 14 engineer-days: 6 for SAML integration and metadata exchange, 3 for user migration and identity linking for existing accounts, 2 for the just-in-time provisioning path, 2 for test coverage, 1 for documentation and runbook |
| Rework created | 3 engineer-days. The accepted login, password reset and account recovery journeys from sprint 3 are superseded and their tests retired. Separated out so the true cost of the change is visible |
| Schedule impact | Nine working days added to the UAT entry date if delivered in sequence. Four days if we accept a temporary reduction in the reporting module scope, which is option B below |
| Risk introduced | Medium. Identity linking for the 4,200 existing accounts is the risk concentration. Mitigated by a dry run against a production data copy and a documented manual reconciliation path for mismatches. A new RAID entry, R-019, was opened |
| Dependency on client | Entra ID application registration, metadata exchange, and a named identity administrator available inside the overlap window for two sessions. Named on day 1 of the change |
| Option A — full, sequential | 17 engineer-days at the SOW day rate. USD 11,900. UAT entry moves from 12 to 21 March. Nothing descoped |
| Option B — full, with a trade | 17 engineer-days, USD 11,900, UAT entry moves to 16 March. The reporting module’s scheduled-export feature moves to phase 2, releasing 5 days |
| Option C — reduced | 8 engineer-days, USD 5,600. SSO for new users only, with existing users kept on password login until a later phase. UAT entry holds at 12 March. Not recommended: it leaves two authentication paths in production, which is the outcome the security review was trying to prevent |
| Recommendation | Option B. It meets the security requirement in full, protects most of the date, and the deferred export feature has no external dependency |
| Decision | Option B approved in writing by the client’s authorised signatory on day 6. SOW variation V-003 issued and countersigned. Plan re-baselined on day 7 and the reporting change reflected in the phase 2 backlog |
The parts of this example that do the work are the separated rework line, the named client dependency, and option C being presented with a recommendation against it. A change request that offers only one price and no trade-off is a quotation, not an impact assessment.
Quality, UAT and go-live
Gates in the pipeline, acceptance testing and readiness for production
How quality is enforced
Quality is enforced by the pipeline rather than by intention. Every change passes static analysis, unit and contract tests, dependency and secret scanning, an infrastructure plan review, integration tests in an ephemeral environment, and progressive deployment with automated rollback. A gate that can be bypassed is not a gate, so bypass requires a second approver and is logged.
| Gate | What it checks | Blocks on | Target duration |
|---|---|---|---|
| Pre-commit hooks | Formatting, lint, secret detection before code leaves the machine | Any finding | Under 10 seconds |
| Static analysis and type check | Lint rules, type errors, complexity thresholds, secret scanning with gitleaks | Any error, and new warnings above the agreed baseline | Under 2 minutes |
| Unit and contract tests | Behaviour of changed code, and service boundaries via consumer-driven contracts | Any failure, or coverage on changed lines below the agreed floor | Under 6 minutes |
| Dependency and licence scan | Known vulnerabilities and licence policy on direct and transitive dependencies | Fixable criticals and highs. Unfixable findings recorded with an expiry date | Under 3 minutes |
| Build and sign | One immutable artefact with an SBOM, promoted unchanged through every environment | Reproducibility failure | Under 5 minutes |
| Infrastructure plan and policy | Terraform plan on the pull request with policy-as-code evaluation | Policy violation. Destructive change to stateful resources needs a second reviewer | Under 3 minutes |
| Integration and end-to-end tests | Revenue-critical journeys in an ephemeral environment seeded with anonymised data | Any failure on a critical journey | Under 15 minutes |
| Accessibility check | Automated WCAG 2.2 AA checks on changed user-facing pages, plus manual keyboard and screen-reader review each sprint | New automated violations. Manual findings are triaged | Under 2 minutes automated |
| Performance smoke | Response time on key endpoints against the agreed budget | Regression beyond the agreed threshold | Under 8 minutes |
| Progressive deployment | Canary or blue-green with automated analysis of error rate, latency and saturation | Automatic rollback on breach, without waiting for a human | Minutes to rollback |
| Post-deploy verification | Synthetic checks on real user journeys and a production smoke suite | Failure triggers rollback | Under 5 minutes |
Automated accessibility tooling catches roughly a third to a half of WCAG issues. The rest needs manual keyboard navigation and screen-reader testing, which we do each sprint on changed journeys. Full WCAG conformance validation requires testing with assistive technologies and expert accessibility review, and we will say so rather than presenting a green automated report as compliance.
User acceptance testing
- You execute it. We prepare the environment, the data and the test cases traced to acceptance criteria. Your people run them, because acceptance by the supplier is not acceptance.
- Production-shaped environment. Anonymised data at production-like volumes. A UAT environment with a thousand rows tells you nothing about a table with fifty million.
- Entry criteria enforced. Feature complete, regression green, no open critical or high defects, test data ready, and your testers actually named and available. Starting UAT without testers wastes a fortnight.
- Defect triage daily inside the overlap window during UAT, with severity agreed jointly rather than assigned by us.
- Exit thresholds agreed in advance: zero critical, zero high, and a named cap on mediums with each one having a documented workaround.
- Sign-off by a named acceptance authority on your side, identified in the SOW at the start rather than found at the end.
- Duration. Two to four weeks for most systems. The variable is your testers' availability, not our defect rate.
- An honest warning. UAT is where insufficiently specified requirements surface. If acceptance criteria were thin, UAT becomes a design workshop and generates change requests rather than defects. That is a discovery failure, and the fix is upstream.
Go-live readiness checklist
Every line ticked, by a named owner, before the cutover call starts. There is no partial readiness.
- UAT signed off by the named acceptance authority, with any open mediums documented with workarounds.
- Cutover runbook written, timed, and rehearsed at least once end to end in a non-production environment.
- Rollback procedure tested, not merely written, with a stated rollback trigger and a time limit on the decision.
- A named rollback decision-maker on the call, with authority to call it without further escalation.
- Data migration dry run completed against a production copy, with row counts and reconciliation checks signed off.
- Monitoring, alerting and dashboards live before traffic arrives, with deployment markers configured.
- Runbooks for the top ten likely operational issues, validated by whoever will be on call.
- Support model agreed: who answers, in which hours, through which channel, with what response target.
- Communication plan for internal stakeholders and end users, including what to say if it goes wrong.
- Third-party dependencies confirmed ready: payment providers, identity providers, partner APIs, DNS and certificates.
- Certificate and secret expiry checked. This is a boring cause of a disproportionate number of go-live failures.
- Capacity headroom verified against expected launch load, with the scaling path tested rather than assumed.
- Legal and compliance sign-off where the release touches personal data or a regulated process.
- A go or no-go decision recorded in writing, with the names of who decided.
Reporting, risk and traceability
What you receive, and how risk is tracked
Reporting is written rather than presented wherever possible, because overlap hours are better spent unblocking than narrating.
What reporting you get
You receive a written weekly report, a fortnightly demo plus recording, a monthly delivery review with trend data, and a quarterly steering pack. Risk and issues live in a RAID log reviewed weekly, and every requirement is traceable from its origin through to the test that proves it and the release that shipped it.
| Artefact | Cadence | Format | Audience | Contents |
|---|---|---|---|---|
| Handoff note | Daily, end of our day | Posted in the shared channel | Your product owner and engineers | What moved, what is blocked, what needs your answer before our next morning |
| Delivery report | Weekly, Friday | Written, one page, in your workspace | Your engineering and product leads | Sprint goal status, completed and in-flight items, burn against plan, new and changed risks, decisions awaiting you, next week plan |
| Sprint demo and recording | Fortnightly | Live session plus a 10 to 15 minute recording within 24 hours | Product owner and stakeholders, including those who cannot attend | Working software in your environment, exercised live. Not slides |
| Retrospective output | Fortnightly | Written, in your workspace | Open to you whether or not you attended | Two or three dated actions with named owners, plus the status of the previous set |
| Delivery review pack | Monthly | 60-minute session plus a written pack | Your engineering manager and product lead | Velocity trend, defect escape rate, cycle time, quality gate trends, budget consumed against plan, team health and roster changes |
| Invoice and budget statement | Monthly, by the third working day | Written, to finance and engineering | Your finance and engineering leads | Effort or seats billed, cumulative spend against the plan or cap, forecast to completion |
| RAID log | Live, reviewed weekly | In your tracker or Confluence, always visible | Anyone on either side | Risks, assumptions, issues and dependencies with owners, dates and mitigation status |
| Traceability matrix | Live, updated per sprint | Generated from the tracker, not maintained by hand | You, your auditors, your QA lead | Requirement to acceptance criterion to test case to test result to release |
| Steering pack | Quarterly | 90-minute session plus a written pack | Your sponsor, Nitesh, delivery lead | Roadmap position, commercial position, team shape, escalated risks, decisions needed from the sponsor |
| Architecture decision records | As decisions are made | In your Confluence or repository | Your engineers, now and in two years | Context, options considered, the choice, the trade-off accepted, who decided and when |
Everything on this list lives in your workspace. There is no Redcubical portal to log into, no separate status system to reconcile, and nothing you lose access to when the engagement ends.
Risk and issue management: the RAID log
- Risks are things that might happen. Each has an owner, a probability and impact rating, a mitigation, a trigger that would turn it into an issue, and a review date.
- Assumptions are things we have taken as true without proof. Each has a validation date and an owner, because an unvalidated assumption is a risk wearing a disguise. This is the column most projects leave empty and the one that causes the most damage.
- Issues are risks that materialised, or problems that arrived without warning. Each has an owner, an impact, an action and a target resolution date.
- Dependencies are things we need from you or from a third party. Each has a named owner on the responsible side, a needed-by date, and the schedule consequence of it slipping. Client-side dependencies are the largest single cause of delay we see, which is why they are tracked with the same rigour as risks.
- Reviewed weekly by the delivery lead, with anything new or changed appearing in the weekly report. Not a document written at kick-off and revisited at the post-mortem.
- Visible to both sides always, in your tooling. There is no internal version with the real risks in it.
- Escalation is automatic. Any risk rated high impact and high probability, or any issue open beyond its target date, goes to the monthly review and into the steering pack.
Requirements traceability
Traceability is what lets you answer "who asked for this, why, and how do we know it works" eighteen months later. It is generated from the tooling rather than maintained as a spreadsheet, because hand-maintained matrices are always out of date.
- Origin recorded. Every requirement carries its source: a named stakeholder, a regulatory obligation, or a specific SOW clause.
- Requirement to acceptance criteria. One to many, each criterion testable independently.
- Acceptance criteria to test cases, automated where possible, with the test identifier linked in the ticket.
- Test cases to results, pulled from pipeline runs rather than transcribed.
- Requirement to commits and pull requests, through ticket references enforced by a commit convention.
- Requirement to release, so you can answer which version first contained a given behaviour.
- Change requests linked to the requirements they altered, with the superseded version retained rather than overwritten.
- Why it matters commercially. On regulated work an auditor will ask for exactly this chain. On unregulated work it is what turns a defect argument into a two-minute lookup.
After go-live
Hypercare, retrospectives, and working in your tools
What happens after go-live
Every go-live is followed by 30 days of hypercare: tightened response targets, daily defect triage inside the overlap window, and the same delivery team still assigned rather than reassigned to the next engagement. It ends with an exit review against agreed defect-rate and performance thresholds, and it extends at our cost if those are missed for reasons on our side.
| Period | Response target | Cadence | Who is on it |
|---|---|---|---|
| Days 1 to 5 | Critical acknowledged in 15 minutes, high in 1 hour, all others same working day | Daily triage call inside the overlap window, plus a daily written report | Full delivery team, delivery lead on the call every day |
| Days 6 to 15 | Critical acknowledged in 30 minutes, high in 2 hours, others next working day | Daily triage in the shared channel, written report every second day | Full team on the engagement, a named responder rostered each day |
| Days 16 to 30 | Critical in 30 minutes, high in 4 hours, others next working day | Triage twice a week, weekly written report | Reduced team, delivery lead and two engineers, remainder available on call |
| Exit review, day 30 | Not applicable | One session plus a written report | Delivery lead, your product owner and operations lead |
| After exit | Per your support agreement, or none | Monthly service review if a support agreement is in place | Support team, or your own team with our runbooks and a 30-day question window |
Hypercare exit criteria are agreed before go-live: defect arrival rate below an agreed threshold for five consecutive working days, no open critical or high defects, performance within the stated budget, and your team able to execute the runbooks themselves. If the criteria are not met and the cause is ours, hypercare extends at our cost. If the cause is a scope gap or a client-side dependency, we will say so and price the extension.
Retrospectives and continuous improvement
- Every sprint, without exception, even the good ones. The sprint that went well is where you find out why.
- Two or three dated actions with named owners. A retrospective with no actions is a failed retrospective, not a sign of a healthy team.
- Previous actions reviewed first. Nothing kills the exercise faster than actions that never get done.
- Published whether you attend or not. The output goes into your workspace. There is no internal version.
- Blameless by design. A defect that reached production is a gap in the system that permitted it, not a person who made a mistake. The question is which gate should have caught it.
- Quarterly delivery health review across all our engagements internally, looking at defect escape rate, cycle time, change failure rate and estimate accuracy. Patterns across clients get fixed as process changes, and we tell you when a change came from another engagement's lesson.
- Post-incident reviews within five working days, written, with a timeline, contributing factors and dated actions. Shared with you in full, including the parts that reflect badly on us.
Tooling: we work in yours
This is a firm principle, not a preference. Every artefact on this page lives in your systems, so you never lose visibility and you never lose access.
- Backlog and tracking: Jira or Linear. Also Azure DevOps Boards, Shortcut, Asana or GitHub Projects where that is what you use.
- Documentation and decisions: Confluence or Notion. Architecture decision records in the repository where your engineers prefer that.
- Communication: Slack or Microsoft Teams, in your workspace as guests. Not a Redcubical channel you are invited into.
- Source and pipelines: GitHub, GitLab or Azure DevOps, in your organisation, from the first commit.
- Design: Figma, in your file structure.
- Observability and incidents: whatever you run. Datadog, Grafana, New Relic, CloudWatch, PagerDuty, Opsgenie.
- What we bring: our own internal quality checklists, estimation reference data and runbook templates. Everything produced from them belongs to you.
- What we will not do: maintain a parallel status system, ask you to log into a supplier portal, or keep the real project state anywhere you cannot see it.
- If you have no tooling yet, we will set up Linear, Notion and GitHub in your name, on your accounts, on your billing. Not ours.
The uncomfortable part
Where our process is deliberately heavier than a startup’s, and where we flex it
Why the process is heavier
Our process is heavier than a co-located startup team needs, in four specific places: written acceptance criteria, decision records, formal change control, and traceability. Each exists because of the time-zone boundary. A team sharing a room can hold context in conversation. A team nineteen hours out of sync cannot, and the cost of pretending otherwise is rework.
| Practice | A co-located startup | Us | The reason |
|---|---|---|---|
| Acceptance criteria | Often a conversation and a ticket title | Written, testable, agreed before build starts | Ambiguity discovered at 03:00 your time costs a full day. Written criteria are the only thing that removes that cost |
| Decision records | Held in the team’s shared memory | Written at the time, with options rejected and why | Your engineers inherit this codebase. So does whoever replaces one of ours. Shared memory does not survive either event |
| Change control | Reprioritise in the stand-up | Written request, impact assessment, priced options, written approval | You cannot see the team working. Without a visible mechanism, scope movement looks like either drift or overcharging |
| Traceability | Rarely maintained at all | Generated from tooling, requirement to release | It is what settles a defect-versus-change disagreement in two minutes rather than two meetings, and what an auditor asks for |
| Written status reporting | A conversation in the office | A written weekly report and a daily handoff note | You are asleep for most of our working day. The alternative to writing is you finding out later |
| Definition of done | Understood, mostly, differently by each person | Explicit, checked per item, non-negotiable | Different unstated standards across a distance produce work that has to be redone. This is the cheapest document in the engagement |
The overhead is real. We estimate this discipline costs roughly 8 to 12 percent of engineering capacity in writing and coordination. It is worth it because the rework it prevents is considerably larger than that, and because it is what makes attrition and handover survivable. We are not claiming it is free.
Where we flex, and how far
- Ceremony load. On a two or three-person engagement we drop formal planning and refinement and run a 20-minute weekly session instead. Stand-up drops to three days a week if you prefer. The demo stays.
- Reporting formality. Below about USD 60,000 of engagement value, the weekly report becomes a short structured message in the channel rather than a document, and there is no monthly pack unless you want one.
- Phase gates. On engagements under six weeks we collapse initiation, discovery and mobilisation into a single one-week phase with one gate.
- Change control threshold. Set as high as you like. Some clients set it at five days of effort so almost nothing goes through formal variation. That is your call and we will follow it.
- Sprint length. One week for very short engagements, Kanban with a weekly demo for support and platform work, three weeks where your stakeholders genuinely cannot review more often.
- Estimation formality. On a dedicated team where you own priorities, we can drop story points entirely and report on cycle time and throughput instead. Several of our longest engagements run this way.
- UAT. Can be folded into sprint acceptance for internal tools with a single stakeholder, rather than run as a separate phase.
What we will not flex, whatever the engagement size
- Testable acceptance criteria before build. Without them there is no definition of defect, and the engagement will end in a commercial argument.
- The definition of done. It can be shortened by agreement. It cannot be silently ignored under schedule pressure, because that is exactly when it matters.
- Quality gates in the pipeline. Bypass needs a second approver and is logged. A gate that can be skipped quietly is not a gate.
- Decision records for material choices. Non-negotiable. This is the artefact that has saved the most client money in our experience, and it costs ten minutes.
- A deployable increment demonstrated regularly. The frequency can change. The existence cannot. This is the mechanism that lets you cancel in month two instead of month seven.
- Blameless post-incident reviews shared in full. Including the parts that reflect badly on us.
The limitation of any process
Process reduces variance. It does not create capability, and it cannot substitute for judgement. A well-run process with the wrong architecture produces a well-documented failure on schedule. Our phase gates are designed to catch that at discovery and at the architecture record, which is why an architect reviews every estimate and every material design decision. But if you are choosing a supplier, weight the engineering judgement of the people you meet more heavily than the process documentation you are shown. Ours is on this page precisely so you can spend the conversation on the harder question.
Answers
Delivery process questions
Do you work in your process or ours?
Yours. We work in your Jira or Linear, your Confluence or Notion, your Slack or Teams, your repositories and your pipelines. Where you have a definition of done, a sprint length and a release process, we adopt them. What is on this page is our default for clients who do not have an established process yet.
Why two-week sprints rather than one week or a continuous flow?
Two weeks is long enough to deliver something demoable through a full quality pipeline and short enough that a wrong direction costs at most ten working days. One-week sprints spend too much of the cycle in ceremony. Continuous flow works well for mature teams and we run Kanban on support and platform work, but a fixed cadence gives an overseas engagement a reliable demo and reporting heartbeat.
What is the difference between a defect and a change?
A defect is behaviour that does not meet a written acceptance criterion. A change is a new or altered acceptance criterion. That distinction is why we insist on testable acceptance criteria before build: without them, every disagreement becomes a negotiation about whether you should be charged.
How do you estimate, and how accurate is it?
Relative sizing in story points for sprint-level work, and three-point estimation converted to a range for anything commercial. On well-understood work our sprint commitments land within about 10 percent. On genuinely novel work the honest range at the outset is minus 25 to plus 50 percent, and we quote it as a range rather than a single number.
What reports do we receive and how often?
A written weekly report every Friday covering progress, burn, risks and decisions awaiting you. A fortnightly demo of working software plus a recording. A monthly delivery review with trend data on velocity, defect escape rate and budget. A quarterly steering pack. All in your workspace, no separate portal.
What happens in hypercare?
Thirty days after go-live with tightened response targets, daily defect triage inside the overlap window, the delivery team still on the engagement rather than reassigned, and daily then weekly written reports. It ends with an exit review confirming defect rates and performance are within agreed thresholds before we transition to steady state.
Is your process not too heavy for a small team?
Parts of it are, deliberately, and parts of it flex. We hold firm on traceable acceptance criteria, decision records, quality gates in the pipeline and the definition of done, because those are what make a time-zone boundary survivable. We flex the ceremony load, the reporting formality and the phase-gate paperwork down to almost nothing on small engagements.
Who runs the retrospective and do we see the output?
Our delivery lead runs it, the whole team attends, and you are welcome. The output is two or three dated actions with named owners, published in your workspace whether you attend or not. If a retrospective produces no actions we treat that as a failed retrospective rather than a good sign.
See the process applied to your engagement
Send the problem and the constraints. You get a call with the architect who would lead the work, and a written plan showing the phases, the gates, the reporting you would receive and the trade-offs we would recommend, inside one business day.