Blockchain Tender Planform

The Challenge

I grew up and started my career in South Africa, which is known globally for rugby, beautiful wildlife and corruption. Like in any country, government projects, whether it be building roads, bridges, IT systems etc, get published on a public tender platform to which registered companies can bid. Similarly for many listed companies they too need to issue a formal tender to which various known companies can bid.

What should happen:

  1. Bids are published to the platform

  2. Companies receive, assess and bid with their solution and price before due date

  3. All bids assessed objectively based on track record, price, solution etc

  4. A decision made for the best provider

The challenge is that most bids are secured behind closed doors before the tender is even submitted to the public or platform.

What actually happens:

  1. Bids are published to the platform

  2. Companies do their assessment and submit their solution & pricing

  3. The assessors review these, share the info to their ‘preferred providers’ who then submit their bid at a lower price + ‘fee’

  4. The preferred provider wins and a ‘fee’ is given to the publishing company

  5. Actual vs sold project delivery and pricing is not tracked, or tracked elsewhere.

By ‘Fee’ I mean: If a project is priced at $100mil, the actual deliver cost is $80mil, and the $20mil is split between the ‘preferred provider’ and the company.

This happens all the time, it’s nothing new!

The Solution

A tender platform whereby companies can create new tenders and submit to the platform with all the respective meta data and tender requirements. Providers can received, accept and submit their bid + meta data. Furthermore, due to the Blockchain layer the platform is almost ‘immediately auditable’ by regulatory agencies.

It seems Cambridge Institute of Technology had a similar idea, but just slightly different.

Key points:

  1. All tender information and submitting information is written in a smart contract

  2. All acceptances, submission and submission information is hashed and stored on the chain

  3. And all bids can only be opened after a certain date and they are all opened at the same time.

  4. All timing with regards to when documents are read, and engagement data is also hashed ie: Like any website analytics stats.

Point 3 is the critical one because it means that all bids are opened and no bids can then be changed.

We need to solve the issue whereby a bid is opened and then the lower price is shared to someone else, who can then change it on their 1st bid.

Challenges

  1. Getting government agencies to endorse this as ‘the platform’ of truth given that they are incentivised to keep the current off-chain process

  2. Hashing costs & gas fees if we are hashing so much meta data

  3. Companies / governments use mainly offline tools ie: Word / excel etc and likely won’t want to work much within the tool whilst we need as much to go through the tool as possible to ensure we can track engagement.

  4. Tracking actual project delivery to bid information si very tough given the variety of industries / solutions and shear volume of sub-contratcors involved in any delivery.

Tech & Product

Phase 1:

  1. System Admin Portal (Manage registered companies & vendors + oversee the operational elements and conflict resolution when neccessary)

  2. Company Portal (Creating Bids)

  3. Vendor Portal (Submitting Bids)

I would start with 1-2 main industries / sectors and it would be important to have engagement tracking tools like Mix Panel to ensure feature usage.

Phase 2 & beyond:

  1. Allow for companies to be Vendors too and vis verse

  2. Develop industry / sector and service specific workflows ie: Construction could be different to tech or other supplies

  3. Develop project tracking modules where companies can see the sold vs actual progress

  4. This could then tie into their rating and portfolio for future bids

  5. Build in

Possible Tech:

I’m not a technical person per se but I would use:

  1. Polygon Chain for smart contracts and hashing

  2. React Front-end

  3. Node.js for the back-end

  4. AWS hosting the web application

  5. Kubernetes for orchestration

Hold tight - I will flesh this out a bit more in the future

Conclusion

Phase 1 of the solution is viable. The interface should fairly simple and the underlying technology to create & publish tenders, receive and submit bids, and for companies to select their provider should not be overly complex.

When post sales delivery needs to be tracked / reported then we enter a space that is for another post :)

Previous
Previous

Your AI Guru

Next
Next

Interactive Loyalty