BizzPays
BizzPays
01 · The Vision
Full proposal and supporting detail
0%
BizzPays
Phase 1: Foundation & Build Readiness

The first stage of building BizzPays

BizzPays is being built as a financial and business ecosystem: consumer accounts, business services, payments, commerce, referrals, mobility, travel, property, agriculture and finance, delivered with specialist partners for a potentially very large audience.

Phase 1 establishes the product, commercial, technical and operational foundations of that platform. It ends with something BizzPays can demonstrate, and with a plan, team, timeline and budget for delivering the whole vision.

Phase
Phase 1: Foundation & Build Readiness
Duration
8 weeks
The journey
  1. 01VisionThe BizzPays ecosystem as set out by Kwame and the board
  2. 02Phase 1: Foundation & Build ReadinessProduct, technology, security, commercial and delivery foundations, plus a demonstrable product foundation
  3. 03Full build programmeThe platform built to the validated scope, plan and budget
  4. 04LaunchPublic release into a network already registered during the build
  5. 05ScaleFurther services, partners and markets added on the same foundation

Phase 1 is not separate from the project. It is the first phase of it.

Current investment view
Committed now
Phase 1: Foundation & Build Readiness
8 weeks · £68,000 all inclusive
Recommended planning position
c. £2.4m for Phase 1 plus the recommended production programme
Upper planning envelope c. £3.8m

Following further review of the vision, we have completed an initial bottom-up simulation of what the wider production programme may require. This is not a fixed quotation. Decisions on launch scope, regulatory responsibility, partners, integrations, user volumes and infrastructure are what Phase 1 exists to validate. We think BizzPays leadership should see the realistic level of capital commitment before authorising it.

Minimum responsible launch
c. £1.91m
c. £1.98m
c. 10 to 12 months
Recommended V1
c. £2.32m
c. £2.38m
c. 12 to 13 months
Upper planning case
c. £3.69m
c. £3.76m
c. 13 to 18+ months

These are bottom-up planning figures, not a fixed quotation. Phase 1 replaces the assumptions behind them with evidence. By the end of Phase 1 BizzPays does not receive another estimate. It receives a build-ready programme where every significant cost traces back to a defined capability, integration, resource, dependency or operating requirement.

Keza StudioPrepared by Keza Studio for BizzPays
02Phase 1

The challenge

BizzPays has a developed commercial vision, an extensive strategic deck, several business propositions and live partner conversations. What does not exist yet is one agreed plan that a development programme can be built and costed from.

The breadth

The first release is intended to be much wider than a conventional first version. It launches with a working ecosystem and several ways for people to earn, access opportunities or run a business.

The standard

The platform will hold money, identities and business information. It has to be built, trialled and proven before it is put in front of the market.

The risk

We can size the programme today, and section 14 sets out that range. What we cannot yet do responsibly is fix a single price inside it, because scope, partners, financial responsibilities and security requirements would move it.

Our recommendation is to begin with Phase 1: define the platform, build a demonstrable foundation, and cost the full programme properly before the larger capital commitment.

The principles this protects

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

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

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.

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.

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

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.

03Phase 1

What Phase 1 delivers

At the end of Phase 1, BizzPays leadership and its investment board hold the following.

  1. 01

    A product foundation you can see, click through and verify

    A BizzPays brand identity, full screen designs, a reusable design system, a complete clickable prototype and a documented technical foundation, so the vision can be demonstrated rather than described and independently reviewed.

  2. 02

    An agreed definition of what BizzPays needs to become

    One version of the platform that leadership, partners and the board all recognise, instead of several interpretations.

  3. 03

    A validated scope for the wider platform

    What sits in the first release, what follows later, and what is deliberately left out.

  4. 04

    A complete product blueprint

    Every major user, action and interaction defined, with the business processes behind them.

  5. 05

    A clear technical and security direction

    How the platform is built, where information lives, and how customers, money and company data are protected as volumes grow.

  6. 06

    Confirmed partners, integrations and dependencies

    Which external systems BizzPays relies on, how they connect, and what has to be in place before the build starts.

  7. 07

    The delivery team and resources required

    The people, skills and capacity needed to build BizzPays, and how they are organised.

  8. 08

    A realistic implementation programme

    Delivery phases, sequence and timeline, including what can run in parallel and what has to wait.

  9. 09

    A defensible budget for the full build

    Cost by phase, the assumptions behind it and the areas still carrying uncertainty, so the board approves a figure that holds.

  10. 10

    A clearer picture of how BizzPays earns

    The revenue mechanisms across the ecosystem mapped against the platform being built.

How we arrive at the final build cost

Phase 1 is a simulation of the production build, run before BizzPays commits to carrying it out

Rather than estimating the platform from a high-level feature list, we work through the programme as though the production team were preparing to begin development.

  1. 01Platform vision
  2. 02Agreed V1 scope
  3. 03User journeys
  4. 04Interfaces and screens
  5. 05Business processes
  6. 06Data requirements
  7. 07Technical services
  8. 08Integrations
  9. 09Security requirements
  10. 10Engineering work
  11. 11Dependencies
  12. 12Delivery team
  13. 13Simulated development programme
  14. 14Cost

Every major BizzPays capability becomes a build package covering:

  • What the user needs to do
  • What the interface needs to provide
  • What must happen behind the interface
  • What information must be stored
  • Which external partners or services are required
  • Which security controls are required
  • What internal BizzPays staff need to manage
  • What happens when something fails
  • What must be tested
  • What infrastructure is required
  • What engineering resources are needed to deliver it

Each package is estimated individually, rather than attempting to estimate BizzPays as one large project. That is the evidence behind the final programme budget, set out in section 14, The Planning Range.

04Phase 1

The BizzPays product foundation

Phase 1 ends with more than documents. There is a BizzPays brand, a full set of screen designs, a design system, a clickable prototype and a documented technical foundation that leadership, partners and the board can look at, click through and independently verify.

BizzPays brand identity

