Delivery Methodology
How INX Delivers
Every INX engagement follows the same five-phase delivery model: Discovery, Architecture, Engineering, Deployment, and Optimisation. The model is adapted to context — never abandoned for convenience.
The process exists because engineering quality is not a property of individual engineers — it is a property of the system in which they work. A clear process produces predictable outcomes. The absence of process produces unpredictable ones.
Discovery
Understanding before designing
Discovery is a structured, billable engagement — typically two to four weeks — that produces the architectural and commercial foundation every subsequent phase builds on. No engineering work begins until this phase is complete.
What Happens
- Stakeholder interviews to understand business and operational requirements
- Technical audit of existing systems where applicable
- Architecture requirements documentation
- Risk identification and mitigation planning
- Integration requirements mapping
- Milestone and timeline sequencing
Deliverable
A Technical Specification document — the contractual reference for all subsequent engineering work. Scope, architecture, milestones, and acceptance criteria are defined here.
Systems built without understanding the operational context they serve have a structural disadvantage no amount of engineering competence can overcome. Discovery exists to close that gap before the architecture is fixed.
Architecture
Designing the system before building it
Architecture is treated as a formal engineering deliverable — not an implicit set of decisions made during coding. The architecture phase produces a complete technical design against which engineering is then executed.
What Happens
- Data model design and schema definition
- API contract specification (REST, GraphQL, or gRPC)
- System boundary and service decomposition design
- Third-party integration architecture
- Scalability and performance constraint modelling
- Security architecture and access control design
Deliverable
An Architecture Design Document extending the Technical Specification — providing engineers with unambiguous direction on data structures, component boundaries, and integration contracts.
Architecture decisions are the most expensive to reverse. Making them explicitly, on paper, before production code is written eliminates the class of technical debt that accumulates when design happens implicitly during development.
Engineering
Senior-only delivery against a defined specification
Engineering proceeds against the Technical Specification and Architecture Design Document. Progress is transparent, code quality is non-negotiable, and every feature is delivered with tests, documentation, and code review.
What Happens
- Feature development by senior engineers against the agreed specification
- Mandatory peer code review for every pull request
- Automated test coverage as a delivery requirement
- Continuous integration against a shared trunk
- Weekly progress reporting against milestones
- Architecture deviation flags — any spec change is documented and approved
Deliverable
A production-ready codebase with documented test coverage, passing CI, and code reviewed against the specification. Deployment-ready artifacts produced at each milestone.
Engineering is not where design decisions should be made. When engineering proceeds against a clear specification, delivery is predictable and quality is measurable — not a matter of individual judgement.
Deployment
Handing over operating systems, not code repositories
Production deployment is treated as a complete engineering task — not a handoff. INX deploys with full observability tooling, runbooks, and documented operational procedures.
What Happens
- Deployment pipeline engineering (CI/CD to production)
- Observability setup: metrics, distributed tracing, structured logging
- Alerting and on-call runbook documentation
- Database migration and data validation in production
- Security review and vulnerability scanning
- Post-deployment smoke testing and validation
Deliverable
A production system with documented operational procedures, configured alerting, and a handover package sufficient for any competent engineering team to operate.
Software that cannot be reliably deployed, monitored, and recovered from failure is not production-ready regardless of its code quality. Deployment engineering is treated with the same seriousness as feature engineering.
Optimisation
Measuring production behaviour against operational requirements
After deployment, INX continues to monitor and optimise the system under real production load. The warranty period provides structured post-delivery support before transition to ongoing support or handover.
What Happens
- Production performance measurement against specification targets
- Query and API endpoint optimisation under load
- Bottleneck identification and resolution
- Dependency and security patching
- User feedback integration and product iteration
- Transition planning to ongoing support or internal team handover
Deliverable
A validated production system performing within specified parameters, with documented performance baselines and a clear operational handover.
Production behaviour is the only reliable measure of engineering quality. Systems that perform well in staging but fail under real load are a systemic failure of the delivery process — not an acceptable outcome.
Quality Controls
Embedded at every phase
Specification lock
No feature is built without a specification entry. Scope changes require documented amendment.
Peer code review
Every production merge requires a second-engineer review. No exceptions.
Test coverage gate
Automated test coverage is checked at each milestone. Untested code is not shipped.
Architecture deviation protocol
Any departure from the architecture specification is flagged, documented, and approved before proceeding.
Weekly milestone reporting
Progress against milestones is reported transparently, including blocked items and timeline risks.
Post-deployment warranty
A structured warranty period follows all project-based engagements.
Begin with a discovery conversation
Discovery engagements can begin within one week of initial alignment. Submit an inquiry and our leadership team will respond within two business days.