DEV Community

Cover image for Designing BuildBridge: A Large-Scale Construction Project Management Platform
Daniel Kuboi
Daniel Kuboi

Posted on

Designing BuildBridge: A Large-Scale Construction Project Management Platform

1. What is BuildBridge?

BuildBridge is a construction technology platform that connects project owners, contractors, construction workers, material suppliers, transport providers, and administrators in a single ecosystem.

The platform enables:

  • Discovery of verified contractors
  • Digital contract signing
  • Real-time project communication
  • AI-powered material quotation
  • Construction materials marketplace
  • Transport and logistics coordination
  • Live project monitoring through photos and videos
  • Escrow-based milestone payments
  • Worker and supplier directories

Unlike traditional construction management that relies on phone calls, WhatsApp groups, spreadsheets, and paper contracts, BuildBridge provides transparency and accountability throughout the entire project lifecycle.

2. Requirements and Goals of the System

We will focus on the following requirements while designing BuildBridge.

Functional Requirements

User Management

  1. Users should register and login.
  2. Users should select roles.
  3. Contractors should undergo verification.

Contractor Discovery

  1. Search contractors using location.
  2. Filter by experience, rating, trade and budget.
  3. View contractor portfolios.
  4. Send Requests for Quotations (RFQs).

Contract Management

  1. Generate legal contracts.
  2. Support digital signatures.
  3. Store signed contracts.

Communication

  1. Real-time chat.
  2. File sharing.
  3. Notifications.

AI Quotation

  1. Generate material estimates.
  2. Estimate project costs.
  3. Convert quotation into purchase orders.

Marketplace

  1. List materials.
  2. Manage inventory.
  3. Place orders.

Logistics

  1. Book transportation.
  2. Track deliveries.

Project Execution

  1. Define project milestones.
  2. Upload live photos and videos.
  3. Approve or reject milestones.

Payments

  1. Escrow deposits.
  2. Milestone releases.
  3. Payment tracking.

Non-Functional Requirements

Availability

99.9% uptime

Reliability

No contracts, payments, photos, or project records should be lost.

Performance

Contractor Search < 2 seconds

AI Quotation < 5 seconds

Chat Delivery < 500 milliseconds

Page Load < 3 seconds

Scalability

Support:

  • 50,000 users in Year 1
  • 500,000 users in Year 3
  • Millions of users long term

3. Design Considerations

BuildBridge differs from social networks because it is transaction-heavy rather than content-heavy.

The platform must support:

Heavy Writes

  • Photo uploads
  • Video uploads
  • Payment transactions
  • Chat messages
  • Contract updates

Heavy Reads

  • Contractor searches
  • Marketplace searches
  • Project dashboards
  • Material catalogs

High Reliability

Construction projects can involve millions of shillings.

Loss of:

  • Contracts
  • Payments
  • Milestone records

is unacceptable.

Trust

The platform's biggest challenge is establishing trust between project owners and contractors.

This is achieved through:

  • Escrow payments
  • Contractor verification
  • Live media uploads
  • Digital contracts

4. Capacity Estimation and Constraints

Let's estimate the scale of our system.

Users

Assume:

500,000 registered users

20% daily active users

500,000 × 20%
=
100,000 DAU
Enter fullscreen mode Exit fullscreen mode

Projects

Assume:

50,000 active projects

Each project uploads:

20 photos daily

50,000 × 20
=
1,000,000 photos/day
Enter fullscreen mode Exit fullscreen mode

Photo Storage

Average photo size:

5 MB
Enter fullscreen mode Exit fullscreen mode

Storage per day:

1,000,000 × 5 MB
=
5,000,000 MB

=
5 TB/day
Enter fullscreen mode Exit fullscreen mode

Storage per year:

5 TB × 365

=
1,825 TB

=
1.8 PB/year
Enter fullscreen mode Exit fullscreen mode

Video Storage

Assume:

200,000 videos/day

Average video:

50 MB

Storage/day:

200,000 × 50 MB

=
10,000,000 MB