Logo system, colour, typography, imagery direction and usage rules, delivered as a brand guide that is ready for handover and owned by BizzPays.

Full product design

Wireframes for the main journeys first, then finished visual designs of every core screen across mobile and desktop, so the interface is decided before any production code is written.

A design system

The reusable components, states and patterns the full build assembles screens from, rather than each screen being redrawn from scratch.

A complete clickable prototype

Not a slideshow. The core journeys wired end to end (registering, an account, a business profile, a payment, an application and a partner service), openable on a phone or laptop and clicked through without a guide. This is the real interface, without live money or live data behind it.

The technical foundation, designed and documented

The database structure defined table by table with the relationships between them, plus infrastructure and system diagrams showing environments, services, integrations and where information lives. Complete enough for an external engineer or CTO to review and price against.

The value is simple: the vision becomes easier to explain, easier to sell internally and easier to build, because the shape of the platform has already been decided.

What it is not
  • The prototype demonstrates the real interface, but does not process live payments, hold live customer accounts or connect to live partner systems.
  • The backend is defined and diagrammed, not yet built. No live money or live data runs through it.
  • Content and figures shown inside the prototype are illustrative until confirmed by BizzPays and its partners.
  • One narrow technical journey is trialled in provider sandbox environments to measure engineering effort. No live customer money, live customer accounts or partner production systems are involved.
  • The production build of the platform itself is a separate phase.
Built to be independently verified

Every Phase 1 output is designed to be handed to an independent reviewer and checked. That is the point of producing them.

A technical adviser or CTO

Whether the architecture, database schema and integration plan are sound and buildable.

A security consultant

Whether protection requirements, access control and resilience are defined to a reviewable standard.

An investor's engineer

Whether the scope, team, timeline and budget are defensible against the deliverables produced.

Another development firm

Whether they could pick up the design system, prototype and technical foundation and continue the build.

05Phase 1

The full build blueprint

The second Phase 1 outcome is the plan for the full build: validated scope, architecture, security, delivery phases, team, timeline and a costed programme.

  • Exactly what the first release includes

    One agreed launch definition covering the services that must work, what can follow, and what is excluded.

    Deliverable: V1 Scope & Launch Definition

  • Every user, action and interaction defined

    What consumers, merchants, staff and partners do, what happens when something is refused or fails, and the processes behind each journey.

    Deliverable: Product Requirements Document, Build-Ready User Story Set, Key User Journey Flows

  • Which partners BizzPays depends on, and whether they are ready

    What each partner already has, what has to be built, what information moves between organisations and what is missing today.

    Deliverable: Partner & Integration Readiness Matrix

  • What the technology has to support, so the build can be costed

    Payments, accounts, identity, data, infrastructure and monitoring, with the cost and dependency implications of each option made explicit.

    Deliverable: Platform & Technology Specification

  • How BizzPays keeps control of its platform and its data

    What BizzPays owns, where information is held, what partners may access and how a supplier can be replaced without losing the customer relationship.

    Deliverable: Platform Ownership & Data Control Blueprint

  • How users, transactions and company information are protected

    Account protection, staff and partner access, monitoring, incident response and recovery, prepared for review by your appointed security adviser.

    Deliverable: Security & Customer Protection Strategy, Resilience & Recovery Requirements

  • How BizzPays builds its audience during the build

    A smaller pre-launch experience so registrations, interest and referrals accumulate while the platform is under construction.

    Deliverable: V0 Pre-Launch Network Specification

  • What is required to actually run the business day to day

    The internal tools, approvals, support and oversight the operating team needs behind the customer experience.

    Deliverable: Operations & Management Requirements

  • How the full build is sequenced, resourced and priced

    Delivery phases, dependencies, team, timeline and cost by phase, with the uncertain areas named rather than hidden.

    Deliverable: Master Delivery Backlog, Delivery Roadmap, Team & Resource Plan, Delivery & Investment Plan

The full build investment plan

We have completed an initial bottom-up simulation of the production programme, so the board can see the likely level of capital commitment today: approximately £2.32m for the recommended build after Phase 1, inside a range of approximately £1.98m to £3.76m including this phase. Those are planning figures. The final figure depends on validated scope, services at launch, integrations, security requirements, infrastructure, user volumes, operating requirements, the delivery team and the rollout strategy. Phase 1 establishes each of those and returns the cost by delivery phase, with the assumptions and remaining uncertainty stated. Sections 13 to 16 set out the method, the range, the assumptions behind it and the cost of operating at scale.

Questions answered by the end of Phase 1

  1. 01
    What exactly is BizzPays V1?

    Without a fixed launch definition, cost, team size and timeframe remain moving targets.

  2. 02
    What are the principal launch opportunities?

    The wider vision contains many opportunities, but the first public release requires a deliberate and agreed selection.

  3. 03
    What does BizzPays itself own and operate?

    Core strategic capability should not unintentionally become controlled by an external supplier.

  4. 04
    What should be provided by partners?

    Using proven specialist systems in the right places cuts development time and cost.

  5. 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.

  6. 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.

  7. 07
    How will the platform be protected?

    Financial platforms become increasingly attractive targets as user base and transaction volumes increase.

  8. 08
    What happens if a partner or service becomes unavailable?

    One supplier should not be able to disable the wider BizzPays ecosystem.

  9. 09
    What can begin before the full platform is complete?

    BizzPays intends to build demand and register prospective users during development.

  10. 10
    What team is required?

    Programme duration depends directly on expertise, team size and how much work can safely happen in parallel.

  11. 11
    What will V1 realistically cost?

    The board should understand both the overall investment and what that investment is buying.

  12. 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.

06Phase 1

Risk reduction

Phase 1 is the point at which the largest risks in a programme of this size are removed, while the amount committed is still comparatively small.

