BidRadar Development Progress

████░░░░░░░░░░░░░░░░ 1/60

Current phase: Product strategy and development foundations
Current milestone: Define what BidRadar will become before generating application code
Primary tool: Google AI Studio
Permanent source of truth: GitHub
Production architecture: React, FastAPI, PostgreSQL, pgvector, Redis, object storage, and Gemini

Introduction

Government tendering creates a significant business opportunity for IT consulting companies, cloud service providers, software development agencies, cybersecurity specialists, managed service providers, and digital transformation consultancies.

Public-sector organizations purchase enormous volumes of technology services every year.

They issue contracts for:

• Cloud migration
• Microsoft 365 implementation
• Cybersecurity services
• Managed infrastructure
• Software development
• Data platforms
• DevOps engineering
• Application modernization
• IT support
• Digital transformation
• Artificial intelligence
• Network services
• Enterprise architecture
• Technology consulting

The opportunity is substantial.

The process, however, is difficult.

Tender opportunities are spread across numerous procurement portals. Each notice may contain multiple documents, hundreds of pages, complex eligibility rules, technical specifications, legal conditions, evaluation criteria, submission instructions, and strict deadlines.

For smaller IT service providers, the tendering process can become overwhelming.

A company may need to:

1. Find relevant opportunities.
2. Determine whether the opportunity fits its expertise.
3. Download and review all tender documents.
4. Identify mandatory requirements.
5. Decide whether to bid.
6. Assemble supporting company evidence.
7. Prepare a compliant proposal.
8. Coordinate contributors and reviewers.
9. Validate the final submission.
10. Upload the proposal before the deadline.

Much of this work is repetitive, document-heavy, and time-consuming.

This is the problem BidRadar is designed to solve.

BidRadar will be an AI Tender Intelligence and Proposal Automation SaaS platform for IT service providers.

It will help technology companies discover suitable public-sector opportunities, understand tender requirements, assess organizational fit, and create evidence-backed proposal drafts using their own company knowledge.

In the previous development series, we designed BidRadar using Claude Code as the primary coding assistant.

That series established a complete architectural blueprint covering forty major development stages.

We will now build a second implementation series using Google AI Studio and Gemini.

The objective is not merely to repeat the same articles with a different tool name.

The objective is to create a more execution-focused series in which Google AI Studio helps generate the initial full-stack application, Gemini powers the intelligent tender-analysis capabilities, GitHub preserves the source code, and a local development environment provides the engineering control required for databases, testing, migrations, Docker, and production deployment.

By the end of the series, we aim to have a functional, extensible, and production-ready BidRadar SaaS platform.

What We Are Building

BidRadar is an AI-powered tender discovery, analysis, and proposal-generation platform designed specifically for technology consultancies and IT service providers.

The initial positioning is:

BidRadar — AI Tender Intelligence for IT Service Providers

The platform will help users move through the complete procurement lifecycle:

Discover
    ↓
Understand
    ↓
Qualify
    ↓
Plan
    ↓
Draft
    ↓
Review
    ↓
Approve
    ↓
Submit
    ↓
Learn

Rather than functioning as a simple tender-search website, BidRadar will become an integrated proposal workspace.

It will connect public procurement data, organizational knowledge, AI analysis, proposal generation, workflow automation, and management reporting.

The Core Product Vision

The long-term vision for BidRadar is straightforward:

Help IT service providers spend less time searching, reading, coordinating, and formatting—and more time pursuing the government opportunities they are genuinely positioned to win.

The product should reduce four major forms of waste.

Discovery Waste

Companies often spend hours browsing procurement portals and reading irrelevant notices.

BidRadar should automatically collect, normalize, filter, and rank opportunities.

Analysis Waste

Tender documents may contain hundreds of pages.

BidRadar should summarize the opportunity, identify requirements, extract deadlines, detect evaluation criteria, and highlight risks.

Proposal Preparation Waste

Proposal teams repeatedly search for the same case studies, certifications, consultant profiles, methodologies, and project references.

BidRadar should retrieve this evidence automatically from the organization’s knowledge base.

Coordination Waste

Proposal work is often tracked through spreadsheets, email chains, meetings, and manually maintained checklists.

BidRadar should coordinate tasks, assignments, reviews, approvals, deadlines, and submission readiness in one workspace.

The Target Customer

BidRadar is not initially intended for every kind of supplier.

The first version will focus on IT service providers.

Examples include:

• Cloud consulting companies
• Microsoft partners
• Managed service providers
• Cybersecurity consultancies
• Software development agencies
• Data and analytics consultancies
• DevOps and platform engineering companies
• IT infrastructure providers
• Digital transformation consultancies
• AI consulting companies
• Enterprise architecture firms
• Network and communications providers

