SEC.00 — ENGINEERING MODEL
How we work
Seven phases, each with named activities, named deliverables and a duration band. Durations are bands because they depend on your domain — but the artefacts do not change.
SEC.01 — PROCESS
From first argument to third year
Every phase ends with something you can hold, not a status update.
01
Discovery & product strategy
2–4 weeksUnderstand the problem well enough to argue about the solution, and write the requirements down in a form that survives a change of team.
Activities
- Stakeholder and user interviews
- Domain modelling workshops
- Requirement specification to IEEE-830 / ISO 29148 structure
- Scope shaping and risk register
You receive
- Requirement specification
- Prioritised scope with a shipping sequence
- Risk register
02
Architecture & planning
1–3 weeksDecide the shape of the system before writing application code, and record the decisions so they can be revisited with their reasoning intact.
Activities
- Data and domain modelling
- Service and module boundaries
- Architecture decision records
- Delivery plan and environment topology
You receive
- Documented schema with constraints
- Architecture decision records
- Delivery plan with sequencing
03
Design
2–4 weeksDesign the interface as a system of tokens and components, so the hundredth screen costs less than the tenth.
Activities
- Interaction design for the core flows
- Design tokens and component library
- Accessibility review against WCAG 2.2 AA
- Prototype of the flows that carry the most risk
You receive
- Design system with tokens
- Interactive prototype
- Accessibility notes
04
Build
Ongoing, in 2-week iterationsShip working software in iterations, each one demonstrable and each one deployed to a real environment.
Activities
- Two-week iterations with a working demo at the end of each
- Typed implementation, front to back
- Automated tests concentrated on domain logic
- Continuous deployment to a staging environment
You receive
- Working software every iteration
- Access to the repository from day one
- Iteration notes and updated roadmap
05
Quality & hardening
1–3 weeksFind the failures that only appear under real data, real load and real users before those users do.
Activities
- End-to-end coverage of business-critical flows
- Load testing against stated volume assumptions
- Security review and dependency audit
- Accessibility and performance audit
You receive
- Test suites in the repository
- Audit reports with remediation
- Performance baseline
06
Launch
1–2 weeksGet to production with a way back if something is wrong.
Activities
- Production environment provisioning
- Data migration with a rehearsed rollback
- Monitoring, alerting and error tracking
- Handover documentation and team walkthrough
You receive
- Live system
- Runbook and rollback plan
- Monitoring dashboards
07
Operate & evolve
OngoingKeep the system healthy and keep improving it — most of a product’s life is spent here.
Activities
- Dependency and security update cadence
- Incident response against an agreed severity ladder
- Iterative delivery against a living roadmap
- Quarterly architecture review
You receive
- Support agreement with response targets
- Release notes per iteration
- Maintained documentation
SEC.02 — DELIVERY
Multi-location delivery
Distributed delivery fails when it becomes a relay race: one team stops, writes nothing down, and another starts by guessing. We structure it so the written artefact is the handoff.
DELIVERY SPEC
- ANCHOR
- Every team is anchored to Colombo (UTC+5:30). One timezone owns the schedule, so there is never a question of whose morning a decision waits for.
- OVERLAP
- Full mornings overlap with Europe and the Middle East, and early hours reach US East. Standing meetings are placed inside real overlap, not at somebody’s midnight.
- HANDOFF
- Each day ends with a written handoff in the repository: what moved, what is blocked, and what the next person should pick up. If it is not written, it did not happen.
- DOCUMENTATION
- Documentation currency is a merge condition. A pull request that changes behaviour without changing the docs does not merge.
- ACCESS
- Clients hold their own repository, cloud accounts and secrets from the first commit. Nothing routes through us that you could not take over tomorrow.
SEC.03 — APPLIED AI
Where we use it, and where we do not
AI is a tool with a cost and a failure mode, and it belongs where those are acceptable. Being specific about where we do not use it is the more useful half of this.
Where we use it
- Retrieval and summarisation over a system’s own documents, where a wrong answer is visibly a suggestion
- Draft generation inside delivery: test scaffolds, migration drafts, review notes — always read by an engineer before merge
- Assistive product features that have a deterministic fallback when the model is unavailable or wrong
Where we deliberately do not
- Anything that computes money, tax or a balance. Those paths stay deterministic and testable.
- Authorisation and access decisions
- Irreversible actions without a person confirming them
- Generated code merged without review, however convincing it looks
SEC.04 — ENGAGEMENT
Three ways to work together
The difference is who holds the roadmap, not how good the engineering is.
01
Product build
A defined product, taken from discovery to launch by us, against an agreed scope and sequence.
Best for Founders and companies with a product to ship and no in-house engineering team.
02
Dedicated product team
An embedded team working as part of yours, on your roadmap, with your rituals and your repository.
Best for Companies with a product organisation that needs to add capacity without losing coherence.
03
Technical partnership & advisory
Architecture review, delivery process, and the specific hard decisions — without us holding the keyboard.
Best for Teams that can build but want a second opinion on the decisions that are expensive to reverse.
Start with a conversation about the problem
Not a proposal, not a pitch deck. Tell us what you are building and we will tell you what we would do first.