Programme Definition & Technical Due Diligence

BizzPays has evolved beyond the scope of a conventional software project. A financial platform, consumer accounts, business services, payments, commerce, referrals, mobility, travel, property, agriculture, digital assets, finance and a growing network of specialist partners - built for potentially very large audiences, with multiple commercial opportunities live at launch.

Engagement

Programme Definition, Technical Due Diligence & V1 Delivery Planning

Programme fee

£50,000 · 3 milestones

Duration

6 weeks, collaborative

The next responsible step is not to immediately begin full development, nor to produce a high-level quotation based on assumptions. Before significant capital and resources are committed, BizzPays requires a clear and decision-ready blueprint covering:

Exactly what BizzPays V1 includes
Which services must be functional at launch
Which capabilities BizzPays should own
Which capabilities specialist partners should supply
How partner systems connect into one BizzPays experience
How customer, business and financial data stay under BizzPays control
How security is designed into the platform
What operational structure is required to run the ecosystem
What team is required to deliver it
How long delivery should realistically take
What level of investment will be required

Keza Studio therefore proposes a dedicated six-week Programme Definition & Technical Due Diligence engagement - intentionally separate from the main development contract.

Prepared by Keza Studio for BizzPays

02Context

Why this phase is necessary

BizzPays has a highly developed commercial vision, an extensive strategic deck, multiple business propositions, external partner conversations and a growing operational structure. What does not yet exist is a single agreed document bringing all of it into one executable delivery plan.

Quality before deadlines

The objective is not to force development into an arbitrary launch date at the expense of quality, security or readiness. The software needs to be built, trialled and proven before the wider BizzPays proposition is put in front of the market.

Breadth at launch

The initial public release is intended to be much broader than a conventional MVP - launching with a meaningful ecosystem and multiple ways for users to earn, access opportunities or build businesses, rather than a payment product with promises attached.

Launching with significant breadth while maintaining a high standard of quality and security makes formal programme definition essential.

A premature quotation could produce a number.

It would not yet produce a reliable plan.

The purpose of this engagement is to remove that uncertainty before BizzPays makes the substantially larger investment required for development.

03Context

The questions this engagement will answer

At the end of the Programme Definition phase, BizzPays should be able to answer each of these confidently.

01
What exactly is BizzPays V1?
Without a fixed launch definition, cost, team size and timeframe remain moving targets.
02
What are the principal launch opportunities?
The wider vision contains many opportunities, but the first public release requires a deliberate and agreed selection.
03
What does BizzPays itself own and operate?
Core strategic capability should not unintentionally become controlled by an external supplier.
04
What should be provided by partners?
Existing specialist systems may dramatically reduce development time and cost where appropriate.
05
How do partner systems operate as one BizzPays ecosystem?
Customers should experience BizzPays as one coherent platform rather than a collection of unrelated services.
06
Where does BizzPays data live and who can access it?
Customer, transaction and business data are potentially among BizzPays' most valuable long-term assets.
07
How will the platform be protected?
Financial platforms become increasingly attractive targets as user base and transaction volumes increase.
08
What happens if a partner or service becomes unavailable?
One supplier should not be able to disable the wider BizzPays ecosystem.
09
What can begin before the full platform is complete?
BizzPays intends to build demand and register prospective users during development.
10
What team is required?
Programme duration depends directly on expertise, team size and how much work can safely happen in parallel.
11
What will V1 realistically cost?
The board should understand both the overall investment and what that investment is buying.
12
What is the fastest responsible route to market?
Acceleration is possible in some areas, but the cost, resources and risks should be clearly understood first.

04Context

Strategic priorities this engagement protects

Six principles established during our discussions, carried through every decision in the programme.

4.1

BizzPays must retain control of its own platform

Specialist providers should connect into the BizzPays ecosystem, rather than BizzPays becoming dependent on an external organisation for its core customer relationship, technology or data. The programme will clearly separate BizzPays-owned capability from partner-provided capability that can be connected in a controlled and replaceable way.

BizzPays-owned capability - the strategic foundation that stays under BizzPays' control
Partner-provided capability - specialist services connected in a controlled, replaceable way
The objective is not to eliminate suppliers, but to prevent dependency becoming a loss of control

4.2

Security must be designed in from the beginning

BizzPays will handle financial information, customer identities, transactions, businesses and external partners at potentially very significant volumes. The platform should ultimately withstand serious independent scrutiny, which requires security to influence the fundamental design.

Where sensitive information is stored and who can access it
How financial activity is protected and important actions recorded
How partners are permitted to connect and suspicious activity detected
What happens if an account or supplier is compromised, and how the platform recovers

4.3

One platform, not a collection of suppliers

The ecosystem will involve specialists across travel, banking, mobility, insurance, property and other services. For the customer, there should simply be BizzPays. Clear boundaries define what each party is responsible for, how information moves, what happens when something fails and who owns the customer relationship.

4.4

The first public experience must establish trust

The platform may become involved in people's money, businesses, income, vehicles, travel, property and livelihoods. A launch proposition is only ready when the journey works end to end, the partner is operationally ready, support is prepared, financial and data processes are tested, failure scenarios are considered and the experience is proven with real users.