This focus is important.

A narrowly defined target market allows us to build better:

• Opportunity filters
• Requirement categories
• Scoring models
• Knowledge templates
• Proposal structures
• AI prompts
• Dashboard terminology
• Onboarding workflows

BidRadar may eventually support other professional-service sectors, but IT services will remain the initial specialization.

Primary User Personas

The product must serve several different roles inside an IT consulting organization.

Business Development Manager

The Business Development Manager wants to:

• Find relevant opportunities
• Understand pipeline value
• Prioritize high-potential contracts
• Assign opportunities to proposal teams
• Track opportunity status
• Review Bid/No-Bid recommendations
• Monitor win rates

Proposal Manager

The Proposal Manager wants to:

• Review requirements
• Create a proposal plan
• Assign sections
• Track deadlines
• Monitor requirement coverage
• Request reviews
• Approve final content
• Generate submission packages

Technical Consultant

The Technical Consultant wants to:

• Understand technical requirements
• Review assigned sections
• Add solution content
• Upload supporting evidence
• Comment on AI-generated drafts
• Approve technical claims

Subject Matter Expert

The Subject Matter Expert wants to:

• Review specific tender requirements
• Validate assumptions
• Correct AI interpretations
• Contribute technical or legal expertise
• Confirm supporting evidence

Executive Sponsor

The Executive Sponsor wants to:

• Understand the opportunity quickly
• Review strategic fit
• See risk and value
• Approve the Bid/No-Bid decision
• Authorize final submission

Knowledge Administrator

The Knowledge Administrator wants to:

• Upload company documents
• Manage case studies
• Maintain consultant profiles
• Track certifications
• Archive outdated information
• Review search and retrieval quality

System Administrator

The System Administrator wants to:

• Manage users
• Configure organizations
• Control permissions
• Manage integrations
• Review security events
• Monitor system health

The Core Customer Problem

The primary problem can be summarized as follows:

IT service providers often possess the expertise required to win government contracts, but they lack an efficient system for discovering suitable opportunities, understanding complex requirements, finding internal evidence, coordinating proposal work, and producing compliant responses.

BidRadar addresses this problem by combining:

• Procurement data
• Document intelligence
• Organizational knowledge
• Generative AI
• Workflow automation
• Collaboration
• Analytics
• Submission preparation

The value does not come from a single AI feature.

The value comes from connecting the full process.

The BidRadar Value Proposition

BidRadar should deliver measurable value in five areas.

Faster Opportunity Discovery

Users should be able to find relevant IT tenders without manually checking numerous portals.

Faster Tender Understanding

Users should be able to understand a procurement opportunity within minutes rather than spending hours reading every document.

Better Bid Selection

BidRadar should help organizations avoid low-probability opportunities and focus resources on strategically attractive contracts.

Faster Proposal Development

AI-assisted drafting and evidence retrieval should reduce the time required to create an initial proposal.

Lower Submission Risk

Compliance validation, traceability, workflow monitoring, and submission checks should reduce the risk of missing mandatory requirements.

What Google AI Studio Will Do

Google AI Studio will play two distinct roles in this project.

Role 1 — Development Environment

We will use Google AI Studio to help generate and evolve the BidRadar application.

It will assist with:

• Generating the initial full-stack application
• Creating React pages and components
• Producing backend code
• Updating project files
• Testing user-interface concepts
• Prototyping workflows
• Creating Gemini integrations
• Refining prompts
• Generating structured schemas
• Explaining generated code

Role 2 — AI Platform Inside BidRadar

The Gemini API will power product features such as:

• Tender summarization
• Requirement extraction
• Document analysis
• Opportunity scoring
• Proposal outline generation
• Proposal draft generation
• Compliance review
• Rewrite suggestions
• Function calling
• RAG
• Agent workflows

This distinction matters.

Google AI Studio helps us build BidRadar.

Gemini becomes one of the intelligence layers inside BidRadar.

What Google AI Studio Will Not Replace

Google AI Studio will not become the permanent home of the complete engineering workflow.

The project still requires conventional development infrastructure.

Google AI Studio will not replace:

• GitHub
• PostgreSQL administration
• Alembic migrations
• Local automated testing
• Docker
• CI/CD
• Production monitoring
• Infrastructure configuration
• Backup management
• Security audits
• Incident response

The correct development model is therefore hybrid.

Google AI Studio
        │
        ▼
Generate and modify application code
        │
        ▼
GitHub
        │
        ▼
Review, version, test, and protect code
        │
        ▼
Local development environment
        │
        ▼
Run databases, migrations, workers, and tests
        │
        ▼
Cloud deployment

Why We Are Not Discarding the Claude Code Architecture

The previous Claude Code series produced a strong system blueprint.