=
10 TB/day
Enter fullscreen mode Exit fullscreen mode

Storage/year:

10 TB × 365

=
3.65 PB/year
Enter fullscreen mode Exit fullscreen mode

Total Media Storage

Photos = 1.8 PB/year

Videos = 3.65 PB/year

Total

=
5.45 PB/year
Enter fullscreen mode Exit fullscreen mode

Media storage becomes the largest cost in the system.

Chat Messages

Assume:

100,000 active users

Average:

50 messages/day

100,000 × 50

=
5,000,000 messages/day
Enter fullscreen mode Exit fullscreen mode

Messages per second:

5,000,000

÷ 86,400

=
58 messages/sec
Enter fullscreen mode Exit fullscreen mode

Peak traffic:

58 × 10

=
580 messages/sec
Enter fullscreen mode Exit fullscreen mode

Payments

Assume:

50,000 transactions/day

Average project budget:

KES 2,000,000

Transaction volume:

50,000 × 2,000,000

=
KES 100 Billion/day
Enter fullscreen mode Exit fullscreen mode

This requires enterprise-grade payment reliability.

5. High-Level System Design

At a high level we divide the system into independent services.

                    Users
                      |
                Load Balancer
                      |
                 API Gateway
                      |
---------------------------------------------------
|        |         |        |        |            |
Auth   Project   Search   Chat   Payment         AI
Service Service Service Service Service      Service
---------------------------------------------------
                      |
                  Kafka
               Event Bus
                      |
--------------------------------------------------------
|         |          |          |          |            |
Media   Contract  Marketplace Logistics Notifications Analytics
--------------------------------------------------------
                      |
------------------------------------------------
|              |              |                |
PostgreSQL   Redis      Elasticsearch       S3
------------------------------------------------
Enter fullscreen mode Exit fullscreen mode

6. Database Schema

Users

Users
-----
UserID
Name
Email
Phone
Role
CreatedAt
Enter fullscreen mode Exit fullscreen mode

Size estimation:

UserID         8 bytes
Name          50 bytes
Email         50 bytes
Phone         15 bytes
Role           4 bytes
Timestamp      8 bytes

Total

=
135 bytes
Enter fullscreen mode Exit fullscreen mode

500,000 users:

500,000 × 135

=
67.5 MB
Enter fullscreen mode Exit fullscreen mode

Projects

Projects
--------
ProjectID
OwnerID
ContractorID
Budget
Status
CreatedAt
Enter fullscreen mode Exit fullscreen mode

Assume:

200,000 projects

200 bytes/project

200,000 × 200

=
40 MB
Enter fullscreen mode Exit fullscreen mode

Media Metadata

Media

MediaID
ProjectID
URL
Latitude
Longitude
Timestamp
UploaderID
Enter fullscreen mode Exit fullscreen mode

Approximate size:

300 bytes
Enter fullscreen mode Exit fullscreen mode

Daily metadata:

1,200,000 uploads

× 300 bytes

=
360 MB/day
Enter fullscreen mode Exit fullscreen mode

Yearly:

131 GB/year
Enter fullscreen mode Exit fullscreen mode

Notice metadata is tiny compared to actual media storage.

7. Component Design

Authentication Service

Handles:

  • Registration
  • Login
  • JWT generation
  • OTP verification
User
 |
Auth API
 |
PostgreSQL
 |
JWT
Enter fullscreen mode Exit fullscreen mode

Search Service

Handles:

  • Contractors
  • Workers
  • Shops
  • Materials

Instead of querying PostgreSQL directly:

PostgreSQL
     |
Kafka Events
     |
Elasticsearch
     |
Search API
Enter fullscreen mode Exit fullscreen mode

This gives sub-second search.

Contract Service

Responsible for:

  • Contract generation
  • Version control
  • Digital signatures
Contract
    |
PDF Generator
    |
Digital Signature
    |
S3 Storage
Enter fullscreen mode Exit fullscreen mode

AI Quotation Service

Input:

Building Type
Area
Floors
Quality Tier
Location
Enter fullscreen mode Exit fullscreen mode