Approving a figure, then being asked for more
The full build budget is produced from a validated scope, with assumptions and uncertain areas stated in writing.
Scope growing without control
The first release is defined and agreed before development spending begins.
An integration turning out not to be possible
Each partner and system is confirmed ready in Phase 1, not discovered mid build.
Security added late and expensively
Protection requirements shape the platform design, and are prepared for independent review.
Rework caused by unclear requirements
Requirements, journeys and processes are documented before engineers start building.
Under-resourcing the programme
The team and capacity needed are modelled against the real scope.
An unrealistic timeline
Sequencing and dependencies are mapped, so the programme reflects what can genuinely run in parallel.
Committing major capital too early
The first portion of the investment establishes certainty before the larger commitment is made.

How Phase 1 narrows the planning range

The range of approximately £1.98m to £3.76m is wide today because a number of decisions could materially change the nature of the programme. Phase 1 targets the largest sources of uncertainty first.

Regulatory and financial operating model

Confirm which activities BizzPays carries out itself and which sit with authorised partners.

V1 scope

One board-approved definition of what is genuinely required at launch.

Payment architecture

Test the selected payment provider in a sandbox and confirm funding, transfers, transaction status, reversals, reconciliation and exception handling.

Ledger and reconciliation

Prototype the financial record and reconciliation approach before the wider build commits to it.

KYC and KYB

Assess proposed providers against the BizzPays customer and business journeys and obtain commercial pricing.

Partner readiness

Review documentation, technical capability, commercial dependencies, sandboxes and responsibilities for every proposed V1 partner.

Voice and AI

Prototype representative conversations, confirm language requirements, latency and usage cost, and define what the AI is and is not permitted to do.

Security

Complete the initial threat model and agree the security, privileged access, data, recovery and monitoring requirements.

Scale

Replace broad user ambitions with measurable operational assumptions: users, active users, concurrency, transactions, payment volume, requests, data growth and retention.

A representative end-to-end technical trial

Registration, authentication, identity verification, account creation, payment provider interaction, financial record, transfer, reconciliation, administration, audit and monitoring.

We build or simulate one narrow technical journey across that chain in provider sandboxes. The purpose is not to launch it during Phase 1. It is to measure the real engineering effort behind the most important assumptions in the estimate, then compare actual effort against our original figures and recalibrate the programme.

This is a non-production trial in sandbox environments. No live customer money, live customer accounts or partner production systems are involved, and it does not form part of the built platform.

The principle is straightforward: commit the first portion of the investment to establishing certainty, so the substantially larger commitment that follows is made against a plan rather than an estimate.

07Programme

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

At present, different stakeholders could interpret "BizzPays V1" very differently. For one person it may mean accounts and payments. For another it may mean travel. For another it may mean housing, mobility, farming and several commercial opportunities. Until this boundary is agreed, any quotation or timetable relies on assumptions.

BizzPays V1 Scope & Launch Definition
08Programme

Twenty-seven defined outputs

Each output exists because something in the build depends on it. The business outcome comes first, with the output named underneath. The next section traces each one into the stage of the build it feeds.

  • 1
    Exactly what BizzPays intends to launch
    Deliverable: V1 Scope & Launch Definition
  • 2
    What the platform must do
    Deliverable: Product Requirements Document
  • 3
    What each type of user needs
    Deliverable: Build-Ready User Story Set
  • 4
    How important experiences work end to end
    Deliverable: Key User Journey Flows
  • 5
    What BizzPays builds versus what partners provide
    Deliverable: Partner & Integration Readiness Matrix
  • 6
    What technology is required
    Deliverable: Platform & Technology Specification
  • 7
    How BizzPays retains strategic control
    Deliverable: Platform Ownership & Data Control Blueprint
  • 8
    How users, money, data and services are protected
    Deliverable: Security & Customer Protection Strategy
  • 9
    How the platform responds to failures
    Deliverable: Resilience & Recovery Requirements
  • 10
    How BizzPays builds its network during development
    Deliverable: V0 Pre-Launch Network Specification
  • 11
    How BizzPays will operate the platform internally
    Deliverable: Operations & Management Requirements
  • 12
    Everything required to deliver V1
    Deliverable: Master Delivery Backlog
  • 13
    What could block or delay delivery
    Deliverable: Dependency & Readiness Map
  • 14
    How the programme should be sequenced
    Deliverable: V1 Delivery Roadmap
  • 15
    Who is required to deliver the programme
    Deliverable: Team & Resource Plan
  • 16
    Cost, speed and risk trade-offs
    Deliverable: Delivery & Investment Plan
  • 17
    Final investment and development decision
    Deliverable: V1 Development & Investment Decision Pack
  • 18
    A consistent, owned visual identity ready for handover
    Deliverable: BizzPays Brand Identity & Guidelines
  • 19
    Every core screen designed across mobile and desktop
    Deliverable: Wireframes & Screen Designs
  • 20
    A reusable component library the build continues from
    Deliverable: BizzPays Design System
  • 21
    The real interface clickable end to end, without live money or data
    Deliverable: Interactive Clickable Prototype
  • 22
    The data structure defined and reviewable
    Deliverable: Database Schema & Data Model
  • 23
    Environments, services, integrations and data locations mapped
    Deliverable: Infrastructure & System Architecture Diagrams
  • 24
    Every significant build cost traced to a capability, integration or resource
    Deliverable: Bottom-Up Build Cost Model
  • 25
    Which costs are settled once scope is agreed and which grow with usage
    Deliverable: Fixed & Variable Cost Model
  • 26
    What different levels of success cost to operate
    Deliverable: Scale Economics Model
  • 27
    The estimate checked against measured engineering effort
    Deliverable: Technical Trial Findings & Estimate Recalibration
09Programme

From Phase 1 into the build

The full build programme starts from the items produced in Phase 1. Each one is the input to a specific stage of that build, so here is where every output lands and what the build has to guess at without it.

01
Mobilisation & contracting
  • 1
  • 14
  • 15
  • 16
  • 17
  • 24
  • 25
  • 26
  • 27

Without these: There is no agreed scope to contract against, no team to hire against and no budget for the board to approve.