That work remains valuable.

We will reuse:

• Product requirements
• Core domain concepts
• Database entities
• API boundaries
• Service-layer patterns
• Repository patterns
• Multi-tenant architecture
• Tender source framework
• Document-processing pipeline
• Knowledge-base architecture
• RAG design
• Proposal workflows
• Collaboration concepts
• Security controls
• Observability requirements

The underlying architecture is not tied to Claude Code.

Coding assistants generate implementation.

Architecture defines the system.

We are changing the development tool, not abandoning the product design.

What Will Be Different in This Series

This series will place more emphasis on producing and inspecting a running application.

Every article should deliver at least one of the following:

• A visible interface
• A working API
• A database migration
• An automated test
• A usable workflow
• A measurable AI capability
• A deployment improvement

We will follow five rules.

Rule 1 — Build Incrementally

Each article implements one bounded capability.

Rule 2 — Preserve Existing Behavior

Google AI Studio prompts must instruct the model not to break completed features.

Rule 3 — Review Generated Code

AI-generated code will be inspected for architecture, security, maintainability, and correctness.

Rule 4 — Test Every Milestone

No part is complete until its validation checklist passes.

Rule 5 — Commit Every Milestone

Every article ends with a recommended Git commit.

The Initial MVP

The complete BidRadar vision is large.

We therefore need a clearly bounded Minimum Viable Product.

The first MVP should allow a user to:

1. Create an account.
2. Create an organization.
3. Upload or import a tender opportunity.
4. Upload tender documents.
5. Extract text from the documents.
6. Generate an AI tender summary.
7. Extract structured requirements.
8. Review a Bid/No-Bid score.
9. Upload company knowledge.
10. Generate a proposal outline.
11. Generate an evidence-backed proposal draft.
12. Review requirement coverage.
13. Export the proposal.

This is already a significant product.

The MVP will not initially include every advanced feature described in the sixty-part roadmap.

MVP Feature Boundaries

Included in the MVP

• User authentication
• Organization accounts
• Opportunity management
• Tender document upload
• PDF and Office extraction
• Gemini requirement extraction
• Executive tender summaries
• Basic opportunity scoring
• Organization knowledge uploads
• Semantic search
• RAG
• Proposal outline generation
• Proposal draft generation
• Requirement traceability
• Basic collaboration
• DOCX export

Deferred Until Later

• Direct integration with many procurement portals
• Fully autonomous proposal agents
• Real-time collaborative text editing
• Advanced CRM integration
• Digital signatures
• Automated portal submission
• Predictive win probability
• Multi-region infrastructure
• Machine-learning model training
• Fine-tuned organization-specific language models
• Mobile applications

Deferring these features prevents the MVP from becoming impossible to complete.

Product Scope by Capability

The complete BidRadar platform can be divided into ten capability domains.

1. Identity and Organization Management

This domain includes:

• User registration
• Login
• Organization creation
• Memberships
• Roles
• Permissions
• Tenant isolation
• Audit events

2. Tender Opportunity Management

This domain includes:

• Tender source connectors
• Opportunity imports
• Buyers
• Procurement classifications
• Search
• Filters
• Saved searches
• Opportunity lifecycle

3. Tender Document Intelligence

This domain includes:

• File upload
• File validation
• Text extraction
• OCR
• Gemini document understanding
• Requirement extraction
• Summarization
• Evidence linking

4. Opportunity Qualification

This domain includes:

• Strategic fit
• Technical fit
• Compliance fit
• Commercial attractiveness
• Risk
• Deadline pressure
• Bid/No-Bid recommendations

5. Organization Knowledge

This domain includes:

• Case studies
• Certifications
• Consultant CVs
• Methodologies
• Project references
• Previous proposals
• Service descriptions
• Semantic search
• Versioning

6. Proposal Generation

This domain includes:

• Proposal templates
• Outline generation
• Requirement mapping
• Evidence retrieval
• Section drafting
• Citations
• Placeholder detection
• Draft versions

7. Proposal Quality and Compliance

This domain includes:

• Requirement traceability
• Compliance validation
• Coverage analysis
• Quality scoring
• Rewrite suggestions
• Evidence checks
• Final readiness

8. Collaboration and Workflow

This domain includes:

• Section assignments
• Tasks
• Reviews
• Comments
• Approvals
• Notifications
• Reminders
• Escalation

9. Export and Submission

This domain includes:

• Microsoft Word export
• PDF export
• Appendices
• Submission packages
• Manifests
• Checksums
• Portal connectors

10. Analytics and Operations

This domain includes:

• Pipeline reporting
• Win/loss analytics
• Team productivity
• AI usage
• Cost tracking
• Observability
• Security monitoring
• Production operations

Functional Requirements

