Seven stages, from understanding the problem to improving the software in production. Each one ends with something you can see, check, and decide on.
This is a model, not a script. A startup MVP, an AI proof-of-concept, and an enterprise platform use the same stages in very different proportions, and we agree the shape with you before work starts.
Each stage lists what we do, what you receive, and what we need from each other. Scroll to follow the work as it moves through.
01
STAGE 01
Discover
Understand users, business constraints and goals.
THE QUESTION IT ANSWERSWhat problem are we solving, for whom, and why now?
ACTIVITIES
Conversations with stakeholders and, where possible, the people who will use the software
Review of existing systems, data, documents, and earlier attempts
Mapping constraints: budget, timeline, compliance, team, and technology
Listing the assumptions the project depends on and how risky each one is
DELIVERABLES
Discovery brief: goals, users, constraints
Assumption and risk log
Open questions to settle before scope is fixed
COLLABORATION
From you
Time with decision-makers and with the people who know the users, the process, and the edge cases.
From us
Partners lead these conversations directly and write up what we heard, so nothing lives only in someone’s notes.
READY TO MOVE ON WHENWe agree on the problem, who it is for, and what success would look like.
02
STAGE 02
Define
Requirements, scope, architecture and success criteria.
THE QUESTION IT ANSWERSWhat will we build first, and how will we know it worked?
ACTIVITIES
Requirements written as prioritized user stories, ordered by value and risk
A high-level architecture with integration boundaries and data ownership
Explicit scope: what is in, what is out, and what is deferred
Success criteria that can be measured, and acceptance criteria per feature
DELIVERABLES
Prioritized backlog
Architecture outline with key decisions recorded
Success and acceptance criteria
Delivery plan with milestones and known risks
COLLABORATION
From you
Make the scope calls and sign off the success criteria. Tell us which matters most when speed, cost, and scope conflict.
From us
Present options with their trade-offs and a recommendation, then write the decision down.
READY TO MOVE ON WHENScope, success criteria, and the first milestone are agreed in writing.
03
STAGE 03
Design
UX, product flows, technical architecture and prototypes.
THE QUESTION IT ANSWERSWhat is the riskiest assumption, and what is the cheapest way to test it?
ACTIVITIES
User flows and wireframes for the core journeys
Interface design, using your design system or establishing one
Technical design: data model, APIs, infrastructure, security model
Prototypes and technical spikes for the parts we are least sure of
DELIVERABLES
Clickable prototype or flow designs
Technical design and architecture decision records
Spike findings on uncertain components
COLLABORATION
From you
Review designs early, while they are still rough, and put prototypes in front of real users where you can.
From us
Show work before it is polished and test uncertain parts before the build depends on them.
READY TO MOVE ON WHENThe riskiest assumptions have been tested and there is a design to build against.
04
STAGE 04
Engineer
Iterative implementation with code review and automated testing.
THE QUESTION IT ANSWERSIs working software moving closer to the goal with every iteration?
ACTIVITIES
Short iterations, each ending in a demo of working software
Peer code review on every change before it merges
Unit, integration, and contract tests written alongside each feature
Continuous integration running the test suite on every commit
DELIVERABLES
Working software at the end of each iteration
Demo and a short written progress update
Source code with tests in your repository
An up-to-date decision log
COLLABORATION
From you
Join demos, give feedback quickly, and keep a product owner available for questions.
From us
Report status honestly, including what is behind, and raise risks as soon as we see them.
READY TO MOVE ON WHENFeatures meet their acceptance criteria and pass the automated checks.
05
STAGE 05
Validate
QA, performance, security and acceptance testing.
THE QUESTION IT ANSWERSDoes it hold up under real conditions, real load, and misuse?
ACTIVITIES
Exploratory and regression testing across the release candidate
Performance and load testing against targets agreed in Define
Security review: dependency scanning, access control, common vulnerability classes
User acceptance testing with your team, plus accessibility checks
DELIVERABLES
Test report with open issues ranked by severity
Performance and security findings, fixed or explicitly accepted
Acceptance sign-off
COLLABORATION
From you
Run acceptance testing with the people who will use the software, and decide which known issues are acceptable at launch.
From us
Report everything we found, including what we did not fix and why.
READY TO MOVE ON WHENAcceptance criteria are met and every remaining risk is known and accepted.
06
STAGE 06
Deploy
Infrastructure, CI/CD, observability and production rollout.
THE QUESTION IT ANSWERSCan we release safely, see what is happening, and roll back if we need to?
ACTIVITIES
Infrastructure defined as code, with reproducible environments
CI/CD pipelines that promote the same build through each environment
Logging, metrics, dashboards, and alerts that a person will act on
Staged rollout using feature flags, canary, or phased releases
DELIVERABLES
Deployment pipeline and environments
Monitoring and alerting
Rollback plan and incident runbooks
Operational handover notes
COLLABORATION
From you
Provide access to accounts and infrastructure, agree release windows, and name who is responsible when something goes wrong.
From us
Rehearse the release, agree rollback criteria in advance, and stay close during the rollout.
READY TO MOVE ON WHENThe software is live, monitored, and the people running it know how.
07
STAGE 07
Improve
Analytics, monitoring and continuous iteration.
THE QUESTION IT ANSWERSWhat is real usage telling us to do next?
ACTIVITIES
Product analytics measured against the success criteria from Define
Monitoring errors, performance, and running costs
Maintenance: fixes, dependency updates, and security patches
Choosing the next increment based on evidence, not the original wish list
DELIVERABLES
Regular review of success metrics
Prioritized improvement backlog
Maintenance and upgrade plan, or a clean handover to your team
COLLABORATION
From you
Share what users and the business are saying, and decide whether to continue with us or take the work in-house.
From us
Measure honestly, and recommend what to stop doing as well as what to build next.
READY TO MOVE ON WHENFindings feed the next increment, which starts again at Discover or Define.
The next increment starts again at Discover or Define, with evidence from production.
In practice, stages overlap. Design continues while engineering starts, testing is not saved for Validate, and in iterative delivery stages 03 to 06 repeat for every increment. The order shows where emphasis sits, not a set of gates that must close before the next can begin.
02 / HOW IT ADAPTS
The process bends
to the engagement.
An AI proof-of-concept and a regulated enterprise platform should not run the same playbook. These are the shapes we start from; the actual plan is agreed with you in Define.
ENGAGEMENTSTAGES 01–07
ENGAGEMENT 01 / 06
Startup MVP
A new product that needs to reach real users quickly and learn from them.
Compressed and fast. Discovery and definition are short and focused on the one assumption the product depends on, and the learning loop after launch matters more than polish.
01DiscoverLightweight
02DefineCore focus
03DesignLightweight
04EngineerCore focus
05ValidateLightweight
06DeployLightweight
07ImproveCore focus
WHAT CHANGES
Scope is cut to the smallest version that tests the core assumption
Managed platforms and services are preferred over custom infrastructure
Testing is risk-based: critical paths automated, the rest checked by hand
Analytics are added from the first release, because learning is the point
ENGAGEMENT 02 / 06
Existing product
A product already in use that needs new features, modernization, or stabilizing.
Starts from what is already there. Discovery becomes an assessment of the codebase, architecture, and delivery pipeline, and changes are made incrementally around real users.
01DiscoverCore focus
02DefineCore focus
03DesignLightweight
04EngineerCore focus
05ValidateCore focus
06DeployYour process
07ImproveCore focus
WHAT CHANGES
Begins with a code, architecture, and pipeline assessment rather than a blank page
Your conventions, tooling, and branching model are kept where they work
Regression tests are put in place before risky refactoring
Changes ship incrementally behind flags; a full rewrite has to be justified by evidence
ENGAGEMENT 03 / 06
Enterprise application
Systems with many stakeholders, integrations, and compliance or security requirements.
Every stage runs in full, with more formal checkpoints. Non-functional requirements are settled early, and delivery works within your governance rather than around it.
01DiscoverCore focus
02DefineCore focus
03DesignCore focus
04EngineerCore focus
05ValidateCore focus
06DeployCore focus
07ImproveCore focus
WHAT CHANGES
More stakeholders, so more written decisions and explicit sign-off points
Security, compliance, and integration requirements are captured in Define, not found in Validate
Releases follow your change-management and approval process
Documentation and handover are planned as deliverables from the start
ENGAGEMENT 04 / 06
AI proof-of-concept
Testing whether AI can solve a specific problem well enough to justify building it.
An experiment with a decision at the end. The effort goes into defining what “good enough” means and measuring it on real data; the code is deliberately experiment-grade.
01DiscoverCore focus
02DefineCore focus
03DesignLightweight
04EngineerLightweight
05ValidateCore focus
06DeployUsually not included
07ImproveLightweight
WHAT CHANGES
Success is defined as an evaluation: quality, cost, and latency on your own data
Data access and quality are checked first, because they decide most outcomes
Code is built to answer the question, not to run in production; hardening is a separate step
Ends with a written go or no-go recommendation, which can be “do not build this”
ENGAGEMENT 05 / 06
Staff augmentation
Our engineers join your team to add capacity or specific expertise.
Your methodology, not ours. Our engineers take part in your planning, ceremonies, and tooling, and bring our engineering standards into the work they do.
01DiscoverLightweight
02DefineYour process
03DesignYour process
04EngineerCore focus
05ValidateYour process
06DeployYour process
07ImproveYour process
WHAT CHANGES
Onboarding replaces discovery: your codebase, conventions, and domain
Our engineers join your stand-ups, reviews, and backlog
We hold ourselves to the same code review, testing, and documentation standards
A NeuralSharks partner stays available for escalation and technical review
ENGAGEMENT 06 / 06
QA engagement
Improving the quality of software that another team is building or has built.
Centred on Validate, with test automation built as an engineering project of its own. It starts by deciding what is worth testing, and at which level.
01DiscoverCore focus
02DefineCore focus
03DesignLightweight
04EngineerCore focus
05ValidateCore focus
06DeployLightweight
07ImproveCore focus
WHAT CHANGES
Begins with a risk assessment to decide what to test, and at which level
A test strategy replaces the product scope in Define
Engineering means building the test suite and its tooling, maintained like production code
Tests run in your CI pipeline, so every change is checked automatically
Core focusDone in full depth; this is where the engagement spends its effort.
LightweightKept short and proportionate to the risk.
Your processRuns on your team’s existing practice; we work within it.
Usually not includedTypically outside this kind of engagement.
Most real projects are a mix: an existing product with an AI feature, or an MVP with a QA partner alongside. Treat these as starting points for a conversation, not packages. See the capabilities behind each one.
03 / WHAT DOES NOT CHANGE
What does
not change.
The shape flexes. These practices hold in every engagement, including when our engineers work inside your team’s process.
IDPRACTICEWHAT IT MEANS
C-01
Decisions are written down
Scope, architecture, and trade-off decisions are recorded with their reasons, in a place your team can find later.
C-02
Every change is reviewed
No code reaches a shared branch without a second engineer reading it, including in your repositories.
C-03
Tests match the risk
Automated checks cover what would hurt most if it broke. The depth varies; the habit does not.
C-04
Progress is visible
Working software or concrete findings at regular intervals, with honest status, including what is behind.
C-05
Secure by default
Least-privilege access, managed secrets, and care with personal data from the first commit.
C-06
Built to hand over
Documentation, repeatable setup, and code another team can own, whether or not we stay involved.
WORK WITH US
Tell us what you are building. We will propose the shape.
Share the problem, the constraints, and where things stand today. We will suggest which stages matter most for your project, and be clear about which ones you may not need.