02
Build sprints
  • 2
  • 3
  • 4
  • 12
  • 18
  • 19
  • 20
  • 21
  • 22

Without these: Developers design as they build. That is where cost, time and quality problems come from.

03
Hardening & integration
  • 5
  • 6
  • 7
  • 8
  • 9
  • 23

Without these: Protection, data control and partner behaviour are retro fitted, at several times the cost of building them in.

04
Launch readiness
  • 10
  • 11
  • 13

Without these: The platform is finished while the business is not ready to operate it or launch it to anyone.

01

Mobilisation & contracting

  • 1
    V1 Scope & Launch Definition

    Feeds into: Sets the boundary the build contract, sprint plan and budget are written against

    Without it: The build starts without an agreed finish line, so scope grows during development

  • 14
    V1 Delivery Roadmap

    Feeds into: Becomes the delivery schedule the build programme is run and reported against

    Without it: Progress cannot be measured against any committed date

  • 15
    Team & Resource Plan

    Feeds into: Is the hiring and mobilisation plan for the build team

    Without it: Recruitment begins after the build has been approved, delaying the start

  • 16
    Delivery & Investment Plan

    Feeds into: Sets the cost, pace and risk position the board signs the build off against

    Without it: The build budget is a single figure with no trade offs behind it

  • 17
    V1 Development & Investment Decision Pack

    Feeds into: Is the document the board approves the full build investment from

    Without it: The decision to commit major capital rests on assumptions

  • 24
    Bottom-Up Build Cost Model

    Feeds into: Is the evidence base the production budget and contract value are set from

    Without it: The build is priced from a feature list rather than the work it actually contains

  • 25
    Fixed & Variable Cost Model

    Feeds into: Separates the build budget from the operating budget the business plans around

    Without it: Usage-driven costs surface after launch as unplanned operating expense

  • 26
    Scale Economics Model

    Feeds into: Sets the infrastructure and operations budget as user volumes grow

    Without it: Success itself becomes a financial surprise

  • 27
    Technical Trial Findings & Estimate Recalibration

    Feeds into: Corrects the programme estimate before the production commitment is signed

    Without it: The largest assumptions in the budget stay untested until engineers hit them

02

Build sprints

  • 2
    Product Requirements Document

    Feeds into: Becomes the functional specification developers build to

    Without it: Requirements get decided mid-sprint by whoever is closest to the keyboard

  • 3
    Build-Ready User Story Set

    Feeds into: Loads directly into the build backlog as the work items developers pick up

    Without it: Sprint planning starts from scratch and estimates carry no evidence

  • 4
    Key User Journey Flows

    Feeds into: Gives developers and testers the end to end behaviour each journey must produce

    Without it: Individual screens work while the journeys between them break

  • 12
    Master Delivery Backlog

    Feeds into: Is the build backlog itself, sequenced into sprints on day one

    Without it: There is nothing concrete to plan, estimate or track delivery against

  • 18
    BizzPays Brand Identity & Guidelines

    Feeds into: Is applied across the built product, marketing and partner material

    Without it: Brand decisions get made screen by screen during development

  • 19
    Wireframes & Screen Designs

    Feeds into: Are the screens developers build, with no interpretation required

    Without it: Developers design while they build, which is where rework comes from

  • 20
    BizzPays Design System

    Feeds into: Is the component library the front end is assembled from

    Without it: Every screen is rebuilt by hand and the interface drifts apart

  • 21
    Interactive Clickable Prototype

    Feeds into: Is the reference build the team codes against and stakeholders sign screens off from

    Without it: Approval happens against static images and misreadings surface late

  • 22
    Database Schema & Data Model

    Feeds into: Is implemented as the live database structure in the first build sprints

    Without it: Data structure is invented early and migrated painfully later

03

Hardening & integration

  • 5
    Partner & Integration Readiness Matrix

    Feeds into: Determines which components are built in house and which integrate to a partner

    Without it: Work is built twice, or built against a partner system that cannot support it

  • 6
    Platform & Technology Specification

    Feeds into: Fixes the technology stack, services and providers the build is set up on

    Without it: Foundational technology choices are made under sprint pressure

  • 7
    Platform Ownership & Data Control Blueprint

    Feeds into: Governs how data, accounts and customer relationships are held as the platform is built

    Without it: Control of the most valuable assets drifts to external suppliers by default

  • 8
    Security & Customer Protection Strategy

    Feeds into: Sets the protection requirements built into the platform from the first sprint

    Without it: Security is bolted on late, which is the most expensive point to add it

  • 9
    Resilience & Recovery Requirements

    Feeds into: Defines the failure handling, backups and recovery behaviour built into the services

    Without it: Failure paths surface for the first time in front of paying customers

  • 23
    Infrastructure & System Architecture Diagrams

    Feeds into: Is what environments, services and integrations are provisioned from

    Without it: Infrastructure is assembled ad hoc and cost and security suffer for it

04

Launch readiness

  • 10
    V0 Pre-Launch Network Specification

    Feeds into: Runs alongside the build so a registered network exists on launch day

    Without it: The platform launches to an empty audience and growth starts from zero

  • 11
    Operations & Management Requirements

    Feeds into: Specifies the internal tools, admin screens and processes built for the operating team

    Without it: The platform ships with no way for BizzPays staff to run it

  • 13
    Dependency & Readiness Map

    Feeds into: Drives the order of work so partner, legal and provider dependencies are cleared in time

    Without it: Sprints stall waiting on approvals and third parties nobody chased early

The full build is scoped, sequenced, staffed and costed from these items. Phase 1 is not preparation ahead of the project. It is the first stage of it, and the stage everything after it is built on.

10Programme

Eight weeks, week by week

Phase 1 runs over eight weeks, covering the definition work, the brand identity, the full product design and design system, the clickable prototype, the documented technical foundation and the full build plan. The programme assumes timely access to BizzPays stakeholders, partners, advisers and service providers.