The initial functional requirements are grouped below.

Opportunity Requirements

The system must allow users to:

• Create opportunities manually.
• Import opportunities from configured sources.
• Search and filter opportunities.
• Open an opportunity workspace.
• Track publication and closing dates.
• Store buyer information.
• Store external procurement references.
• Attach multiple tender documents.
• Record opportunity status.

Document Requirements

The system must:

• Accept supported document formats.
• Validate uploaded files.
• Store original files safely.
• Extract text.
• Detect unsupported or corrupt files.
• Preserve document metadata.
• Track processing status.
• Associate extracted evidence with source locations.

AI Analysis Requirements

The system must:

• Generate tender summaries.
• Extract structured requirements.
• Categorize requirements.
• identify mandatory requirements.
• Identify deadlines.
• Extract evaluation criteria.
• Link findings to evidence.
• Store model and prompt metadata.
• Support human review.

Knowledge Requirements

The system must allow organizations to:

• Upload knowledge documents.
• Classify knowledge.
• Extract text.
• Create chunks.
• Generate embeddings.
• Search semantically.
• Filter by metadata.
• Version knowledge.
• Archive obsolete documents.

Proposal Requirements

The system must:

• Generate a proposal outline.
• Map requirements to sections.
• Retrieve supporting evidence.
• Generate proposal drafts.
• Produce citations.
• Flag missing evidence.
• Allow human editing.
• Maintain version history.
• Track review status.

Workflow Requirements

The system must:

• Create tasks.
• Assign owners.
• Set due dates.
• Track dependencies.
• Request reviews.
• Record approvals.
• Generate notifications.
• Record activity history.

Export Requirements

The system must:

• Generate DOCX files.
• Apply a configurable proposal template.
• Create headings and numbering.
• Insert tables and appendices.
• Generate a table of contents.
• Record export history.

Non-Functional Requirements

BidRadar must not only work.

It must work safely, predictably, and at an acceptable level of quality.

Security

The platform must support:

• Secure password storage
• Encrypted communication
• Tenant isolation
• Role-based authorization
• Secure file handling
• Secret management
• Audit logging
• Rate limiting
• Input validation

Reliability

The platform should:

• Recover from temporary external failures.
• Prevent partial database updates.
• Retry safe background operations.
• Preserve uploaded documents.
• Record failed processing jobs.
• Avoid silent failures.

Performance

Initial performance targets include:

• Common dashboard responses below two seconds
• Opportunity search below two seconds
• File upload progress feedback
• Background processing for long AI operations
• Responsive user-interface interactions
• Paginated large result sets

Maintainability

The codebase should:

• Use clear module boundaries.
• Separate business logic from HTTP handlers.
• Separate retrieval from generation.
• Use type hints.
• Include automated tests.
• Avoid hardcoded configuration.
• Use migrations for schema changes.
• Preserve documentation.

Explainability

AI features should provide:

• Evidence references
• Confidence scores
• Model metadata
• Prompt versions
• Human-review status
• Clear explanations for recommendations

Cost Control

The platform should:

• Track AI requests.
• Record token usage.
• Support multiple Gemini models.
• Cache reusable results.
• Use cheaper models where appropriate.
• Enforce organization-level budgets.
• Prevent unnecessary regeneration.

Proposed Technology Stack

The planned technology stack is designed to remain practical for a small development team while supporting future enterprise growth.

Frontend

• React
• TypeScript
• Vite
• React Router
• TanStack Query
• Component library or custom design system
• Rich-text editor for proposal content

Backend

• Python
• FastAPI
• Pydantic
• SQLAlchemy 2.x
• Alembic
• Async database access
• Background worker framework

Database

• PostgreSQL
• pgvector
• Full-text search
• JSONB for selected metadata
• UUID primary keys

Caching and Jobs

• Redis
• Background task queues
• Job retries
• Scheduled tasks

AI

• Gemini API
• Structured outputs
• Function calling
• Multimodal document understanding
• Embeddings
• RAG
• Agent workflows

File Storage

Development:

• Local or MinIO-compatible storage

Production:

• Cloud object storage

Testing

• Pytest
• API integration tests
• Frontend component tests
• End-to-end tests
• Prompt regression tests
• Retrieval-quality tests

Deployment

• Docker
• GitHub Actions
• Managed PostgreSQL
• Cloud Run or comparable container platform
• Secret Manager
• Centralized observability

High-Level System Architecture

