How we build

Eight stages, and the same eight stages run our business.

This is not a diagram made for a website. The lifecycle below is a single object in our codebase: this page, our CRM pipeline and the phase label in your client portal all read from it. That is why what we sell and what we deliver cannot quietly diverge.

Explore

Understand the idea and whether we are the right team for it.

Typical duration: 1–2 weeks
Your part: Share the problem, the timeline pressure and any hard constraints. Nothing needs to be polished.

A short, unpaid conversation to understand the problem, the constraints and the outcome you need. We use it to decide honestly whether NELLA Labs is a good fit, and to tell you if someone else would serve you better.

What happens

Project Architect session or a direct conversation
Problem framing and outcome definition
Constraint capture: regulatory, budget, timeline, internal capacity
Fit assessment against our capability and current capacity
Preliminary architecture direction and delivery-path options

What you get

Project Canvas — an editable one-page summary of problem, users, outcomes and scope
Indicative investment band and delivery-path recommendation
A written note on what we would need to learn before committing to numbers

We do not move on until

Both sides agree the problem is worth solving and we are a credible team for it
An owner and a decision-maker are identified on the client side
A discovery scope and commercial model are agreed in principle

Shape

Paid discovery that replaces assumptions with evidence.

Typical duration: 2–6 weeks
Your part: Give us access to the people who know: users, operations, existing engineers, compliance. Attend the workshops.
Portal phase: discovery

Discovery is where the cost of a project is actually decided. We investigate the real users, the real systems and the real data, then produce a scope and architecture we are prepared to be held to.

What happens

Stakeholder and user interviews
Existing system, data and integration audit
Service blueprint and journey mapping
Architecture options with trade-offs and costs
Security, privacy and compliance screening, including DPIA triage
Release strategy: what belongs in an MVP and what deliberately does not
Estimation with explicit assumptions and ranges

What you get

Discovery report with evidence and recommendations
Prioritised capability map across MVP, Release 1 and Later
Architecture decision records for the choices that matter
Risk, assumption and dependency register
Delivery plan, team shape and costed proposal

We do not move on until

Scope for the first release is agreed and written down
Architecture direction is documented with recorded trade-offs
Commercial model, budget and timeline are signed off

Design

Make it real enough to test before it is expensive to change.

Typical duration: 3–8 weeks, usually overlapping Build
Your part: Review prototypes with real users where possible. Make decisions at the review points.
Portal phase: design

We design the product as a working system, not a slide deck: flows, states, content, accessibility and a component library engineers can build against directly.

What happens

Information architecture and end-to-end flows
Interaction design including empty, loading, error and permission states
Interface design and a documented design system
Content design and editorial voice
Accessibility design against WCAG 2.2 AA
Prototype testing with representative users

What you get

Clickable prototype of the critical journeys
Design system with tokens, components and usage rules
Annotated specifications including states and accessibility behaviour
Research findings and the design changes they caused

We do not move on until

Critical journeys are tested and the findings are acted on
The design system covers every component the first release needs
Content for the first release is drafted or has an owner and a date

Build

Iterative engineering with quality automated from day one.

Typical duration: 6 weeks to many months, depending on scope
Your part: Attend demonstrations, accept or reject increments, and keep decisions moving.
Portal phase: build

We build in short increments against a working pipeline. Every increment is demonstrable, tested and deployable — there is no separate "integration phase" at the end.

What happens

Two-week increments with a working demonstration at the end of each
Trunk-based development with peer review on every change
Automated unit, integration, contract and end-to-end tests in CI
Infrastructure as code and preview environments per change
Continuous security and dependency scanning
Observability instrumented as features are built, not retrofitted

What you get

Working software in a real environment after every increment
Test suites and coverage of the behaviour that matters
Infrastructure definitions and environment parity
Living technical documentation and runbooks

We do not move on until

The agreed release scope is built and demonstrated
Automated quality gates pass on the release candidate
Operational documentation exists for everything being launched

Validate

Prove it works — for users, under load, and against attack.

Typical duration: 2–5 weeks
Your part: Run user acceptance testing with real users of the system, and sign acceptance.
Portal phase: validate

Acceptance is evidence-based. We test the product against the criteria agreed in Shape, not against a general feeling that it seems fine.

What happens