Output:

Material List
Quantities
Cost Estimate
Enter fullscreen mode Exit fullscreen mode

Architecture:

User Input
      |
Validation
      |
Rules Engine
      |
Pricing Engine
      |
Quotation
Enter fullscreen mode Exit fullscreen mode

8. Reliability and Redundancy

A project worth millions of shillings cannot lose data.

Every component should have replicas.

Primary Database
        |
Replication
        |
Secondary Database
Enter fullscreen mode Exit fullscreen mode

Media Storage:

Photo
  |
S3 Bucket A
  |
Replicate
  |
S3 Bucket B
Enter fullscreen mode Exit fullscreen mode

If one region fails, the other serves traffic.


9. Data Sharding

Suppose after expansion BuildBridge reaches:

20 million users
Enter fullscreen mode Exit fullscreen mode

Single database becomes a bottleneck.


Sharding by ProjectID

Shard = ProjectID % 10
Enter fullscreen mode Exit fullscreen mode

Example:

ProjectID = 145

145 % 10

=
5
Enter fullscreen mode Exit fullscreen mode

Stored in:

Shard 5
Enter fullscreen mode Exit fullscreen mode

Why Not UserID?

A large contractor may manage:

50,000 projects
Enter fullscreen mode Exit fullscreen mode

This creates hotspots.

ProjectID distribution is more uniform.

10. Event-Driven Architecture

Whenever something happens:

Contract Signed
Enter fullscreen mode Exit fullscreen mode

The system publishes:

ContractSigned Event
Enter fullscreen mode Exit fullscreen mode

Kafka distributes this event to:

Notification Service
Analytics Service
Payment Service
Audit Service
Enter fullscreen mode Exit fullscreen mode

Diagram:

Contract Service
        |
        v
      Kafka
        |
--------------------------
|      |       |         |
Notify Audit Analytics Payment
Enter fullscreen mode Exit fullscreen mode

11. Escrow Payment Flow

This is the most critical business workflow.

Owner Deposits Money
          |
          v
     Escrow Wallet
          |
          v
Milestone Approved
          |
          v
Release Funds
          |
          v
Contractor
Enter fullscreen mode Exit fullscreen mode

Example:

Project Budget:

KES 10,000,000
Enter fullscreen mode Exit fullscreen mode

Foundation:

20%
Enter fullscreen mode Exit fullscreen mode

Payment:

10,000,000 × 20%

=
KES 2,000,000
Enter fullscreen mode Exit fullscreen mode

released after approval.

12. Caching and Load Balancing

Frequently accessed contractor profiles are cached.

User
 |
Redis Cache
 |
Hit?
 |
Yes -> Return
 |
No
 |
Database
Enter fullscreen mode Exit fullscreen mode

Assume:

80% of searches target 20% of contractors.

Caching these records dramatically reduces database load.

13. Final Architecture


                 Users
                    |
             Load Balancer
                    |
              API Gateway
                    |
-----------------------------------------------------
|       |       |       |       |       |           |
Auth  Search Project Chat Payment AI Marketplace
-----------------------------------------------------
                    |
                 Kafka
                    |
-----------------------------------------------------
|        |         |        |        |              |
Media Contracts Logistics Notifications Analytics
-----------------------------------------------------
                    |
-----------------------------------------------------
|         |            |             |             |
Postgres Redis Elasticsearch     Object Storage
-----------------------------------------------------
Enter fullscreen mode Exit fullscreen mode

Conclusion

BuildBridge is effectively a combination of several large-scale systems:

  • Uber for geolocation and discovery
  • Amazon for the marketplace
  • Stripe for escrow payments
  • DocuSign for digital contracts
  • Slack for communication
  • Jira for project execution tracking
  • AI-powered estimation systems for construction budgeting

The most important architectural decision is not the AI engine or marketplace. It is building a trustworthy ecosystem through contractor verification, digital contracts, milestone tracking, live geotagged evidence, and escrow payments. These features create the foundation upon which the entire BuildBridge platform is built.

Top comments (0)