The platform will use a modular architecture.

                         ┌───────────────────────┐
                         │      React Web App    │
                         │ Dashboard, Proposals, │
                         │ Knowledge, Workflows  │
                         └───────────┬───────────┘
                                     │ HTTPS
                                     ▼
                         ┌───────────────────────┐
                         │      FastAPI API      │
                         │ Auth, Domain Services,│
                         │ Validation, REST API  │
                         └──────┬───────┬────────┘
                                │       │
                    ┌───────────┘       └─────────────┐
                    ▼                                 ▼
        ┌──────────────────────┐          ┌──────────────────────┐
        │ PostgreSQL + pgvector│          │ Background Workers   │
        │ Users, Tenders,      │          │ Imports, Extraction, │
        │ Proposals, Knowledge │          │ AI, Exports, Alerts  │
        └──────────────────────┘          └───────────┬──────────┘
                                                     │
                        ┌────────────────────────────┼────────────────────┐
                        ▼                            ▼                    ▼
             ┌──────────────────┐        ┌──────────────────┐  ┌─────────────────┐
             │   Gemini API     │        │  Object Storage  │  │ External Portals│
             │ Analysis, RAG,   │        │ Tender and       │  │ Procurement and │
             │ Generation       │        │ Knowledge Files  │  │ Enterprise Apps │
             └──────────────────┘        └──────────────────┘  └─────────────────┘

Multi-Tenant SaaS Architecture

Every organization must operate inside an isolated tenant.

An organization should only see:

• Its own users
• Its own tender opportunities
• Its own documents
• Its own knowledge base
• Its own proposals
• Its own AI usage
• Its own exports
• Its own workflow events

Tenant isolation should be applied throughout:

• Database queries
• Object storage
• Vector search
• Caching
• Background jobs
• Audit records
• API authorization

This is one of the most important architectural rules in the entire platform.

Core Domain Entities

The first database design will likely include the following entities.

Organization
    │
    ├── Membership
    │       └── User
    │
    ├── TenderSource
    │
    ├── Opportunity
    │       ├── Buyer
    │       ├── TenderDocument
    │       ├── Requirement
    │       ├── OpportunityAnalysis
    │       ├── OpportunityScore
    │       └── Proposal
    │               ├── ProposalSection
    │               ├── ProposalVersion
    │               ├── Comment
    │               ├── Review
    │               ├── Task
    │               └── Export
    │
    └── KnowledgeDocument
            ├── KnowledgeVersion
            └── KnowledgeChunk

Later articles will refine these relationships in detail.

AI Architecture

BidRadar will not send every task to the same Gemini model using the same prompt.

The AI layer should include:

• Model routing
• Prompt templates
• Structured schemas
• Retrieval services
• Citation handling
• Confidence scoring
• Usage tracking
• Evaluation
• Safety controls

Example routing:

Fast classification
        ↓
Lower-cost Gemini model
Complex tender analysis
        ↓
Higher-capability Gemini model
Embeddings
        ↓
Embedding model
RAG proposal generation
        ↓
Gemini with retrieved evidence
Agent workflow
        ↓
Gemini with controlled function calling

This helps control both quality and cost.

Evidence-First AI Principle

BidRadar must follow an evidence-first design.

AI-generated claims should be based on:

• Tender documents
• Organization knowledge
• User-provided information
• Verified structured data

The system should not invent:

• Certifications
• Customer references
• Consultant experience
• Project outcomes
• Contract values
• Security clearances
• Employee qualifications

When evidence is missing, the correct output is:

Supporting organizational evidence is not currently available.

This is preferable to generating a persuasive but unsupported statement.

Human-in-the-Loop Principle

AI should accelerate work, not secretly make irreversible decisions.

Human approval should remain mandatory for:

• Bid/No-Bid decisions
• Requirement validation
• Proposal section approval
• Pricing
• Legal exceptions
• Final proposal approval
• Submission authorization

AI recommendations should remain reviewable and explainable.

Development Environments

We will work across four environments.

Google AI Studio

Used for:

• Initial application generation
• Visual prototyping
• Gemini prompt development
• Structured-output experimentation
• Application modifications
• Rapid feature generation

GitHub

Used for:

• Permanent source control
• Commit history
• Branches
• Pull requests
• Issues
• Releases
• CI/CD

Local Development

Used for:

• PostgreSQL
• Alembic
• Tests
• Docker
• Debugging
• File processing
• Worker processes
• Code review

Production Cloud

Used for:

• Application hosting
• Managed database
• Object storage
• Secrets
• Logging
• Monitoring
• Backups

Development Workflow

Every article will follow a controlled implementation cycle.

1. Define the bounded feature
        ↓
2. Prepare the Google AI Studio prompt
        ↓
3. Ask Google AI Studio to inspect existing code
        ↓
4. Review the implementation plan
        ↓
5. Generate or modify the code
        ↓
6. Export or synchronize changes
        ↓
7. Review the diff
        ↓
8. Run automated tests
        ↓
9. Perform manual validation
        ↓
10. Commit the milestone