Programme length: 8 weeks, start to finish. What we need from BizzPays is timely access to stakeholders, partners and service providers during that period.
  1. 1
    Week 1
    Define BizzPays V1

    Launch scope, priority services, principal commercial opportunities and the brand direction

  2. 2
    Week 2
    Customers, processes, partners and wireframes

    User journeys, operational requirements, partner responsibilities and wireframes for the main journeys

  3. 3
    Week 3
    Brand identity, technology and provider decisions

    Logo system, colour, typography and imagery direction progressed, alongside the technology, payment, banking and identity decisions, with payment and KYC and KYB providers assessed and priced

  4. 4
    Week 4
    Platform control, data and security

    Platform structure, ownership model, threat model, security and resilience requirements, and the start of full screen designs

  5. 5
    Week 5
    Full product design, design system and the technical trial

    Finished mobile and desktop screen designs, the reusable component library assembled, and the representative end-to-end journey run in provider sandboxes

  6. 6
    Week 6
    Clickable prototype, technical foundation and voice and AI trial

    Core journeys wired into a complete clickable prototype, the database schema and infrastructure and system diagrams, and representative voice and AI conversations tested for cost and latency

  7. 7
    Week 7
    Delivery planning and bottom-up costing

    Backlog, dependencies, team structure, sequencing, partner readiness and each build package estimated from the bottom up

  8. 8
    Week 8
    Investment and board preparation

    Delivery phases, the minimum, expected and upper build cost, the fixed and variable and scale cost models, recommendations and the board pack

11Programme

How we work together

This programme cannot be defined effectively by Keza Studio working in isolation. The eight 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 instead of waiting for the weekly meeting, including the regular morning slots we 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

Keza Studio engages directly with technology providers to confirm 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.

12Programme

The delivery team

These are BizzPays project resources, not advisers reviewing from outside. Keza Studio's own leadership works inside the programme.

Active in Phase 1

Funded by this engagement

These are the roles whose time the £68,000 covers for the eight weeks of Phase 1.

  • Product & UX/UI Design Director
    In-housePhase 1

    Owns the BizzPays product definition, the brand identity and the end-to-end UX and UI direction, and supervises the design process directly

  • Technical Director
    In-housePhase 1

    Owns the platform structure, technology decisions and build feasibility, and the documented database schema, API contracts and infrastructure

  • Senior Engineering Specialist
    In-housePhase 1

    Payments, financial services, integrations and core platform requirements

  • Product & UX Lead
    In-housePhase 1

    Customer and merchant journeys, wireframes, full screen designs and the design system

  • Front-end Engineer
    In-housePhase 1

    Builds the complete clickable prototype from the finished designs and design system

  • Project Manager & Scrum Master
    In-housePhase 1

    Owns the delivery plan, sprint cadence, resource scheduling, dependencies and the full build investment model

Roles for the full build

Costed in the full build

These three roles are needed for the build itself rather than the Phase 1 delivery work. Where a hire is needed we begin that process during Phase 1, so candidates are in the pipeline ahead of the build, but they do not all need to be in place before this phase ends. They are costed within the full build programme, not the Phase 1 fee.

  • Senior DevOps Engineer
    To be hiredFull build

    Infrastructure, environments, deployment pipelines and operational readiness for the live platform

  • Backend Engineer
    In-houseFull build

    Owns the backend services, API contracts and database implementation for the live platform

  • Cybersecurity Specialist
    To be hiredFull build

    Security requirements, threat modelling and live platform protection

The nine roles above are the Phase 1 organisation. The production build needs a larger team, modelled at roughly twelve to thirty-four people depending on the pace chosen. Those options are in section 16, Cost At Scale, and are costed inside the production programme rather than this phase.

Capacity this phase requires

BizzPays is larger than a standard software project, and Phase 1 needs capacity reserved for it. The studio puts its resources into this programme for the eight weeks, so each item below is a real cost of running the team and is itemised in section 17.

  • Dedicated product and engineering time

    Senior Keza people working on BizzPays each week, not fitting it around other programmes

  • A desk for every team member

    Coworking space held for the full eight weeks so the team sits together on this programme

  • Equipment for everyone joining

    Machines and hardware leased for the duration, so new people are productive immediately

  • Software and AI tooling

    Design, collaboration, AI, documentation and modelling subscriptions per person

  • Development and test environments

    Hosting, tooling and environments used to build and demonstrate the foundation

  • Dedicated senior operations capacity

    Additional senior DevOps capacity brought on specifically for this programme

13The Full Build

The costing method

The full build estimate is produced across six connected layers, so every significant cost can be traced back to a defined capability, integration, resource, dependency or operating requirement.

  1. 01

    Product scope

    Exactly what must genuinely work in the first public release, separated so later opportunities cannot silently become part of the original quotation.

    • V1: required for the initial public release
    • V1.1 and subsequent releases: planned next
    • Future ecosystem: intentionally outside the initial build
  2. 02

    Build requirements

    Each capability is decomposed into the work actually required to make it function. Business onboarding, for example, covers registration, identity verification, company information, document upload, manual review, approval and rejection, notifications, permissions, audit records, administration tools and support processes. Each is estimated separately.

  3. 03

    Build, integrate or partner

    For every major capability we determine the right ownership position, which matters most across payments, identity verification, travel, mobility, financial products and other regulated or specialist services.

    • Own it, because it is strategically important to BizzPays
    • Build it, because appropriate external capability does not exist
    • Integrate it, because a mature specialist technology already exists
    • Partner for it, because specialist operational or regulatory responsibility sits better outside BizzPays
  4. 04

    Delivery effort

    Requirements are converted into individual engineering and delivery tasks and estimated across the resources required.

    • Frontend and product engineering
    • Backend and financial platform engineering
    • Quality assurance and automation
    • Infrastructure and DevOps
    • Security
    • Architecture
    • Product and business analysis
    • UX and product design
    • Programme and delivery management
  5. 05

    Delivery simulation

    The work is loaded into a realistic programme with dependencies and parallel workstreams.

    • What can happen at the same time
    • What must happen sequentially
    • Which roles become bottlenecks
    • What team size is required
    • How different team structures affect time and cost
  6. 06

    Commercial model

    The programme is then priced from the bottom up and presented as a minimum, an expected case and an upper planning case. Uncertainty is not hidden inside one arbitrary contingency percentage: higher-risk capabilities carry wider ranges than areas where scope is already well understood.