4.5

Do not build what specialist partners already do well

For every major capability the engagement will determine whether BizzPays should own it, build it, integrate it or partner for it. Travel is a clear example: the priority is connecting an existing specialist platform effectively rather than rebuilding a reservation ecosystem.

Own it - because it is strategically critical
Build it - because suitable external capability does not exist
Integrate it - because a mature specialist solution already exists
Partner for it - because operational or regulatory responsibility belongs with a specialist

4.6

Plan for the scale BizzPays intends to achieve

Discussions already include access to associations and communities numbering in the millions, with an ambition to register prospective customers before full launch. The objective is not to over-engineer for every hypothetical scenario, but to avoid early decisions that make growth unnecessarily expensive or difficult.

05Programme

Ten workstreams

The scope of work, from defining V1 through to modelling the team, timeline and investment. Tap any workstream to see what we do, why it matters and what you receive.

What Keza Studio will do

The core BizzPays services required at launch
The priority income and business opportunities
What must be genuinely functional at launch
What may be visible but dependent on later partner activation
What is deliberately excluded from V1
The conditions to satisfy before BizzPays is ready for public release

Why this matters

Different stakeholders could interpret "BizzPays V1" very differently - accounts and payments for one, travel for another, housing, mobility, farming and multiple commercial opportunities for another. Until this boundary is agreed, any quotation or timetable relies on assumptions.

BizzPays V1 Scope & Launch Definition

06Programme

Seventeen deliverables

The output of this phase is not a development quotation. It is a comprehensive blueprint for BizzPays V1.

1
V1 Scope & Launch Definition
Exactly what BizzPays intends to launch
2
Product Requirements Document
What the platform must do
3
Master User Story Catalogue
What each type of user needs
4
Key User Journey Flows
How important experiences work end to end
5
Partner & Integration Readiness Matrix
What BizzPays builds versus what partners provide
6
Technical Requirements Document
What technology is required
7
Platform Ownership & Data Control Blueprint
How BizzPays retains strategic control
8
Security & Customer Protection Strategy
How users, money, data and services are protected
9
Resilience & Recovery Requirements
How the platform responds to failures
10
V0 Pre-Launch Network Specification
How BizzPays builds its network during development
11
Operations & Management Requirements
How BizzPays will operate the platform internally
12
Master Delivery Backlog
Everything required to deliver V1
13
Dependency & Readiness Map
What could block or delay delivery
14
V1 Delivery Roadmap
How the programme should be sequenced
15
Team & Resource Plan
Who is required to deliver the programme
16
Delivery Scenario & Investment Model
Cost, speed and risk trade-offs
17
Board-Ready V1 Development Proposal
Final investment and development decision

07Programme

The six-week programme

The programme assumes timely access to relevant BizzPays stakeholders, partners, advisers and service providers.

1
Week 1
Define BizzPays V1
Launch scope, priority services and principal commercial opportunities
2
Week 2
Define customers, processes and partners
User journeys, operational requirements and partner responsibilities
3
Week 3
Technical research and provider assessment
Technology options, payment / banking / identity requirements and integrations
4
Week 4
Platform control, data and security
Platform structure, ownership model, security and resilience
5
Week 5
Delivery planning
Backlog, dependencies, team structure and sequencing
6
Week 6
Investment and board preparation
Delivery scenarios, programme cost, recommendations and final development proposal

08Programme

How we work together

This programme cannot be defined effectively by Keza Studio working in isolation. The six weeks are collaborative and decision-led.

Weekly Programme Session

A structured weekly meeting with BizzPays leadership focused on major product, commercial and delivery decisions.

Short Decision Sessions

Where an unanswered question could block significant work, shorter focused sessions are arranged rather than waiting for the weekly meeting - including the regular morning slots discussed.

Partner Discovery Sessions

Meetings with each relevant V1 partner or department to establish capability, readiness, responsibilities, technology, data requirements and outstanding dependencies.

Technical Provider Sessions

Where appropriate, Keza Studio engages directly with technology providers to validate proposed approaches and integration requirements.

Security Review

Security and platform recommendations are prepared for review with BizzPays' appointed cyber-security adviser.

CEO & Leadership Onboarding

As BizzPays appoints its CEO and divisional leadership, they are progressively incorporated into the definition process.

09Programme

The proposed Keza Studio team

Not every specialist is assigned full-time throughout. The objective is to apply the right expertise to the right decisions, rather than asking one person to make assumptions across multiple specialist industries.

Programme / Product Lead
Owns the overall BizzPays definition and alignment with commercial objectives
Technical Lead
Owns the platform structure and technology recommendations
Senior Engineering Specialist
Researches payments, financial services, integrations and core platform requirements
Product / UX Lead
Defines customer journeys, merchant journeys and user experience requirements
Business Analyst
Coordinates requirements, partner research and structured documentation
Security Specialist
Defines security requirements and prepares the independent review
Delivery Lead
Converts requirements into roadmap, resources, dependencies and investment models