This workflow prevents uncontrolled code generation.

Prompting Rules for Google AI Studio

Every implementation prompt should contain instructions similar to the following:

Before making changes:
1. Inspect the existing project.
2. Explain the relevant architecture.
3. Identify the files that must change.
4. List assumptions.
5. Describe the implementation plan.
During implementation:
1. Preserve completed functionality.
2. Follow the established project structure.
3. Avoid duplicating existing components.
4. Use strict TypeScript and Python typing.
5. Validate all external input.
6. Add error handling and structured logging.
7. Respect organization-level tenant isolation.
8. Add automated tests.
After implementation:
1. Summarize every change.
2. List files created or modified.
3. Provide commands required to run the feature.
4. Explain how to validate the result.
5. Report known limitations.

This pattern will be refined throughout the series.

Development Roadmap

The complete roadmap contains sixty parts.

Phase 1 — Strategy and Foundations

Part 1 — Project Vision, Product Scope, and Development Roadmap

Define the product, users, architecture, MVP, development workflow, and full implementation plan.

Part 2 — Understanding Google AI Studio as a Full-Stack Development Environment

Explore Build mode, prompts, previews, project files, packages, secrets, deployment, and limitations.

Part 3 — Defining the Product Requirements Document

Create the complete PRD, personas, workflows, acceptance criteria, and non-functional requirements.

Part 4 — Designing the High-Level System Architecture

Define frontend, backend, storage, AI, jobs, integrations, and deployment architecture.

Part 5 — Designing the Database Schema

Model organizations, users, tenders, documents, knowledge, proposals, workflows, and audit records.

Part 6 — Designing the REST API

Define resource contracts, schemas, errors, filters, pagination, and versioning.

Part 7 — Establishing the Design System

Create visual language, layouts, components, states, accessibility, and responsive behavior.

Phase 2 — Initial Application Generation

Part 8 — Writing the Master Build Prompt

Create the master Google AI Studio application-generation prompt.

Part 9 — Generating the Initial Full-Stack Application

Generate the first visible BidRadar application with core screens and mock data.

Part 10 — Reviewing the Generated Project Structure

Inspect architecture, dependencies, technical debt, routing, components, and data flow.

Part 11 — Correcting the Generated Architecture

Refactor unsafe, duplicated, hardcoded, or poorly organized generated code.

Part 12 — Exporting to GitHub

Establish repository structure, branch protection, commits, issues, and releases.

Part 13 — Running BidRadar Locally

Install the frontend and backend environments and solve common setup problems.

Part 14 — Creating the Docker Development Environment

Add PostgreSQL, Redis, object storage, backend, frontend, and workers.

Phase 3 — Backend and Data

Part 15 — Building the FastAPI Backend Foundation

Part 16 — Connecting FastAPI to PostgreSQL

Part 17 — Managing Database Migrations with Alembic

Part 18 — Building the Core SQLAlchemy Models

Part 19 — Building the Repository Layer

Part 20 — Building the Service Layer

Phase 4 — Authentication and Multi-Tenancy

Part 21 — Building User Registration and Login

Part 22 — Building Organization Accounts and User Administration

Part 23 — Implementing Role-Based Access Control

Part 24 — Enforcing Multi-Tenant Data Isolation

Phase 5 — Tender Discovery and Import

Part 25 — Building the Tender Source Connector Framework

Part 26 — Building the Tender Opportunity Data Model

Part 27 — Building the Tender Import Pipeline

Part 28 — Building Search, Filters, and Saved Searches

Part 29 — Building the Opportunity Dashboard and Workspace

Phase 6 — Tender Documents and AI Analysis

Part 30 — Building Secure Tender Document Upload and Storage

Part 31 — Building PDF and Office Text Extraction

Part 32 — Analyzing Documents with Gemini Multimodal Understanding

Part 33 — Building Structured Requirement Extraction

Part 34 — Building Tender Summaries and Executive Briefings

Part 35 — Building Opportunity Scoring and Bid/No-Bid Recommendations

Phase 7 — Organization Knowledge

Part 36 — Building the Organization Knowledge Base

Part 37 — Building the Knowledge Ingestion Pipeline

Part 38 — Building Semantic Chunking and Metadata Enrichment

Part 39 — Generating Embeddings and Storing Vectors with pgvector

Part 40 — Building Hybrid Semantic and Keyword Search

Part 41 — Evaluating Retrieval Quality

Phase 8 — RAG and Proposal Generation

Part 42 — Building the RAG Pipeline with Gemini

Part 43 — Building Proposal Outline Generation

Part 44 — Building Evidence-Backed Proposal Draft Generation

Part 45 — Building Proposal Compliance Validation

Part 46 — Building Proposal Review, Quality Scoring, and Rewrite Suggestions