How the costs behave

Not all BizzPays costs behave the same way. They are separated so leadership can see which are largely known once the scope is agreed, and which grow with usage or commercial activity.

Mostly fixed build costs

Once V1 is agreed these become largely predictable, and form the principal production build budget.

  • Product design and requirements
  • Core platform engineering
  • Accounts and customer functionality
  • Ledger and reconciliation
  • Administration
  • Core security
  • Architecture
  • Testing
  • DevOps and release preparation
  • Programme management

Step variable costs

These increase when a specific decision is made, and are costed at that point rather than hidden inside the original scope.

  • Adding another live partner
  • Adding another payment provider
  • Building native mobile applications
  • Adding another country
  • Introducing active-active infrastructure
  • Adding ticketing or recruitment
  • Adding a significant new marketplace
  • Introducing a major new regulatory capability

Usage variable costs

These grow according to how much the platform is used.

  • Infrastructure and databases
  • Storage and bandwidth
  • Identity verification
  • SMS and notifications
  • AI and voice usage
  • Monitoring
  • Support technology

Transaction linked costs

Payment processing is treated separately and modelled as part of BizzPays unit economics rather than disguised as a fixed software cost.

  • Transaction count and value
  • Payment method and transfer volume
  • Provider and commercial rate
  • Whether charges are absorbed by BizzPays or passed to customers
14The Full Build

The planning range

The complete programme cannot responsibly be reduced to a fixed price before scope, partners, financial responsibilities and technical requirements are validated. That should not stop BizzPays leadership seeing the likely level of investment.

Planning cases

Minimum responsible launch
c. £1.91m
c. £1.98m
c. 10 to 12 months
Recommended V1Recommended
c. £2.32m
c. £2.38m
c. 12 to 13 months
Upper planning case
c. £3.69m
c. £3.76m
c. 13 to 18+ months
Recommended capital planning position

Plan around approximately £2.4m for Phase 1 plus the recommended production programme, while retaining an upper planning envelope of approximately £3.8m until the major assumptions have been validated.

These are bottom-up planning figures, not a fixed quotation. Phase 1 replaces the assumptions behind them with evidence.

Recommended V1 cost structure

Product engineering, backend, frontend, QA, infrastructure, security and delivery
c. £1.49m
Architecture, business analysis and product and UX support
c. £253k
Independent penetration testing and retesting
c. £35k
Privacy, payments and compliance related technical assurance
c. £30k
Development, test and load testing infrastructure
c. £50k
Engineering, security and programme tooling
c. £35k
Device, browser and mobile testing
c. £15k
Supplier sandbox, setup and technical support allowances
c. £25k
Expected build subtotal
c. £1.93m
Delivery contingency at the current uncertainty level
c. £386k
Current recommended production build estimate
c. £2.32m

With the £68,000 Foundation & Build Readiness phase, that gives a total programme planning figure of approximately £2.38m, inside a current range of c. £1.98m to c. £3.76m. The figures are recalculated during Phase 1 as partner information, technical decisions and validated build requirements replace the assumptions in use today.

What each case means

Minimum responsible build

c. £1.91m after Phase 1

This is not the same platform built more cheaply. It is a deliberately narrower launch, with some ecosystem services and deeper functionality moving into later releases.

  • Customer and business identity
  • Core account experience
  • Payment orchestration
  • Ledger and reconciliation
  • Essential risk controls
  • Referrals
  • Core administration
  • Security and reliability
  • Pre-launch registration
  • A smaller number of live partner services

Recommended V1

c. £2.32m after Phase 1

Our present working recommendation. The core financial platform plus a meaningful wider BizzPays ecosystem at launch.

  • Approximately four partner service integrations
  • Merchant and opportunity discovery
  • Referrals and reusable application processes
  • Operational administration and reporting
  • Text and voice assisted AI
  • Security, resilience and testing
  • Controlled launch preparation

Upper planning case

c. £3.69m after Phase 1

Not extra features. This is the high-side cost of delivering approximately the same strategic V1 where complexity proves greater than currently expected. We recommend the board keeps it visible until the major uncertainties are resolved.

  • More difficult payment or financial integrations
  • Partner APIs requiring substantially more work
  • Expanded security requirements
  • Additional regulatory requirements
  • Greater infrastructure resilience
  • More extensive performance engineering
  • Complex exception and operational processes
  • Longer external approval or certification cycles

The final investment plan

At the end of Phase 1 the investment plan does not simply state a number. It shows what the number buys, what assumptions it depends on, which costs are fixed, which change with scale, what sits outside the figure, what would move the price, and what further opportunities would cost if they were brought into scope.

15The Full Build

The assumptions behind the range

The planning range depends on the working assumptions below. Phase 1 confirms or replaces each one, which is how the range narrows.

Market

BizzPays launches into Nigeria first, before expanding into additional markets.

Financial infrastructure

BizzPays owns the customer experience, orchestration, application technology and strategic data layer. Authorised specialists provide regulated financial infrastructure. The recommended V1 does not assume BizzPays builds its own payment switch or independently holds customer funds.

Payments

One primary live payments provider initially, with the architecture designed so further providers can be added. A second fully operational provider with automatic routing or failover is not included unless specifically approved.

Customer application

A mobile-first customer platform with responsive desktop support. Two separately engineered native iOS and Android products are not currently included. The mobile delivery approach is confirmed in Phase 1.

Partner services

Approximately four meaningful live partner integrations in V1. Additional partners carry an identifiable incremental cost.

AI and voice