Additional specialist support may be introduced where the programme requires deeper expertise within a particular domain.

10Commercials

Investment

Two separate commitments: fees for the work performed, and an optional reservation that secures future delivery capacity.

Programme Definition

£50,000

Total professional fee for Programme Definition & Technical Due Diligence.

Engagement commencementOn signing£25,000
Definition milestoneEnd of Week 3£12,500
Final programme deliveryOn completion£12,500

The engagement commences following execution of the agreement and receipt of the first payment.

Optional

Priority Delivery Capacity Reservation

£25,000

Priority access to the Keza Studio delivery team for 30 days following completion of the Programme Definition engagement. If BizzPays becomes our principal programme we may need to materially reduce acceptance of other major engagements - we are prepared to make that commitment, and it requires a reciprocal one.

If BizzPays proceeds: the full £25,000 is credited against the first development invoice.

If not within the period: the reservation is non-refundable, because capacity was reserved and competing work restricted.

Programme Definition fees pay for work completed. The Capacity Reservation secures future delivery availability. The £50,000 is not automatically deducted from development cost - the development programme is separately priced once V1 is defined.

Why this is a paid engagement

This phase extends materially beyond preparing a development quotation. It commits senior product, technical, security and delivery resources over several weeks, and involves:

Reviewing and consolidating the wider BizzPays vision
Defining a complex V1 programme
Working directly with BizzPays stakeholders
Meeting specialist partners and assessing third-party services
Researching technical options

Considering security and resilience
Defining several hundred product requirements
Mapping dependencies and modelling delivery approaches
Planning the required team
Producing a board-ready investment proposal

At completion BizzPays owns a comprehensive definition of its V1 platform and the information needed to make technology, partner, staffing and investment decisions - irrespective of whether Keza Studio receives the main development contract.

11Commercials

Scope boundaries, ownership and success

This engagement defines and prepares BizzPays V1. It does not include the main production build - which protects this phase from gradually becoming an unstructured development engagement.

Not included

Production development
Main platform development operates under a separate agreement
Complete visual interface design
Definition-stage flows or wireframes may be created; complete production UI design belongs to development
Third-party licence costs
Providers and expected costs may be identified; subscriptions are purchased separately
Formal legal advice
Areas requiring legal input are identified; we do not replace your legal advisers
Regulatory approval
BizzPays entities and regulated partners remain responsible for authorisations
Partner commercial agreements
We assess technical suitability; commercial relationships remain with BizzPays
Production security testing
Requirements and testing strategy are defined; full testing runs against the built platform
Ongoing delivery management
Full programme management begins under the main mobilisation / development agreement

Ownership of deliverables

Once all Programme Definition fees are paid, BizzPays receives the agreed BizzPays-specific outputs created under this engagement. BizzPays will not be required to continue with Keza Studio simply to access the requirements, research and blueprint. Pre-existing Keza Studio frameworks, methods, templates, tools and general know-how remain Keza Studio's intellectual property.

Success criteria

V1 has been definedOne agreed description of what constitutes BizzPays V1
Priority launch opportunities confirmedNo material ambiguity around the principal launch proposition
Partner responsibilities understoodEach important V1 service has clear ownership and responsibility
Partner readiness visibleMissing information, access and agreements clearly identified
Product requirements definedMajor customer and business journeys documented
Technical direction establishedThe development team understands the principal technology requirements
Data ownership definedBizzPays understands what it owns and what providers can access
Security requirements establishedThe proposed approach is ready for specialist review
Pre-launch acquisition definedBizzPays can begin building its network ahead of full V1
Operational requirements definedThe business understands what is needed to operate the platform
Dependencies visibleThe board can understand what could delay delivery
Development team modelledRequired roles and capacity are understood
Development cost modelledBizzPays has a credible investment requirement
Delivery scenarios comparedThe implications of accelerating or reducing the programme are visible
Development proposal completedBizzPays can make an informed decision on implementation

12Close

What happens after Programme Definition

The objective is to enter the main development programme with as many fundamental questions already answered as possible - so development resources are spent building BizzPays, not repeatedly establishing what BizzPays is supposed to be.

1
Programme Definition
6 weeks
2
V1 Blueprint
Product + partners + technology, security + data + operations
3
Board Decision
Scope + team + timeline + investment
4
Mobilisation
Dedicated BizzPays delivery team
5
V1 Development
Multiple workstreams in parallel, pre-launch acquisition continues
6
Security & Operational Testing
Independent testing against the built platform
7
Launch Readiness
Journeys, partners, support and processes proven
8
BizzPays V1
Public launch into an existing network

Closing statement

BizzPays will not simply have another development proposal. BizzPays will have the blueprint for the business and technology ecosystem it intends to build.

BizzPays has the potential to become significantly larger than a conventional software product. That opportunity is precisely why the foundation deserves more care, not less. The purpose of Programme Definition is not to slow BizzPays down with documentation - it is to remove the uncertainty that causes programmes of this size to become slow, expensive, fragmented and difficult to control. Keza Studio is prepared to make the level of commitment required to take responsibility for that foundation.