Phase 9 — Collaboration and Agentic Workflows

Part 47 — Building Collaborative Editing and Version Control

Part 48 — Building Workflow Automation and Task Management

Part 49 — Connecting Gemini to BidRadar Tools with Function Calling

Part 50 — Building Agentic Proposal Planning and Human Approval Workflows

Phase 10 — Export, Integrations, and Production

Part 51 — Building Microsoft Word Export

Part 52 — Building PDF Export and Submission Packages

Part 53 — Building Notification Connectors

Part 54 — Building Microsoft 365, SharePoint, and CRM Integrations

Part 55 — Building Proposal Analytics and Executive Reporting

Part 56 — Building Gemini Usage Tracking and Cost Controls

Part 57 — Building Automated Tests and AI Evaluation

Part 58 — Securing BidRadar for Enterprise Use

Part 59 — Deploying BidRadar with Google Cloud

Part 60 — Production Hardening, Observability, and Release Readiness

Definition of Done

A development article is not complete merely because Google AI Studio generated code.

Each part must satisfy its Definition of Done.

A feature is complete when:

• The code follows the architecture.
• Automated tests pass.
• Manual validation succeeds.
• Tenant isolation is preserved.
• Errors are handled.
• Logging exists.
• Security risks are reviewed.
• Documentation is updated.
• The change is committed.
• The next part can build safely on it.

Risks and Constraints

AI-Generated Code Quality

Generated code may include:

• Duplicated logic
• Weak typing
• Incomplete error handling
• Insecure defaults
• Hardcoded mock data
• Poor separation of concerns

Mitigation:

• Review every diff.
• Test every feature.
• Refactor before continuing.

Scope Expansion

A sixty-part platform can easily grow beyond control.

Mitigation:

• Enforce article boundaries.
• Defer unrelated features.
• Maintain an explicit backlog.

AI Cost Growth

Document analysis, embeddings, RAG, and proposal generation can become expensive at scale.

Mitigation:

• Track usage from the beginning.
• Cache results.
• Batch requests.
• Route tasks to appropriate models.
• Add budgets and limits.

Tender Data Complexity

Procurement sources vary significantly.

Mitigation:

• Normalize through adapters.
• Preserve raw source data.
• Isolate source-specific logic.

Data Privacy

Tender documents and organizational knowledge may contain confidential information.

Mitigation:

• Encrypt data.
• Isolate tenants.
• restrict access.
• Audit actions.
• define retention policies.

Hallucinations

AI may produce unsupported claims.

Mitigation:

• Require evidence.
• Use structured outputs.
• Validate responses.
• Preserve human review.
• Reject unsupported content.

Success Metrics

We should measure whether BidRadar actually improves the tendering process.

Initial success metrics include:

Discovery

• Relevant opportunities found
• Search time reduced
• Saved searches created
• Opportunity engagement rate

Analysis

• Average document-analysis time
• Requirements extracted
• Human correction rate
• Evidence-link accuracy

Proposal Production

• Time to first draft
• Proposal sections generated
• AI suggestions accepted
• Requirement coverage

Workflow

• Tasks completed on time
• Review turnaround
• Overdue tasks
• Approval duration

Business Outcomes

• Bid rate
• Win rate
• Proposal cycle time
• Pipeline value
• Hours saved

These metrics will later power the analytics platform.

First Google AI Studio Project Prompt

We will not generate the entire application in this article.

However, we can begin by creating the project context that Google AI Studio will use in later parts.

Paste the following prompt into a new Google AI Studio project.