Text-based AI support and voice interaction are included in the recommended case, so customers who find typing or complex financial interfaces difficult are supported. AI is not assumed to independently authorise or move customer money.

Travel, mobility, property and financial services

Modelled as BizzPays experiences connected to specialist providers, rather than separate industries rebuilt from first principles inside BizzPays.

Ticketing and recruitment

These fit naturally into the wider ecosystem but are not in the recommended V1 budget. If brought into V1 they are separately scoped and costed.

Media and TV

A full live video, television or user-generated media platform is not included in the current V1 estimate.

Physical POS

A proprietary physical terminal estate and the associated agent management platform are not currently included.

Scale

Headline user figures are treated as registered users rather than all users being active at once. Phase 1 replaces this with actual targets for monthly active users, peak concurrent users, payments per user, transaction volumes and value, AI usage, messaging, storage and data retention.

16The Full Build

Cost at scale, and programme options

Build cost and operating cost are different things. This section shows what BizzPays may cost to run as it grows, and how team size affects the length of the production programme.

Technology operating cost by scale

500,000 registered
c. 175,000
c. £149k / month
2 million registered
c. 700,000
c. £369k / month
5 million registered
c. 1.75 million
c. £775k / month
20 million registered
c. 7 million
c. £2.37m / month
What the figures include
  • Core cloud infrastructure
  • Application and database services
  • Network and content delivery
  • Security and monitoring
  • Identity verification
  • Messaging
  • AI and voice
  • Platform operations and SRE
  • Security operations
  • Technical compliance support

These figures exclude payment transaction fees, marketing, the full customer service workforce, regulatory capital, physical operations and costs belonging to third-party commercial partners. They are planning scenarios rather than supplier quotations, rebuilt in Phase 1 against real assumptions and, where possible, actual commercial quotations.

The variables that drive it

Registered users, active users, transactions, transaction value, messages, KYC and KYB checks, AI and voice use, data volume and peak system demand.

Production programme options

Lean programme
c. 12 people
c. 24 to 26 months
Recommended programmeRecommended
c. 23 people
c. 12 to 13 months
Accelerated programme
c. 34 people
c. 9 to 10 months

These are production build team sizes, not the Phase 1 team. A larger team can accelerate the programme, but doubling team size does not halve delivery time. Payment architecture, partner readiness, security, testing, certification and real-world pilot activity create dependencies that cannot be removed by adding engineers.

17Investment

Where the investment goes

The £68,000 is all inclusive. Here is what it covers, area by area, including the cost of running the team for the eight weeks.

Delivery work allocation

Product strategy, scope and requirements

Launch definition, requirements, user stories and business processes

£9,000
Brand identity and design system

Logo system, colour, typography, imagery direction, usage rules and the reusable component library the build assembles screens from

£7,000
Product design: wireframes and full screen designs

Wireframes for the main journeys, then finished visual designs of every core screen across mobile and desktop

£10,000
Clickable prototype build

The core journeys wired end to end into a complete clickable prototype, openable on a phone or laptop

£8,000
Technical architecture, database and infrastructure design

Platform structure, technology options, integrations, the database schema and the infrastructure and system diagrams

£9,000
Security, data and integration planning

Protection requirements, data control, resilience and integration readiness

£5,000
Commercial, delivery and investment modelling

Revenue mechanisms, delivery phases, team model and the full build budget

£5,000
Delivery work
£53,000

Programme running costs, included in the £68,000

For these eight weeks the studio puts its resources into BizzPays, so these are real dedicated costs rather than overhead absorbed somewhere else. Every person on the programme has a desk, leased equipment and the software they need. These sit inside the total, they are not added to it.

Software and tooling

Design software, collaboration and messaging tools, AI tooling, documentation and modelling subscriptions for every person on the programme

£2,600
Equipment leased for the team

Machines and hardware leased for the eight weeks so everyone joining the programme is equipped from day one

£4,400
Coworking space for every team member

A desk for each person for the duration, so the team works together on BizzPays daily

£5,200
Resourcing dedicated senior capacity

Bringing on and onboarding additional dedicated senior operations capacity for this programme

£2,800
Programme running costs
£15,000
Delivery work
£53,000
Programme running costs
£15,000
Total Phase 1 investment
£68,000

This is how the fee is allocated. The allocation covers the eight-week programme in full: the brand identity, the product design and design system, the clickable prototype, the documented technical foundation and the build plan and budget.

18Investment

Phase 1 investment

Phase 1 establishes the product, commercial, technical and operational foundations required to move BizzPays into full-scale delivery. A flat fee for a defined body of work.

Phase 1: Foundation & Build Readiness
£68,000

All inclusive: £53,000 delivery work and £15,000 programme running costs, nothing added on top

Covering the eight-week programme, the delivery team, the brand identity, screen designs and design system, the clickable prototype, the documented technical foundation and the full build plan and budget, together with the desks, equipment, software and AI tooling the team runs on.

Stage payments
  • Phase 1 mobilisationOn approval£28,000
  • Definition and foundation milestoneEnd of Week 4£20,000
  • Phase 1 completion and board packOn completion£20,000
A flat fee for Phase 1. On completion, BizzPays owns the outputs and the programme moves to the full build, quoted separately from the plan and budget produced here.

What the investment produces

This phase commits senior product, technical, security and delivery people to BizzPays over eight weeks. The work includes:

  • Settling the BizzPays platform definition with your team
  • Defining a complex V1 programme
  • Working directly with BizzPays stakeholders
  • Confirming what specialist partners and third-party services can deliver
  • Selecting and specifying the technology the platform runs on
  • Defining how users, money and data are protected and recovered
  • 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 BizzPays brand identity, full screen designs, a design system, a clickable prototype, a documented technical foundation and a full definition of the platform and the information needed to make technology, partner, staffing and investment decisions. That holds whoever ultimately builds it.

At the conclusion of Phase 1, BizzPays leadership and its investment team will have enough visibility to make informed decisions about the complete delivery programme: what is being built, in what order, by whom, over what period and at what cost.