Client-run user acceptance testing with structured cases and evidence
Accessibility audit: automated checks plus manual keyboard and screen-reader review
Performance and load testing against agreed budgets
Security testing, and penetration testing before high-risk production use
Data migration rehearsals with reconciliation
Disaster-recovery and restore rehearsal

What you get

UAT results with defect triage and resolution evidence
Accessibility conformance report against WCAG 2.2 AA
Performance report against the agreed budgets
Security findings and remediation record
Signed acceptance record

We do not move on until

Acceptance criteria are met and formally signed
No open critical or high-severity defects or security findings
Rollback and recovery procedures are tested, not merely written

Launch

Go live deliberately, with a way back.

Typical duration: 1–3 weeks plus a 2–4 week hypercare window
Your part: Approve the go/no-go, prepare your users, and staff the hypercare window with us.
Portal phase: launch

Launch is a rehearsed procedure with a named owner, a cutover plan, a rollback path and a period of heightened support afterwards.

What happens

Production readiness review against a written checklist
Data migration and reconciliation
Cutover rehearsal, then cutover
Monitoring, alerting and on-call activation
Team training and handover documentation
Hypercare: elevated support and daily review immediately after launch

What you get

Release record with what shipped, who approved it and how to reverse it
Production runbooks, alert routes and escalation paths
Training materials and recorded handover sessions
Hypercare log and exit report

We do not move on until

The service is live, monitored and meeting its agreed targets
The hypercare period closes with no unresolved critical issues
Support entitlement and escalation routes are active and understood

Grow

Use evidence from real usage to decide what happens next.

Typical duration: Continuous
Your part: Agree the outcome measures, and let the evidence change the roadmap.
Portal phase: grow

After launch the roadmap should be driven by what users actually do. We instrument, measure, experiment and prioritise against outcomes rather than a fixed feature list.

What happens

Product analytics and funnel instrumentation
Experimentation and A/B testing where volumes support it
Conversion, retention and task-completion optimisation
Roadmap delivery in continuing increments
Ongoing accessibility and performance work

What you get

Outcome dashboards tied to the KPIs agreed in Shape
Experiment results and the decisions taken from them
A prioritised, evidence-backed roadmap

We do not move on until

The agreed outcome measures are being reported against
Roadmap priorities are set from evidence rather than opinion

Operate

Keep it secure, available, affordable and improving.

Typical duration: Ongoing, renewed annually
Your part: Agree the service level you need, and attend the quarterly service review.
Portal phase: operate

Software that is not maintained decays. Operate covers monitoring, incident response, patching, cost control and the steady engineering work that keeps a system trustworthy.

What happens

Monitoring, alerting and incident response against agreed severities
Security patching and dependency management
Cost and performance optimisation
Backlog enhancement and small continuous improvements
Capacity, resilience and disaster-recovery testing
Quarterly service health and roadmap review

What you get

Service reports covering availability, incidents, SLA attainment and cost
Incident records with root cause and corrective actions
A maintained dependency and vulnerability position
A quarterly roadmap recommendation

We do not move on until

Service targets are being met and reported
Renewal or transition is agreed ahead of the term ending

One model

Lifecycle, pipeline and portal are the same thing

Most organisations run three vocabularies for one process: what sales says, what delivery does, and what the client sees. We collapsed them into one typed object.

Mapping between delivery lifecycle stages, CRM pipeline stages and client portal phases
Lifecycle stage	CRM pipeline stages	Portal phase
01Explore	captured_lead, wizard_in_progress, submitted, qualification	—
02Shape	discovery_scheduled, discovery_active, solution_shaping	discovery
03Design	won_onboarding, delivery	design
04Build	delivery	build
05Validate	uat_release_readiness	validate
06Launch	deployment_hypercare	launch
07Grow	support_managed_service, expansion_renewal	grow
08Operate	support_managed_service, expansion_renewal	operate

Pipeline stage identifiers are the literal values used in our CRM.

Principles

Five things we will not trade away for speed

Every increment is demonstrable and deployable. There is no separate integration phase where the risk accumulates.
Quality gates run automatically and block on real failures. Controls that can be skipped under deadline pressure are not controls.
Accessibility and security are designed in and tested throughout, not reviewed at the end when nobody has time to act.
Estimates carry their assumptions. When an assumption turns out to be wrong, the estimate changes and we say so.
A rollback path exists and has been tested before anything goes live.

Next step

Start at Explore

The first stage costs you nothing but an honest conversation. The Project Architect is the structured version of it.

Start the Project Architect Send a message