Hassan Khan is FlutterCraft's Head of Strategy & Partnerships. He writes about UK market entry, technology adoption, go-to-market planning, strategic partnerships, partner due diligence, and turning digital initiatives into repeatable growth.
Related articles
Continue with more FlutterCraft thinking for founders and product teams.
A product made from both owned and external components
Balance between control and speed
Clear boundaries between components and parties
The GOV.UK purchasing strategy guidance recommends considering user needs, organisational capability, full costs, lifecycle, commercial approach and the choice between building, buying or combined approaches.
The strongest decision is rarely “build because custom is better” or “buy because software already exists”. It is the route that fits the capability, risk and time horizon.
Start With the Business Capability
Do not begin with a preferred vendor or framework. Define what the organisation needs to be able to do.
Capability question
Why it matters
What must the organisation do better?
Connects technology to a business outcome
Who needs the capability?
Identifies users, buyers, operators and support teams
Is the capability differentiating?
Helps determine whether ownership creates strategic value
How urgent is the need?
Sets the time-to-value requirement
What must integrate with it?
Reveals technical and operational dependencies
What data does it use?
Identifies privacy, security and governance responsibilities
Who will operate it?
Tests internal capability and support ownership
How long will it matter?
Shapes lifecycle, investment and exit planning
What would failure cost?
Makes risk and assurance proportionate
What does success look like?
Creates a basis for evaluating the route
A capability may be important without being differentiating.
For example, payroll, email, accounting or basic scheduling may be essential to the organisation but not unique to its proposition. Buying a suitable product may be sensible. By contrast, a specialised workflow that defines the customer experience may justify greater control or customisation.
Importance and differentiation are separate questions.
Commodity or Differentiating?
Use a simple two-part test.
Is the capability common?
Look for:
Multiple credible suppliers
Mature workflows
Clear feature comparisons
Established security and support practices
Standard data formats
Well-understood integration patterns
A reasonable way to migrate if necessary
If the business need is common and the products fit, buying may reduce unnecessary construction.
Is the capability strategically distinctive?
Look for:
A customer journey competitors cannot easily copy
Proprietary operational knowledge
A specialised workflow
A unique data or decision process
A product experience central to the value proposition
A need for rapid iteration in a specific direction
A requirement for ownership over the roadmap
If the capability is central to differentiation, a custom or partner-supported route may deserve closer examination.
This does not mean every distinctive capability must be built internally. A specialist partner may help create and maintain it while the business retains product ownership and decision authority.
Compare Time to Value
The quickest route to initial functionality is not always the quickest route to a useful operating capability.
Compare the stages:
Selection or discovery
Procurement or commercial agreement
Configuration or design
Integration
Data migration
Security and privacy review
User acceptance
Training and operational readiness
Launch
Continuous improvement
Exit or replacement
Route
Time advantage
Time risk
Build
Can start with a narrow, focused scope
Discovery, engineering, testing and maintenance may take longer than expected
Buy
Existing functionality may be available quickly
Configuration, procurement, migration and integration can become the critical path
Partner
Specialist capability may reduce internal ramp-up time
Availability, decision speed and unclear responsibilities can delay delivery
Hybrid
Allows a focused owned component alongside external capability
Boundary decisions and integration can create hidden coordination work
Do not compare only the date on which the first interface appears. Compare the date on which the capability can be operated reliably.
Compare Total Lifecycle Cost
The first invoice is only one part of the decision.
Include:
Discovery and requirements
Design and configuration
Development
Integration
Data migration
Testing
Security assurance
Accessibility work
Hosting or licence costs
Support and incident response
User training
Product management
Vendor management
Platform or supplier changes
Renewal increases
Additional usage
Technical debt
Data export
Transition and decommissioning
Cost category
Build
Buy
Partner
Initial delivery
Engineering and product effort
Licence, configuration or implementation
Discovery and delivery fees
Ongoing change
Internal roadmap and maintenance
Product limits, configuration or custom extensions
Change requests or retained team capacity
Operations
Internal platform, support and monitoring
Vendor plus internal oversight
Shared responsibilities requiring governance
Integration
Owned but still requires maintenance
Dependent on available interfaces and supplier support
Depends on partner capability and access
Exit
Knowledge and code ownership can help
Migration, data export and replacement planning
Knowledge transfer and handover obligations
Internal capability
Requires sustained technical ownership
Requires commercial and technical oversight
Requires enough internal capability to manage the relationship
A cheap first step can produce expensive dependency if the organisation cannot change, monitor or exit the arrangement.
Assess Control and Flexibility
Control has several dimensions:
Product roadmap
User experience
Data model
Integration behaviour
Release timing
Security configuration
Service availability
Pricing exposure
Support process
Access to source code or documentation
Ability to export and migrate information
Buying does not remove the need for oversight. Building does not guarantee flexibility. Partnering does not automatically transfer ownership.
The GOV.UK guidance on managing technical lock-in recommends considering future provider changes, exit costs, open standards, data export and loosely coupled components. Although the guidance focuses on cloud arrangements, the same questions are useful for software and delivery decisions.
Ask:
Can the organisation export its data in a usable format?
Can another supplier understand and operate the system?
Are integrations documented?
Are critical decisions recorded?
Can the organisation replace one component without replacing everything?
What happens if the supplier changes price, product direction or ownership?
How much knowledge remains inside the organisation?
Control should be measured against the things the business genuinely needs to control.
Assess Integration and Data
Integration often decides whether a “buy” route remains simple.
Investigate:
Authentication
User and role synchronisation
Data ownership
API limits
Webhooks and event handling
Data quality
Reporting
Failure and retry behaviour
Monitoring
Data retention
Backups
Data export
Sub-processors
Cross-border processing where relevant
If personal data is processed by a supplier, the organisation needs to understand the relevant controller and processor responsibilities. The ICO guidance on contracts and liabilities between controllers and processors explains that contracts may need to address documented instructions, confidentiality, security, sub-processors, rights requests, assistance, audits and end-of-contract provisions.
Do not use a generic security statement as a substitute for understanding the actual data flow.
Draw the boundary:
Data or system question
Decision required
Who collects the data?
Identify the organisation and purpose
Who decides how it is used?
Clarify governance responsibility
Where is it processed and stored?
Record relevant locations and suppliers
Who can access it?
Define roles and privileged access
How is it protected?
Set proportionate controls
How is it deleted or returned?
Define retention and exit behaviour
What happens during an incident?
Agree notification and response ownership
Treat Partner as a Distinct Route
A partner is not simply an outsourced version of “build”.
A specialist partner may contribute:
Product discovery
Engineering capability
Domain expertise
Design and UX
Integration knowledge
Delivery capacity
Technical leadership
Quality assurance
Security support
Knowledge transfer
A transition path to internal ownership
The organisation may still retain:
Product direction
Customer relationship
Prioritisation authority
Data and intellectual property ownership
Acceptance criteria
Strategic roadmap
Final approval
Partner model
Useful when
Boundary to define
Specialist delivery partner
The organisation has a clear product need but lacks delivery capability
Scope, acceptance, quality and ownership
Embedded capability partner
The team needs additional capacity or expertise
Reporting, decision rights and knowledge transfer
Build-transfer partner
The organisation wants a new capability and plans to own it later
Documentation, training and transition milestones
Integration partner
The work depends on connecting systems or products
Technical access, support and incident ownership
Strategic technology partner
Both parties contribute to a longer-term capability
Commercial model, roadmap and mutual commitments
The partner model should be chosen because it fits the capability and ownership requirement, not because it avoids making a decision.
Assess Internal Capability
Every route requires internal ownership.
Even when software is purchased or delivery is partnered, someone inside the organisation must be able to:
Define the business outcome
Represent users
Make scope decisions
Manage risk
Review supplier performance
Understand the architecture at an appropriate level
Approve changes
Manage data and access
Monitor service quality
Plan renewal or exit
Decide whether the product is still valuable
The GOV.UK purchasing strategy guidance recommends understanding organisational skills and capabilities when choosing a delivery approach.
Internal capability
Why it matters
Product ownership
Prevents supplier activity from replacing product direction
Technical oversight
Helps evaluate architecture, integration and risk
Commercial management
Protects value, terms and renewal decisions
Security and privacy ownership
Ensures responsibilities remain visible
Operational support
Makes incidents and user problems actionable
Data stewardship
Protects quality, access and lifecycle
Change management
Helps users adopt and sustain the capability
If the organisation cannot provide enough oversight, the route may be wrong or the plan may need capability-building first.
Use a Decision Matrix
Score each route against criteria that matter to the organisation. Do not use a score to create false precision. Use it to expose trade-offs.
Criterion
Weight
Build
Buy
Partner
Hybrid
Strategic differentiation
High
5 - Maximum control over unique capability
2 - Limited differentiation
4 - Specialist capability with tailored delivery
4 - Own the differentiating layer while buying standard services
Time to useful capability
High
2 - Requires internal planning and delivery time
5 - Fastest when a suitable product already exists
4 - Faster delivery with specialist support
4 - Accelerates standard parts while protecting key custom work
Lifecycle cost
High
2 - Higher internal build and maintenance commitment
4 - Predictable subscription or licence costs
3 - Delivery and ongoing support costs must be managed
3 - Costs are shared across internal and external ownership
User and workflow fit
High
5 - Can be designed around the exact workflow
2 - May require process compromises
4 - Can be configured and extended for the organisation
4 - Customise critical journeys and use standard tools elsewhere
Integration complexity
Medium
3 - Full control but all integrations must be delivered
2 - Existing systems may require workarounds
4 - Partner can design and manage integration work
3 - Complexity is split between internal and external systems
Data and security control
High
5 - Maximum control over architecture and data handling
3 - Depends on supplier controls and contract terms
4 - Stronger control when responsibilities are clearly agreed
4 - Sensitive or strategic elements can remain under direct control
Internal capability
High
2 - Requires strong product and engineering ownership
4 - Lower technical delivery requirement, but still needs governance
4 - Specialist capability supplements the internal team
3 - Requires enough internal capability to coordinate both routes
Flexibility and roadmap control
Medium
5 - Roadmap is fully controlled internally
2 - Roadmap depends on the supplier
4 - Changes can be agreed through the partnership
4 - Internal priorities remain flexible for the owned components
Supplier dependency
Medium
4 - Lower direct supplier dependency
2 - High dependency on the product supplier
2 - Ongoing reliance on the delivery partner
3 - Dependency is limited to selected components and services
Exit and transition
High
4 - Internal ownership can simplify transition
2 - Migration may be difficult if data or workflows are locked in
3 - Depends on documentation, access and handover terms
3 - Exit risk is reduced when ownership boundaries are explicit
For each cell, record a short evidence-based rationale rather than an unexplained number.
A useful decision statement might look like this:
We will use a hybrid route because the customer-facing workflow is strategically differentiating, while identity, payments and communications are common capabilities that can be sourced externally. The organisation will retain product ownership, data governance and the core workflow roadmap.
That is more useful than saying:
Hybrid scored highest.
Plan Assurance and Exit Before Commitment
Security, privacy, commercial and operational assurance should begin before the relationship becomes difficult to change.
The NCSC Cyber Assessment Framework supply-chain guidance emphasises understanding dependencies, protecting data shared with third parties, managing connections and defining appropriate contractual responsibilities.
Consider:
Supplier ownership and dependency
Subcontractors
Access to production systems
Source-code and repository access
Data processing
Incident response
Vulnerability management
Business continuity
Service availability
Support levels
Change notification
Intellectual property
Audit or assurance evidence
Data return and deletion
Knowledge transfer
Termination assistance
The Digital, Data and Technology Playbook also highlights the importance of lifecycle planning, relationships, data exchange, transition and exit for digital technology projects.
This article is not legal, tax, competition, procurement, privacy or security advice. Obtain qualified advice for the specific arrangement and sector.
Hassan’s Strongest Stop Signal
Do not commission custom software when the organisation has not yet established:
The business capability it needs
The user problem
The differentiating element
The internal decision owner
The operational owner
The evidence that existing products are unsuitable
The budget for maintenance and change
The reason a custom route is preferable
Custom development can be appropriate, but “we want something unique” is not enough. Uniqueness should be connected to a real business or user advantage.
If a commercial product meets the need with acceptable control and lifecycle risk, buying may be the stronger decision. If the organisation lacks capability but needs ownership, partnering may be more suitable. If different parts of the capability have different strategic value, use a hybrid model.
Conclusion
Build, buy and partner are all valid routes.
Start with the business capability. Separate common functions from differentiating workflows. Compare time to value and total lifecycle cost. Assess control, integration, data, security, internal capability and exit options. Treat partnership as its own operating model, not as an invisible form of outsourcing.
The right answer is the route that gives the organisation the required capability, control and sustainability at an acceptable level of risk.
A practical guide for international technology companies choosing UK partners for trust, distribution, integration or delivery, with a focused thesis and measurable first motion.
Plan a realistic UK app development budget across discovery, UX, engineering, testing, launch, support and maintenance, with clear cost drivers and quote questions.
Hassan KhanHead of Strategy & Partnerships28 Aug 202613 min read00
