How we work
A process built to remove surprises, not to generate paperwork
Most software does not fail because the code was bad. It fails because the wrong thing was built, the risk was found too late, or nobody could tell whether it was working. Our delivery process exists to close those three gaps. Eight stages, each with a stated goal, a defined set of deliverables and a decision gate you control before we move on.
It is a framework, not a script. Every engagement is shaped to the product, the risk and the team you already have.
The eight stages
Each stage ends at a gate: a point where you see concrete output, decide whether the case still holds, and choose whether to continue, adjust or stop. Nobody discovers in month five that the direction was wrong in month one.
- 01Discovery and business alignmentTypically 1–2 weeks
- 02AI and technical feasibilityTypically 1–3 weeks
- 03Product definitionTypically 1–2 weeks
- 04Experience design and architectureTypically 2–4 weeks, overlapping the first build sprint
- 05Iterative engineeringThe main body of the engagement
- 06AI evaluation and quality assuranceContinuous, with a focused hardening period before launch
- 07Launch and integrationTypically 1–2 weeks
- 08Monitoring and continuous improvementOngoing
01
Discovery and business alignment
Typically 1–2 weeks
Goal
Understand the business before the software. We want to know what outcome you are paid for, who is affected when it does not happen, and what a good result looks like in numbers — not in features.
Main activities
- Structured interviews with the people who own the outcome and the people who live with the current process.
- Mapping the current workflow end to end, including the spreadsheets and workarounds nobody puts in the official diagram.
- Reviewing existing systems, data sources, contracts and integration constraints.
- Naming the success metrics, the budget envelope and the deadlines that are real rather than aspirational.
- Identifying the assumptions that would break the business case if they turned out to be wrong.
What we need from you
- A decision-maker who can confirm priorities and trade-offs.
- Two to five subject-matter experts for interviews, roughly an hour each.
- Access to existing documentation, analytics and system owners.
Deliverables
- Business context and problem statement.
- Current-state process map with the friction points marked.
- Success metrics and measurement plan.
- Stakeholder map and constraint list.
- Initial scope hypothesis with a rough effort range.
Decision gate
We agree on the problem, the metric that proves it is solved, and the constraints we must respect. If the business case does not hold up here, we say so before you spend engineering money on it.
02
AI and technical feasibility
Typically 1–3 weeks
Goal
Establish what is actually achievable with your data, your systems and your budget — and whether AI belongs in the solution at all. Some problems are better solved with a rule, a query or a better form.
Main activities
- Data audit: volume, quality, labelling, coverage, licensing and privacy posture.
- Technical spike or thin prototype on the riskiest part of the system.
- For AI work: baseline evaluation of candidate approaches — retrieval, fine-tuning, classical ML or deterministic logic — against a small, representative test set.
- Integration review of the systems the solution must talk to, including rate limits, auth models and data ownership.
- Cost modelling for inference, infrastructure and ongoing operation at realistic volumes.
What we need from you
- Access to sample data in a compliant environment, and a technical contact who knows where the bodies are buried.
- One review session to walk through the prototype and the baseline numbers.
Deliverables
- Feasibility report with a clear go / adjust / stop recommendation.
- Baseline accuracy or performance numbers where AI is involved.
- Reference architecture options with trade-offs.
- Cost-to-operate estimate at expected volume.
- Risk register: technical, data and vendor risks with mitigations.
Decision gate
You get an honest answer on whether the approach works, at what quality level, and at what running cost. We only continue when the numbers support the business case.
03
Product definition
Typically 1–2 weeks
Goal
Turn a validated idea into a scope you can fund and we can build. The output is a first release that is small enough to ship and large enough to be useful on its own.
Main activities
- Writing user stories and acceptance criteria against the success metrics, not against a feature wish-list.
- Prioritisation workshop to separate the first release from the roadmap behind it.
- Defining non-functional requirements: performance, availability, compliance, accessibility, languages and supported devices.
- Agreeing on the release plan, milestones and how progress will be demonstrated.
- Sizing the work and confirming the team shape needed to deliver it.
What we need from you
- A product owner on your side who can make scope calls between sessions.
- One prioritisation workshop and one scope sign-off review.
Deliverables
- Prioritised backlog with acceptance criteria.
- Release plan and milestone schedule.
- Non-functional requirements document.
- Team composition and delivery estimate.
Decision gate
Scope, budget and timeline are signed off, and everyone can name what is deliberately not in the first release.
04
Experience design and architecture
Typically 2–4 weeks, overlapping the first build sprint
Goal
Design the product people will use and the system that will still be maintainable in three years. Design and architecture run together so neither one is a surprise to the other.
Main activities
- Information architecture, user flows and wireframes for the core journeys.
- High-fidelity UI on a design system with reusable components, states and accessibility built in from the start.
- System architecture: services, data model, integration contracts, environments and deployment topology.
- For AI features: interaction design for uncertainty — how confidence, sources, fallbacks and human review are presented to the user.
- Prototype testing with real users or internal experts where the flow is genuinely new.
What we need from you
- Design reviews at wireframe and high-fidelity stages.
- Participants for prototype testing when the audience is internal.
- Architecture review with your technical stakeholders and, where relevant, your security team.
Deliverables
- Clickable prototype of the core journeys.
- Design system foundations: tokens, components, patterns and accessibility rules.
- Architecture decision records for the choices that are expensive to reverse.
- API and integration contracts.
- Data model and environment plan.
Decision gate
The experience is approved, the architecture is agreed and recorded, and the build can start without waiting on unresolved design or infrastructure questions.
05
Iterative engineering
The main body of the engagement
Goal
Ship working software in short cycles, with every increment integrated, tested and demonstrable. No big-bang integration at the end, and no invisible progress.
Main activities
- Two-week sprints ending in a working build deployed to a shared environment.
- Trunk-based development with pull requests, peer review and automated checks on every change.
- CI/CD pipelines running unit, integration and end-to-end tests before anything is promoted.
- Infrastructure as code, so environments are reproducible rather than hand-assembled.
- Continuous refactoring inside the sprint instead of a deferred clean-up phase that never gets funded.
What we need from you
- A sprint review every two weeks with a live demo of what was built.
- Backlog refinement with your product owner, roughly an hour a week.
- Access to a test environment for hands-on feedback between reviews.
Deliverables
- Working, deployed increment at the end of every sprint.
- Sprint notes: what shipped, what moved, what is blocked and what changed.
- Automated test suites and pipeline coverage that grow with the codebase.
- Updated backlog with re-estimated remaining work.
Decision gate
Each sprint is accepted against its acceptance criteria before the next one starts. Anything not accepted goes back to the top of the backlog rather than being quietly closed.
06
AI evaluation and quality assurance
Continuous, with a focused hardening period before launch
Goal
Prove the product does what it claims — including the parts that are probabilistic. AI features are held to a measured standard, not to a demo that happened to go well.
Main activities
- Functional, regression, cross-browser and cross-device testing on every release candidate.
- Performance and load testing against the volumes named in the non-functional requirements.
- Accessibility testing against WCAG 2.1 AA for user-facing interfaces.
- For AI features: evaluation sets with ground truth, scored on accuracy, groundedness, hallucination rate, refusal behaviour and latency.
- Adversarial testing — prompt injection, jailbreak attempts, harmful and out-of-scope inputs, and behaviour when a model or provider is unavailable.
- Security review: dependency scanning, authentication and authorisation checks, and secrets handling.
What we need from you
- User acceptance testing by the people who will actually use the product.
- Sign-off on the AI quality thresholds — what score is good enough to go live.
Deliverables
- Test plan and executed test reports.
- AI evaluation report with scores against the agreed thresholds and known failure modes.
- Performance and accessibility results.
- Security review findings and remediation status.
- Open-defect list with severities and an agreed disposition for each.
Decision gate
Quality thresholds are met, no critical or high-severity defects remain open, and the AI evaluation results are documented and accepted. Only then do we plan a launch date.
07
Launch and integration
Typically 1–2 weeks
Goal
Get the product into production safely, connected to the systems around it, with the people who depend on it ready to use it.
Main activities
- Production environment setup, hardening and secrets management.
- Data migration with dry runs, validation and a tested rollback path.
- Integration with live systems — ERP, CRM, payments, identity, internal APIs — and verification against real traffic.
- Phased or feature-flagged rollout where the risk profile calls for one.
- Monitoring, logging, alerting and on-call routing configured before go-live, not after the first incident.
- Handover: training sessions, runbooks and admin walkthroughs for your team.
What we need from you
- Go / no-go decision at the launch readiness review.
- Availability of your operations and support teams during the launch window.
- Attendance at training and handover sessions.
Deliverables
- Product live in production.
- Deployment and rollback runbooks.
- Monitoring dashboards and alert configuration.
- Training materials and recorded handover sessions.
- Launch report with the post-launch watch plan.
Decision gate
Launch readiness is confirmed against a written checklist, and rollback is tested rather than assumed. We stay close through the first days in production.
08
Monitoring and continuous improvement
Ongoing
Goal
Keep the product healthy and keep improving the metric we agreed in stage one. Software that nobody watches quietly degrades — AI features degrade faster, because the world moves underneath them.
Main activities
- Monitoring uptime, error rates, latency, cost per request and the business metrics that matter.
- Tracking AI quality in production: drift, accuracy on fresh samples, user feedback, escalation and override rates.
- Regular dependency, security and model updates, with re-evaluation before any model change is promoted.
- Usage analysis to find where users struggle, abandon or work around the product.
- Quarterly roadmap reviews that turn observations into a prioritised next increment.
What we need from you
- Monthly performance review, quarterly roadmap review.
- A named owner on your side for prioritising improvement work.
Deliverables
- Monthly health and performance report.
- AI quality trend report where AI is in production.
- Prioritised improvement backlog.
- Quarterly roadmap update.
Decision gate
Each improvement cycle re-enters the process at the stage it needs — usually definition or engineering — with the same acceptance discipline as the original build.
Communication rhythm
You should never have to ask how the project is going. The cadence is fixed at kick-off and it holds for the length of the engagement.
- Daily: a shared channel with your team and ours. Questions get answered the same working day, not at the next scheduled meeting.
- Weekly: a short written status — what shipped, what is next, what is blocked, what needs a decision from you.
- Every two weeks: a sprint review with a live demo on a real environment. Slides are not a substitute for working software.
- Monthly: a delivery review covering budget burn, scope movement, risks and the metrics from stage one.
- Quarterly: a roadmap and partnership review with your leadership.
- One named delivery lead is accountable for the engagement, and you always know who to call when something is urgent.
- Written decisions over remembered ones: anything agreed in a call is confirmed in writing the same day.
Agile delivery without process theatre
We are agile in the way that matters — short cycles, working software, honest re-planning — and we skip the rituals that exist mainly to look busy.
- We keep: two-week sprints, prioritised backlogs, working increments, retrospectives that change something, and estimates that get revised when reality disagrees.
- We drop: story-point auctions, velocity as a performance score, status meetings that duplicate the written status, and documentation written to satisfy a template.
- Scope is flexible, quality is not. When something has to give, we change the scope of the release rather than the standard of the code.
- Engineers talk directly to the people who will use what they build. Requirements lose something at every hand-off.
- Retrospectives produce at most three concrete changes, each with an owner and a date, reviewed at the next one.
- If a ceremony stops producing value for your project, we drop it and say why.
Risk management
Risks are managed in the open. A risk you know about is a planning problem; a risk you find out about at launch is a crisis.
- A living risk register from stage one, with probability, impact, owner and mitigation for each entry.
- The riskiest work is scheduled first — hardest integration, least certain data, least understood model behaviour.
- Every material risk carries a contingency: an alternative approach, a scope reduction, or a fallback path.
- AI-specific risks are tracked explicitly: model deprecation, provider outages, cost spikes, quality drift, data-licensing changes.
- Dependencies on third parties and on your own teams are tracked as risks, with escalation dates rather than hopeful reminders.
- Escalation is fast and unambiguous: if something threatens scope, budget or the launch date, you hear it in the next working day, not in the next monthly report.
Documentation
We document what a new engineer — yours or ours — would need to be productive in a week. Nothing written to be filed and forgotten.
- Architecture decision records covering what was chosen, what was rejected and why.
- API documentation generated from the source, so it cannot drift from the implementation.
- Runbooks for deployment, rollback, incident response and routine operations.
- Data model and integration contracts, kept current with the code.
- AI system cards: prompts, data sources, evaluation method, known limitations and intended use.
- Onboarding guide for developers taking over the codebase.
- Everything lives in your repository and your workspace. There is no knowledge held hostage in our heads or our accounts.
Security and privacy
Security is part of the definition of done, not a review that happens after the product is built.
- Least-privilege access from day one, with credentials managed in a secrets manager and rotated on schedule.
- Encryption in transit and at rest, and data residency chosen to match your regulatory position.
- GDPR-aligned handling: documented lawful basis, data minimisation, retention limits, and support for access and deletion requests.
- Secure development practices: peer review, dependency and vulnerability scanning in CI, and no secrets in source control.
- AI-specific controls: agreements that keep your data out of third-party training, PII redaction where appropriate, prompt-injection defences, and audit logs of model inputs and outputs.
- Signed NDAs, clear IP assignment, and staff bound by confidentiality terms.
- Penetration testing and independent security review arranged where your risk profile or your customers require it.
Change management
Requirements change. That is normal and we plan for it — what we do not do is absorb changes silently and let the timeline slip without anyone deciding.
- Inside a sprint the backlog is stable. New ideas go to the backlog and are prioritised for the next cycle.
- Every change request gets an impact assessment: effort, timeline, cost and knock-on effects on other work.
- You decide the trade-off explicitly — add budget, move the date, or drop something of equivalent size.
- Small changes within the agreed envelope are handled in refinement without paperwork.
- Material changes are documented and approved in writing before work starts.
- Scope movement is reported in the monthly delivery review, so the difference between the original plan and today is always visible.
Post-launch support
Delivery does not end at go-live. Most products earn their value in the years after launch, and that period needs the same discipline as the build.
- Hypercare for the first weeks after launch: heightened monitoring, fast response and daily check-ins while real usage settles.
- A support agreement with defined severity levels, response and resolution targets, and business or extended hours to match your operating model.
- A single intake channel for issues, with transparent status and history in the Golux Club portal.
- Preventive maintenance: dependency updates, security patching, cost tuning and performance work on a regular schedule.
- For AI systems: ongoing evaluation, re-testing before any model or prompt change reaches production, and cost monitoring per feature.
- Optional continuous improvement retainer — a standing capacity for the next increment, without renegotiating a contract every time.
- Knowledge transfer whenever you want to bring the work in-house. We build for handover, not for lock-in.
The exact process is adapted to your project
What you have just read is our full framework — the complete version, for a complete product build. Almost no project uses all of it at full depth, and forcing one would be exactly the process theatre we avoid. At kick-off we agree which stages get real investment, which are compressed, and which are already covered by your own teams.
- A greenfield MVP under time pressure may compress discovery and definition into a single week and start building immediately.
- A regulated enterprise platform will spend far longer in feasibility, architecture and security review before a line of production code is written.
- A team extension engagement joins your existing process, your board and your ceremonies — our stages become an internal quality standard rather than a client-facing plan.
- An AI feature added to a mature product may skip experience design almost entirely and spend most of its budget in evaluation.
- Stages overlap in practice. Design continues while engineering starts; evaluation runs from the first sprint, not just before launch.
What never changes: a clear goal per stage, deliverables you can inspect, a decision gate you control, and honest reporting on where the work actually stands.
Starting from a prototype built with an AI coding tool? See our vibe coding to production migration path.
Keep going
Where to go next
- Read the case studiesChallenge, solution and measured outcome from delivered engagements.Continue
- Calculate project costA guided technical discovery that returns a budget range, timeline and team shape.Continue
- Book a strategy callForty-five minutes with the engineers who would actually build it.Continue
Next step
Let's map your project against this process
Bring the problem, the constraints and the deadline. In a first call we will tell you which stages your project genuinely needs, what the first gate would look like, and roughly what it takes to get there.