You are helping me design and build BidRadar, an AI Tender Intelligence and Proposal Automation SaaS platform for IT service providers.
BidRadar helps cloud consultancies, managed service providers, cybersecurity companies, software development agencies, DevOps consultancies, data consultancies, and other IT service providers discover government tender opportunities, understand procurement requirements, evaluate Bid/No-Bid fit, retrieve organizational evidence, and generate compliant proposal drafts.
The long-term technology stack is:
Frontend:
- React
- TypeScript
- Vite
- React Router
- TanStack Query
Backend:
- Python
- FastAPI
- Pydantic
- SQLAlchemy 2.x
- Alembic
Data:
- PostgreSQL
- pgvector
- Redis
- Object storage
AI:
- Gemini API
- Structured outputs
- Multimodal document analysis
- Embeddings
- Retrieval-Augmented Generation
- Function calling
- Agent workflows
Infrastructure:
- Docker
- GitHub Actions
- Cloud deployment
- Centralized logging
- Metrics and tracing
Core product domains:
1. Authentication and organization accounts
2. Role-based access control
3. Tender source integrations
4. Tender opportunity management
5. Tender document processing
6. AI requirement extraction
7. Executive tender summaries
8. Opportunity scoring and Bid/No-Bid recommendations
9. Organization knowledge base
10. Semantic and hybrid search
11. RAG-based proposal generation
12. Proposal compliance validation
13. Collaboration and workflow automation
14. DOCX and PDF export
15. Enterprise integrations
16. Analytics and cost controls
17. Production operations
The platform is multi-tenant.
Every business record must belong to an organization, and users must never access another organization's tenders, documents, knowledge, proposals, embeddings, workflows, exports, or analytics.
AI-generated content must be evidence-based.
The system must never invent customer references, certifications, project experience, financial figures, consultant qualifications, or technical capabilities.
Human approval is mandatory for Bid/No-Bid decisions, final proposal approval, pricing, legal exceptions, and submission authorization.
For now, do not generate application code.
Your task is to:
1. Restate the BidRadar product vision.
2. Identify the primary user personas.
3. Define the initial MVP.
4. Separate MVP features from future capabilities.
5. Identify the main technical risks.
6. Identify the main AI risks.
7. Recommend the first visible application screens.
8. Recommend the first backend domain modules.
9. List assumptions that must be confirmed.
10. Produce a concise project brief that can be reused in future prompts.
Do not invent product requirements that conflict with the description above.
Keep the architecture modular, secure, testable, and suitable for gradual production hardening.

Expected Output from Google AI Studio

The initial output should include:

• Product summary
• User personas
• MVP boundaries
• Future roadmap
• Initial screen inventory
• Initial backend modules
• Technical risks
• AI risks
• Assumptions
• Reusable project brief

Do not proceed to application generation yet.

The purpose of this prompt is to test whether Google AI Studio correctly understands the product before we ask it to create code.

Reviewing the Output

Check whether Google AI Studio correctly identifies:

• IT service providers as the target customer
• Government tenders as the opportunity domain
• Evidence-backed AI as a core requirement
• Multi-tenancy as mandatory
• Human approval as mandatory
• The MVP as narrower than the final platform
• GitHub as the source of truth
• PostgreSQL and FastAPI as long-term architecture
• Gemini as the AI layer
• RAG as a future central capability

Reject or correct the output if it:

• Treats BidRadar as a generic CRM
• Generates a procurement portal for government buyers
• Removes the organization knowledge base
• Proposes a purely frontend application
• Stores sensitive credentials in source code
• Makes proposal submission autonomous
• Assumes AI output is always correct
• Ignores tenant isolation

Validation Checklist

Before continuing to Part 2, verify that:

• The BidRadar vision is documented.
• The target customer is clearly defined.
• User personas are identified.
• The MVP is bounded.
• Deferred capabilities are listed.
• The high-level architecture is documented.
• The role of Google AI Studio is understood.
• The role of GitHub is understood.
• The role of the local development environment is understood.
• Multi-tenancy is treated as mandatory.
• Evidence-backed AI is treated as mandatory.
• Human approval checkpoints are documented.
• The sixty-part roadmap is established.
• The initial Google AI Studio context prompt has been tested.
• Incorrect assumptions have been corrected.

Recommended Project Documentation

Create the following project document:

docs/
└── project-vision.md

Suggested contents:

• Product vision
• Target users
• Customer problem
• Value proposition
• MVP
• Deferred scope
• Architecture principles
• AI principles
• Security principles
• Development workflow
• Roadmap

This document will later be committed to GitHub and referenced in future prompts.

Recommended Git Commit

Once the repository is created, use:

docs(product): define BidRadar vision, scope, architecture principles, and development roadmap

What We Established

In this first article, we defined:

• The BidRadar product vision
• The target customer
• The primary user personas
• The customer problem
• The value proposition
• The initial MVP
• The deferred scope
• The technology stack
• The high-level architecture
• The multi-tenant model
• The evidence-first AI principle
• The human-in-the-loop principle
• The hybrid Google AI Studio, GitHub, and local-development workflow
• The complete sixty-part development roadmap
• The first reusable Google AI Studio project prompt

No production code has been written yet.

That is intentional.

The quality of the application will depend heavily on whether its product boundaries and architectural principles are clear before code generation begins.

Next Article

Part 2 — Understanding Google AI Studio as a Full-Stack Development Environment

In the next article, we will explore Google AI Studio itself before generating the BidRadar application.

We will examine:

• How to create a project
• How Build mode works
• How prompts influence application generation
• How the file workspace is organized
• How previews work
• How to inspect generated code
• How packages are added
• How secrets should be handled
• How projects are exported
• How deployment works
• Which tasks should remain outside Google AI Studio
• How to avoid becoming dependent on generated code we do not understand

By the end of Part 2, we will have a controlled and repeatable Google AI Studio development workflow ready for the BidRadar master build prompt.