19Beyond Phase 1

After Phase 1

Phase 1 ends with a board pack: the validated scope, the delivery programme, the team and the costed full build. From there the sequence is clear.

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

Cost control during the programme

BizzPays is an evolving ecosystem and further opportunities will emerge during delivery. The objective is not to prevent that. It is to make the financial impact visible before additional work is authorised, so new ideas do not become hidden cost increases.

  1. 01
    Define the requested capability

    What is being proposed, and why.

  2. 02
    Assess programme impact

    What new product, engineering, integration, security, infrastructure and operational work it creates.

  3. 03
    Estimate minimum, expected and maximum cost

    The likely range rather than a single optimistic figure.

  4. 04
    Assess timing

    Whether it extends the programme or can run in parallel.

  5. 05
    Assess ongoing cost

    Whether the capability creates new recurring or usage-based costs.

  6. 06
    Approve before build

    Work enters the delivery programme only once the commercial and programme impact is understood.

Programme governance

Once production begins, four commercial measures are maintained throughout delivery and reviewed alongside progress at the regular BizzPays programme meeting, so the board has ongoing financial visibility rather than a forecast that changes at the end of a phase.

Approved programme value

What BizzPays has authorised.

Committed and spent

What has already been contractually committed or used.

Estimate at completion

What the programme is currently expected to cost based on actual progress.

Upper risk exposure

What the programme could cost if currently identified risks materialise.

From foundation to long-term platform

The opportunity does not end with one software release. The recommended programme treats the initial build as the foundation of a continuing platform, so BizzPays can make progress without attempting to build every long-term opportunity into the first public release.

  1. 01Foundation & Build ReadinessDefine and validate the platform.
  2. 02Production BuildBuild the agreed V1.
  3. 03Controlled LaunchRelease to a managed audience and prove the operating model.
  4. 04ScaleIncrease customer volumes and strengthen infrastructure and operations.
  5. 05Ecosystem ExpansionIntroduce further partners, services, products and countries on the architecture established earlier.

The objective is to enter the full build with the fundamental questions already answered, so development money is spent building BizzPays rather than repeatedly working out what BizzPays is meant to be.

20Beyond Phase 1

Commercial opportunity

This is not only a software programme. BizzPays is the operating foundation of a business, so Phase 1 treats how the platform earns as a design requirement rather than an afterthought.

  • Transactions across the ecosystem

    Payments and financial activity moving through BizzPays accounts rather than around them.

  • Business services

    Services sold to merchants and businesses operating on the platform.

  • Partner and commission arrangements

    Value earned where BizzPays introduces customers to specialist partners across travel, mobility, property, finance, insurance and agriculture.

  • Referral and representative network

    Associations, organisations and individuals bringing customers in, with attribution recorded from the first registration.

  • Recurring relationships

    Ongoing accounts and subscriptions rather than one-off transactions.

  • Network effects

    Each additional service, partner and member making the others more valuable, which is the strategic reason for building one platform rather than several products.

The mechanisms above come from the BizzPays material already shared. The cost side of the business is modelled in the full build sections; commercial rates, volumes and revenue forecasts are not, because they depend on partner agreements BizzPays holds. Phase 1 attaches figures to these mechanisms where BizzPays and its partners can supply them.

21Close

Scope boundaries, ownership and success

Phase 1 defines BizzPays and builds a demonstrable foundation. It does not include the production build, which keeps this phase from drifting into an unstructured development engagement.

Not included in Phase 1

  • Production build of the platform

    Phase 1 produces a demonstrable product foundation, not a live platform. The one exception is a narrow technical trial run in provider sandboxes to measure engineering effort, which is not part of the built platform. Live accounts, payments and partner connections are built in the full programme

  • Third-party licence costs for the built platform

    The software and tooling the Phase 1 team runs on is included in the running costs. Providers and expected costs for the live platform may be identified; those 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 confirm 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 the outputs

Once all Phase 1 fees are paid, BizzPays receives the agreed BizzPays-specific outputs created in this phase, including the product foundation. BizzPays will not be required to continue with Keza Studio in order to use the designs, specifications and build plan. 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
22Close

Why Keza, and the next step

BizzPays holds the vision, the commercial ambition and the market. Keza Studio brings the product, design, architecture, security and delivery capability to turn that into something buildable.

We build, we do not only advise

Keza Studio is the product and technology delivery partner for BizzPays. Phase 1 is led by the same people who would build the platform.

Senior people on the work

Product, commercial and technical leadership sit inside the delivery team rather than reviewing it from outside.

A clear division of responsibility

BizzPays holds the vision, the commercial relationships and the market. Keza brings product, design, architecture, security and delivery.

The next step

Phase 1 begins on approval. Eight weeks later BizzPays has a product it can demonstrate and a costed programme for the full build.

The work in this phase settles what BizzPays is at launch, how it is built, who builds it, over what period and at what cost. Everything produced is BizzPays-owned and open to independent review.

The decision in front of the board

The decision is not whether to commit approximately £2.4m to production now

It is whether BizzPays commits £68,000 and 8 weeks to establishing enough certainty to make that larger decision responsibly. We already have enough information to believe the wider programme represents a multi-million-pound technology investment, with a central planning case of approximately £2.38m including Phase 1 and a current range of approximately £1.98m to £3.76m. What we do not yet have is the evidence to tell the board where in that range the programme should sit. That is what Phase 1 establishes.

At the end of the eight weeks, the next investment decision is made with:

  • A defined product
  • A demonstrable experience
  • A validated technical architecture
  • Confirmed partner dependencies
  • A security strategy
  • A delivery organisation
  • A realistic programme
  • A minimum, expected and upper build cost
  • A fixed versus variable cost model
  • A scale economics model
  • A clear understanding of what would move those figures

Commit the first portion of the investment to establishing certainty, so the substantially larger investment that follows is made against an independently reviewable plan rather than a guess.

Downloads

Take the documents with you

Download either document to read offline or circulate to your team.