BidRadar Development Progress

████░░░░░░░░░░░░░░░░ 2/60

Current phase: Strategy and development foundations
Current milestone: Establish a controlled Google AI Studio engineering workflow
Previous article: Project Vision, Product Scope, and Development Roadmap
Next article: Defining the Product Requirements Document
Primary tool: Google AI Studio
Permanent source of truth: GitHub

Introduction

In Part 1, we defined the vision for BidRadar.

We established that BidRadar will become an AI Tender Intelligence and Proposal Automation SaaS platform for IT service providers.

The platform will eventually support:

• Government tender discovery
• Procurement document analysis
• Structured requirement extraction
• Bid/No-Bid recommendations
• Organization knowledge management
• Semantic search
• Retrieval-Augmented Generation
• Evidence-backed proposal drafting
• Compliance validation
• Collaborative proposal workflows
• Microsoft Word and PDF export
• Enterprise integrations
• Analytics
• Production operations

We also made an important architectural decision.

Google AI Studio will help us generate, inspect, preview, and refine the application, but GitHub and the local development environment will remain essential parts of the engineering process.

Before generating the first BidRadar application, we need to understand the development environment itself.

This is necessary because Google AI Studio is not simply a chatbot that returns isolated code fragments.

Its current Build mode can generate full-stack web applications from natural-language instructions, create and update project files, run an application preview, install packages, use server-side functionality, manage secrets, and deploy applications. Google also provides a separate Playground for experimenting with prompts, Gemini models, structured output, tools, and managed agents.

That makes Google AI Studio extremely useful.

It also creates a risk.

A developer can ask for an application, see an attractive preview, and assume the system is ready.

But a successful preview does not automatically prove that the generated application is:

• Secure
• Maintainable
• Correctly structured
• Multi-tenant
• Properly tested
• Production-ready
• Economical to operate
• Safe for confidential tender documents

The objective of this article is therefore not to generate BidRadar yet.

The objective is to establish a controlled engineering method for using Google AI Studio.

By the end of this article, we will understand:

• The major Google AI Studio workspaces
• How Build mode works
• How to create and inspect projects
• How natural-language instructions affect generated code
• How application previews should be used
• How files and dependencies are managed
• How server-side code differs from browser code
• How secrets must be handled
• How Gemini API keys fit into the application
• How projects should move into GitHub
• How deployment works
• Which tasks should remain outside AI Studio
• How to prevent AI-generated changes from damaging existing functionality
• How to prepare a reusable BidRadar development protocol

Objectives

After completing this article, we should be able to:

• Explain the purpose of Google AI Studio.
• Distinguish Build mode from the Gemini Playground.
• Create a new Build mode application.
• Understand the generated application workspace.
• Navigate between prompts, files, and preview.
• Inspect generated source code.
• Request bounded changes instead of uncontrolled rewrites.
• Understand frontend and server-side responsibilities.
• Install and review application dependencies.
• Protect Gemini API keys and other secrets.
• Recognize the limitations of browser-based previews.
• Export or transfer code into a permanent repository workflow.
• Decide when to use Google AI Studio and when to use local development tools.
• Establish a repeatable BidRadar implementation cycle.
• Create a safe project-context prompt for future development.

What Is Google AI Studio?

Google AI Studio is Google’s browser-based environment for working with Gemini models and building Gemini-powered applications.

It serves several related purposes.

Prompt Experimentation

Developers can test:

• System instructions
• User prompts
• Model parameters
• Structured output
• Multimodal inputs
• Tool definitions
• Function calling
• Long-context tasks

API Prototyping

Once a prompt behaves correctly, AI Studio can help developers obtain code for calling Gemini from an application.

The AI Studio quickstart describes it as an environment for experimenting with Gemini and then obtaining implementation code for supported languages.

Application Generation

Build mode allows developers to describe an application through natural language and generate a working project.

Google’s current documentation describes support for full-stack web applications using natural-language prompting.

Agent Prototyping

The AI Studio Playground can also be used to experiment with managed agents through a visual interface.

For BidRadar, we will use these capabilities differently.

Google AI Studio Build Mode
        │
        ├── Generate application screens
        ├── Create project files
        ├── Implement bounded features
        ├── Preview user journeys
        └── Prototype full-stack behavior
Google AI Studio Playground
        │
        ├── Test tender-analysis prompts
        ├── Test structured JSON schemas
        ├── Evaluate model responses
        ├── Prototype function calling
        └── Prototype agents
Local Development Environment
        │
        ├── Run PostgreSQL
        ├── Manage Alembic migrations
        ├── Execute test suites
        ├── Run Docker services
        ├── Inspect logs
        └── Debug production-like behavior

Google AI Studio Is Not the BidRadar Architecture

One of the most important concepts in this development series is the separation between the development tool and the application architecture.

Google AI Studio is a tool we use to create code.

It should not determine every architectural decision.

BidRadar’s long-term architecture remains:

React Frontend
      │
      ▼
FastAPI Backend
      │
      ├── PostgreSQL
      ├── pgvector
      ├── Redis
      ├── Object Storage
      ├── Background Workers
      └── Gemini API

If Google AI Studio initially generates a simpler application structure, we should treat that structure as a prototype rather than an unchangeable foundation.

For example, AI Studio may generate:

• A frontend with local mock data
• A lightweight server runtime
• Direct Gemini calls
• Simplified persistence
• A minimal authentication model

That may be useful for demonstrating the product.

It does not automatically satisfy our long-term requirements for:

• Multi-tenant PostgreSQL persistence
• Organization-aware authorization
• Background document processing
• Vector search
• Database migrations
• Enterprise auditability
• Asynchronous workers
• Production observability

The product architecture remains ours.

The AI-generated application must gradually conform to it.

The Main Google AI Studio Workspaces

Google AI Studio exposes several workflows that can be relevant to BidRadar.

The interface may evolve, but the underlying concepts remain stable.

1. Build Mode

Build mode is used to create and modify applications.

It typically combines:

• A natural-language conversation
• Project files
• Generated code
• Application preview
• Build and runtime feedback
• Deployment controls

This will be the main workspace used during the application-generation phases of the series.

2. Playground or Prompt Workspace

The Playground is used to experiment directly with Gemini.

It is better suited to tasks such as:

• Testing requirement-extraction prompts
• Comparing model outputs
• Defining JSON schemas
• Evaluating long tender documents
• Testing function calls
• Prototyping agents

3. API Key and Project Management

Gemini API calls require authentication.

Google AI Studio can create or associate API keys with projects. Google’s current API documentation notes that AI Studio can automatically create a project and API key for new users, while additional keys can be created through the API-key interface.

4. Deployment Interface

Build mode can deploy full-stack applications through Google-managed infrastructure. Google’s deployment documentation describes a direct path from Build mode into a managed, scalable environment.

Deployment is useful for previews and early demos.

It does not eliminate the need for production engineering.

Creating a Google AI Studio Project

The first practical step is to create a dedicated project for BidRadar.

Do not mix BidRadar with unrelated experiments.

A clean project boundary helps prevent:

• Context pollution
• Conflicting instructions
• Accidental secret reuse
• Unclear billing
• Confused deployment ownership
• Unmanageable prompt history

Recommended Project Name

BidRadar Development

A more explicit name may be useful if multiple environments are planned:

bidradar-development

Later we may use separate Google Cloud projects such as:

bidradar-development
bidradar-staging
bidradar-production

Do not place production credentials in the initial development project.

Creating the Initial Build Application

Inside Google AI Studio:

1. Sign in with the Google account that will own the project.
2. Open the Build workspace.
3. Create a new application.
4. Give it a clear project name.
5. Begin with a small orientation prompt.
6. Do not paste the complete master build prompt yet.
7. Observe the files and preview that are generated.
8. Verify that the project can be reopened before investing significant work.

For this article, use a deliberately small prompt.

Create a minimal full-stack web application called BidRadar Workspace Test.
Purpose:
This is an environment-validation application, not the real BidRadar product.
Requirements:
1. Create a simple professional dashboard page.
2. Display the title “BidRadar Development Workspace.”
3. Display three status cards:
   - Frontend Preview
   - Server Runtime
   - Gemini Integration
4. Add a button labelled “Run Environment Check.”
5. When clicked, call a server-side endpoint.
6. The endpoint should return:
   {
     "status": "ok",
     "application": "BidRadar",
     "environment": "Google AI Studio"
   }
7. Display the returned result in the interface.
8. Do not use a database.
9. Do not require authentication.
10. Do not include a Gemini API call yet.
Before creating files:
- Explain the proposed structure.
- List the files you expect to create.
- Identify the frontend and server-side responsibilities.
After implementation:
- Summarize the files created.
- Explain how the button reaches the server endpoint.
- Report any limitations.

This small test teaches us more about the workspace than immediately requesting a complete SaaS product.

Why We Begin with a Small Environment Test

A large initial prompt can generate dozens of files and screens.

That creates immediate complexity.

If the preview fails, it becomes difficult to determine whether the problem is caused by:

• The runtime
• A package
• A routing issue
• A syntax error
• A missing environment variable
• A bad dependency
• A generated API call
• A state-management problem

The environment-validation application proves several fundamentals first:

• The project can generate code.
• The frontend preview works.
• Client-side interaction works.
• Server-side code executes.
• The browser can call the server.
• Changes can be applied.
• The project persists correctly.

Once this foundation is understood, we can generate larger features with more confidence.

Understanding the Build Mode Workflow

Build mode usually follows a conversational implementation cycle.

Describe the application
        ↓
Model proposes or generates files
        ↓
Runtime builds the application
        ↓
Preview displays the result
        ↓
Developer inspects behavior
        ↓
Developer requests a change
        ↓
Model modifies files
        ↓
Application rebuilds

This feels simple.

The quality of the outcome depends heavily on how we prompt the system.

Poor development prompts often sound like this:

Make this better.

or:

Fix everything and make it production ready.

These prompts provide almost no boundaries.

The model may:

• Rewrite working components
• Replace dependencies
• Change routing
• Remove features
• Rename files
• Introduce new state management
• Alter visual design
• Add unrequested services

A better prompt is bounded.

Modify only the opportunity status card component.
Requirements:
1. Preserve all existing card content.
2. Add a status badge to the top-right corner.
3. Support the statuses:
   - New
   - Reviewing
   - Bid
   - No Bid
4. Do not change routing.
5. Do not change the API response.
6. Do not add dependencies.
7. Add or update the relevant component test.
Before editing:
- Identify the exact files that require changes.
- Explain why each file must change.
After editing:
- List the modified files.
- Explain how to validate the new behavior.

That is the style we will use throughout this series.

The Prompt Is Part of the Engineering Specification

When using AI Studio, the prompt should not be treated as casual conversation.

It functions as a temporary software specification.

A good implementation prompt contains:

• Product context
• Current architecture
• Exact scope
• Constraints
• Required files or modules
• Data contracts
• Error behavior
• Security expectations
• Test expectations
• Explicit exclusions
• Validation instructions

For BidRadar, a typical prompt structure will be:

Context
Current architecture
Feature objective
Functional requirements
Data requirements
Security requirements
Tenant-isolation requirements
Testing requirements
Out-of-scope items
Planning instructions
Post-implementation report

This structure reduces accidental architectural drift.

The Importance of Asking for a Plan First

Before Google AI Studio modifies a large project, ask it to explain its plan.

The planning response should identify:

• Existing modules involved
• Files that will be modified
• New files that will be created
• Dependencies that may be added
• Database changes
• API changes
• User-interface changes
• Tests that will be added
• Assumptions
• Risks

Example:

Do not modify any files yet.
Inspect the existing application and explain how you would add an opportunity detail page.
Your response must include:
1. Existing routes involved.
2. Components that can be reused.
3. New components required.
4. Data contracts required.
5. Files that would be created.
6. Files that would be modified.
7. Testing approach.
8. Risks to existing functionality.
9. Assumptions.
Wait for a separate implementation instruction before changing code.

Even when the tool does not provide a formal approval gate, this practice forces clearer reasoning and gives the developer an opportunity to detect incorrect assumptions.

Understanding the Generated File Workspace

The file workspace shows the actual project produced by Build mode.

Depending on the generated application, it may include files such as:

src/
├── components/
├── pages/
├── services/
├── hooks/
├── types/
├── App.tsx
└── main.tsx
server/
├── routes/
├── services/
└── index.ts
package.json
vite.config.ts
tsconfig.json
.env.example

The exact structure may differ.

The important point is that the preview is generated from these files.

The developer should inspect them.

Do not judge the application only from the rendered screen.

What to Inspect in Every Generated Project

package.json

Review:

• Framework versions
• Scripts
• Runtime dependencies
• Development dependencies
• Unexpected packages
• Duplicate libraries
• Outdated libraries

Ask:

• Why is each dependency necessary?
• Is a large package being used for one small function?
• Has the model installed multiple competing UI libraries?
• Are versions pinned appropriately?

Application Entry Point

Inspect:

• How the application starts
• Which providers wrap the application
• How routing is configured
• Whether errors are handled globally
• Whether configuration is centralized

Routes

Review:

• Public routes
• Protected routes
• Nested routes
• Fallback routes
• Error pages
• Deep-link behavior

Components

Look for:

• Extremely large components
• Repeated markup
• Hardcoded data
• Mixed data-fetching and presentation logic
• Inline business logic
• Missing accessibility labels

Services

Review:

• API-client structure
• Error handling
• Request typing
• Authentication headers
• Retry behavior
• Environment configuration

Server Code

Inspect:

• Input validation
• Secret handling
• Error responses
• Logging
• CORS
• Rate limits
• Dependency boundaries
• Client exposure

Styling

Check:

• Consistency
• Responsiveness
• Accessibility
• Repeated styles
• Hardcoded values
• Visual states

Preview Mode Is a Development Aid, Not Proof of Production Readiness

The application preview is one of Google AI Studio’s strongest features.

It makes development tangible.

We can immediately inspect:

• Layout
• Navigation
• Interactions
• Forms
• Loading behavior
• Error behavior
• Responsive design
• Server responses

But preview success proves only that the application runs in the preview environment under the tested conditions.

It does not prove:

• Production hosting works.
• Authentication is secure.
• Cross-tenant access is impossible.
• Database migrations are valid.
• File processing scales.
• All browsers behave correctly.
• Error recovery is sufficient.
• External services are resilient.
• Secrets are protected.
• Automated tests pass.

We should use the preview to answer:

Does the feature behave as expected from a user’s perspective?

We should use automated and local testing to answer:

Is the implementation correct, secure, maintainable, and production-safe?

Frontend and Server-Side Responsibilities

Google AI Studio’s full-stack functionality allows an application to include browser-side and server-side behavior. Google’s full-stack documentation highlights server runtimes for secrets, external APIs, and functionality that should not run in the browser.

This boundary is essential for BidRadar.

Frontend Responsibilities

The browser should handle:

• Rendering pages
• Navigation
• Forms
• Local interface state
• Calling APIs
• Displaying progress
• User interaction
• Accessible feedback

Server Responsibilities

The server should handle:

• Secret API keys
• Authentication checks
• Authorization
• Database access
• Gemini API calls
• Tender processing
• Document storage
• Business rules
• Audit logging
• Rate limiting

Never Put These in Browser Code

Do not expose:

• Gemini API keys
• Database passwords
• Storage secrets
• OAuth client secrets
• Signing keys
• Administrative credentials
• Service-account keys

Any secret bundled into browser JavaScript should be considered public.

Safe Gemini API Integration

A common prototype mistake is calling Gemini directly from frontend code using a private API key.

That may appear to work in a local preview.

It is unsafe for a public SaaS application.

A secure request path should look like this:

Browser
   │
   ▼
BidRadar Backend
   │
   ├── Validate user
   ├── Validate organization access
   ├── Check usage limits
   ├── Build controlled prompt
   ├── Load server-side API key
   ▼
Gemini API

The browser should never receive the private Gemini key.

Managing Secrets in Google AI Studio

Google AI Studio full-stack applications can use server-side secrets. Google’s current full-stack documentation specifically identifies secrets and external API access as server-side capabilities.

For BidRadar, possible development secrets include:

GEMINI_API_KEY
DATABASE_URL
REDIS_URL
OBJECT_STORAGE_ACCESS_KEY
OBJECT_STORAGE_SECRET_KEY
JWT_SIGNING_KEY

At this stage, only GEMINI_API_KEY is likely to be needed.

Even then, follow several rules.

Rule 1 — Use a Development Key

Do not use a future production key.

Rule 2 — Apply Restrictions Where Available

Restrict usage through the relevant project and billing controls.

Rule 3 — Never Paste Secrets into Prompts

Do not write:

My Gemini key is AIza...
Please add it to the application.

Prompt histories may persist.

Rule 4 — Never Commit Secrets

The repository should include:

.env.example

but not:

.env

Rule 5 — Rotate Exposed Keys

If a key appears in:

• Source code
• A screenshot
• A prompt
• A commit
• A public deployment

revoke and replace it.

Recommended Environment File

Later, the local project may contain:

GEMINI_API_KEY=
DATABASE_URL=
REDIS_URL=
STORAGE_ENDPOINT=
STORAGE_ACCESS_KEY=
STORAGE_SECRET_KEY=
JWT_SECRET=

The committed example should contain names only.

# .env.example
GEMINI_API_KEY=
DATABASE_URL=
REDIS_URL=
STORAGE_ENDPOINT=
STORAGE_ACCESS_KEY=
STORAGE_SECRET_KEY=
JWT_SECRET=

Dependencies and Package Installation

Build mode can generate applications that use external packages.

For every added dependency, record:

• Package name
• Version
• Purpose
• License considerations
• Security implications
• Bundle impact
• Maintenance status

Do not allow the model to install packages casually.

A controlled dependency prompt looks like this:

Before adding a new package:
1. Check whether the existing dependencies already provide the required capability.
2. Explain why a new dependency is necessary.
3. State the exact package name.
4. State which files will use it.
5. Avoid adding overlapping libraries.
6. Do not upgrade unrelated dependencies.

For BidRadar, dependency discipline matters because the platform will eventually contain:

• Rich text editing
• Document upload
• Charts
• Authentication
• Data fetching
• Tables
• Validation
• Date handling
• Testing
• Accessibility components

Without discipline, the project can become bloated quickly.

Avoiding Duplicate Technology Choices

AI-generated applications sometimes accumulate competing tools.

Examples include:

• Axios and native fetch
• Multiple component libraries
• Two date libraries
• Multiple form libraries
• Several icon libraries
• Multiple state-management approaches

The BidRadar architecture should standardize early.

Suggested frontend standards:

HTTP and server state:
TanStack Query + one API client
Forms:
One form library or a consistent controlled-form pattern
Validation:
Shared schema strategy
Dates:
One date library
Icons:
One icon library
UI:
One component system

Do not let every article introduce a new alternative.

Inspecting Changes After Each Prompt

After a feature request, do not immediately continue with another prompt.

Review:

• Which files changed?
• Were unrelated files touched?
• Was working functionality removed?
• Were dependencies added?
• Did data contracts change?
• Did the model introduce mock data?
• Were tests added?
• Were secrets exposed?
• Did tenant context disappear?
• Were error states added?

A useful post-change instruction is:

Provide a change report.
Include:
1. Every file created.
2. Every file modified.
3. Every file deleted.
4. New dependencies.
5. Changed API contracts.
6. New environment variables.
7. Tests added or updated.
8. Known limitations.
9. Areas that still use mock data.
10. Any security assumptions.

Preserving Existing Functionality

As the project grows, a vague prompt may cause regressions.

Every substantial implementation prompt should state:

Preserve all existing behavior unless a change is explicitly required by this task.

It should also identify protected areas.

Example:

Do not modify:
- Authentication behavior
- Existing API response schemas
- Main navigation
- Organization context
- Shared design tokens
- Existing tests unrelated to this feature

This does not guarantee perfection, but it reduces unnecessary changes.

Working in Small Feature Units

Do not ask AI Studio to implement:

Authentication, organizations, tender import, AI analysis, RAG, proposal generation, workflows, and deployment.

That is too broad.

Break the work into bounded units.

For example:

Part 21:
User registration and login
Part 22:
Organization management
Part 23:
Role-based access control
Part 24:
Tenant isolation

Each part should result in:

• A limited set of changed files
• A testable user journey
• A clear commit
• A validation checklist
• Known limitations

This makes recovery possible when the generated code is incorrect.

Context Management

Long AI Studio conversations can accumulate conflicting instructions.

The project may contain earlier assumptions that are no longer valid.

To reduce context drift:

• Maintain architecture documents in the repository.
• Reference those documents in prompts.
• Restate critical constraints.
• Start a focused task with a concise current-state summary.
• Avoid discussing unrelated experiments in the BidRadar project.
• Commit before major changes.
• Export or back up the project regularly.
• Begin a new controlled implementation thread when necessary.

A useful task preamble is:

Current project state:
- React frontend exists.
- FastAPI backend exists.
- PostgreSQL is the system of record.
- Organization-scoped authentication is implemented.
- All opportunity queries require organization_id.
- The feature being added is tender document upload.
- Do not change authentication or organization logic.

Architecture Documents as Persistent Context

Prompt history is not a reliable substitute for project documentation.

BidRadar should gradually maintain documents such as:

docs/
├── project-vision.md
├── product-requirements.md
├── architecture.md
├── database-schema.md
├── api-specification.md
├── security-model.md
├── ai-guidelines.md
└── development-workflow.md

Future prompts should instruct AI Studio to read these files before making changes.

Example:

Before implementing this feature, read:
- docs/project-vision.md
- docs/product-requirements.md
- docs/architecture.md
- docs/security-model.md
- docs/ai-guidelines.md
Do not introduce changes that conflict with these documents.

This creates more stable development context than relying solely on the chat.

GitHub Must Become the Source of Truth

Google AI Studio is excellent for generating and previewing code.

GitHub should remain the authoritative repository.

The GitHub repository provides:

• Durable source history
• Branches
• Commits
• Pull requests
• Code reviews
• Issue tracking
• Release tags
• CI/CD
• Rollback capability
• Ownership continuity

The development rule should be:

A feature is not complete until the relevant code exists in the repository, has been reviewed, tested, and committed.

Recommended Repository Workflow

Google AI Studio change
        │
        ▼
Export or synchronize project
        │
        ▼
Create feature branch
        │
        ▼
Review code diff
        │
        ▼
Run tests locally
        │
        ▼
Fix issues
        │
        ▼
Commit
        │
        ▼
Merge after validation

Example branch names:

feature/project-vision
feature/product-requirements
feature/app-shell
feature/opportunity-dashboard
feature/authentication

Exporting the Project

The exact export controls may evolve, but the objective is consistent:

• Obtain the complete source code.
• Preserve the directory structure.
• Preserve configuration files.
• Exclude secrets.
• Import the result into GitHub.
• Verify that it runs outside AI Studio.

The exported application should not be considered portable until it runs locally.

Local validation should eventually include commands such as:

npm install
npm run build
npm run test

For the FastAPI backend:

python -m venv .venv
pip install -r requirements.txt
pytest
uvicorn app.main:app --reload

The exact commands will be defined in later articles.

Deployment from Google AI Studio

Google AI Studio can deploy full-stack Build mode applications into Google-managed infrastructure.

This is useful for:

• Internal demos
• Stakeholder feedback
• UI reviews
• Early prototype testing
• Temporary preview environments

It should not be treated as automatic proof that BidRadar is production-ready.

Before a public deployment, we still need:

• Authentication
• Authorization
• Tenant isolation
• Rate limiting
• Cost controls
• Logging
• Monitoring
• Error tracking
• Data retention
• Backups
• Security review
• Privacy documentation

Preview Deployment Versus Production Deployment

Preview Deployment

Suitable for:

• Internal review
• Mock data
• Demonstrations
• Limited test users
• Short-lived environments

Production Deployment

Requires:

• Managed database
• Secure secrets
• Production domain
• TLS
• Backups
• Monitoring
• Alerting
• Incident procedures
• Access controls
• Billing controls
• Audit logs
• Data-processing agreements

The series will not call BidRadar production-ready merely because it has been published successfully.

What Should Remain Outside Google AI Studio?

Some development tasks are better handled locally or through dedicated infrastructure.

PostgreSQL Administration

Use local or managed database tools for:

• Creating databases
• Inspecting schemas
• Running migrations
• Reviewing query plans
• Testing indexes
• Backups
• Restore testing

Docker

Use local Docker tooling for:

• Service composition
• Networking
• Volumes
• Worker processes
• PostgreSQL
• Redis
• Object storage

Automated Testing

Use local and CI environments for:

• Unit tests
• Integration tests
• End-to-end tests
• Database tests
• Security tests
• Migration tests

Git Operations

Use GitHub and Git clients for:

• Branches
• Diffs
• Commits
• Reverts
• Pull requests
• Tags

Production Operations

Use cloud and observability tools for:

• Logs
• Metrics
• Traces
• Alerts
• Scaling
• Backups
• Incident management

A Decision Framework: Where Should This Task Run?

Use the following decision guide.

Use Google AI Studio When:

• Creating an initial interface
• Prototyping a user journey
• Generating bounded application code
• Testing Gemini prompts
• Testing structured outputs
• Experimenting with AI features
• Generating component variations
• Explaining unfamiliar code
• Preparing a first implementation draft

Use the Local Environment When:

• Running PostgreSQL
• Writing migrations
• Testing Docker
• Debugging dependency problems
• Running the complete test suite
• Inspecting network behavior
• Performing security testing
• Optimizing database queries
• Reproducing production issues

Use GitHub When:

• Reviewing changes
• Preserving history
• Managing branches
• Coordinating contributors
• Running CI/CD
• Tagging releases
• Reverting regressions

Use Google Cloud When:

• Hosting deployed services
• Storing production secrets
• Running managed databases
• Scaling workloads
• Collecting production telemetry
• Managing backups
• Operating production environments

The BidRadar Google AI Studio Development Protocol

We can now define a standard protocol for future articles.

Step 1 — Establish the Current State

Describe:

• What already exists
• Which article was completed
• Which architecture rules apply
• Which modules are protected

Step 2 — Define One Feature

State:

• User outcome
• Functional scope
• Acceptance criteria
• Explicit exclusions

Step 3 — Request a Plan

Ask AI Studio to:

• Inspect files
• Identify changes
• List assumptions
• Explain risks
• Propose tests

Step 4 — Review the Plan

Reject the plan if it:

• Replaces working architecture
• Introduces unnecessary packages
• Weakens tenant isolation
• Exposes secrets
• Mixes unrelated features
• Ignores testing

Step 5 — Implement

Give a separate implementation instruction.

Step 6 — Inspect the Preview

Verify:

• User journey
• Visual states
• Error states
• Loading states
• Responsive behavior

Step 7 — Inspect the Code

Review:

• Files
• Contracts
• Dependencies
• Security
• Tests
• Configuration

Step 8 — Export and Test

Run the feature outside AI Studio.

Step 9 — Commit

Create a bounded Git commit.

Step 10 — Document Limitations

Record:

• Mock data
• Missing tests
• Deferred work
• Known technical debt

Reusable Planning Prompt

Use this prompt before substantial changes.

You are working on the BidRadar application.
Do not modify files yet.
First inspect the existing project and read the relevant documentation.
Your task is to plan the implementation of:
[FEATURE NAME]
Provide:
1. A summary of the current relevant architecture.
2. The user journey being added or changed.
3. Existing components and services that can be reused.
4. New files that should be created.
5. Existing files that should be modified.
6. Data contracts or schemas required.
7. New environment variables required.
8. Dependencies required, with justification.
9. Error cases.
10. Security considerations.
11. Multi-tenant isolation considerations.
12. Automated tests required.
13. Manual validation steps.
14. Assumptions.
15. Out-of-scope items.
Constraints:
- Preserve existing functionality.
- Do not replace established architecture.
- Do not expose secrets to browser code.
- Do not weaken authentication or authorization.
- Do not add unrelated features.
- Do not add dependencies without justification.
Wait for a separate implementation instruction before changing files.

Reusable Implementation Prompt

After reviewing the plan, use:

Implement the approved plan for:
[FEATURE NAME]
Requirements:
1. Follow the existing project architecture.
2. Modify only the files required for this feature.
3. Preserve existing behavior.
4. Use strict TypeScript and Python typing.
5. Validate all external input.
6. Add structured error handling.
7. Add appropriate logging.
8. Preserve organization-level tenant isolation.
9. Keep secrets server-side.
10. Add or update automated tests.
11. Do not implement out-of-scope functionality.
12. Do not silently change API contracts.
After implementation, provide:
1. Files created.
2. Files modified.
3. Files deleted.
4. Dependencies added.
5. Environment variables added.
6. API contracts changed.
7. Tests added or updated.
8. Commands required to run the feature.
9. Manual validation steps.
10. Known limitations.

Reusable Code-Review Prompt

After implementation:

Review the implementation you just created.
Do not modify code yet.
Evaluate:
1. Functional correctness.
2. Architectural consistency.
3. Type safety.
4. Error handling.
5. Security.
6. Secret handling.
7. Authentication and authorization.
8. Multi-tenant isolation.
9. Accessibility.
10. Performance.
11. Test coverage.
12. Dependency quality.
13. Maintainability.
14. Areas using mock data.
15. Risk of regressions.
Classify findings as:
- Critical
- High
- Medium
- Low
For each finding, identify the relevant file and recommend a specific correction.

This turns Google AI Studio into both a generator and a first-pass reviewer.

The final judgment remains with the developer.

Testing the Environment Application

Return to the small workspace test created earlier.

Verify the following.

Frontend Validation

• The dashboard loads.
• The title is visible.
• The three status cards appear.
• The button is accessible.
• The result area is initially empty.
• A loading state appears after clicking.
• The server response is displayed.
• Repeated clicks do not break the interface.

Server Validation

• The endpoint returns HTTP 200.
• The response matches the requested JSON.
• Invalid methods are rejected.
• Server errors are not exposed as raw stack traces.

Code Validation

• The frontend does not hardcode the successful result.
• The frontend genuinely calls the server endpoint.
• No API key is included.
• No unnecessary packages were added.
• Types exist for the response.
• Errors are handled.

Recommended Improvements to the Workspace Test

After the first version works, issue a bounded refinement prompt.

Improve only the environment-check feature.
Requirements:
1. Add a loading state to the button.
2. Disable the button while the request is running.
3. Display a green success message when the response status is “ok.”
4. Display a clear error message if the request fails.
5. Add a timestamp to the server response.
6. Do not change the page layout.
7. Do not add dependencies.
8. Add or update tests for success and failure behavior.
Before editing:
- Identify the files that require changes.
After editing:
- Explain how to test success and failure states.

This gives us a realistic first experience with iterative generation.

Common Google AI Studio Development Mistakes

Mistake 1 — Generating the Entire Platform in One Prompt

Result:

• Large uncontrolled codebase
• Inconsistent architecture
• Mock features presented as complete
• Difficult debugging

Correction:

Build one bounded capability at a time.

Mistake 2 — Trusting the Preview

Result:

• Attractive application with insecure or fragile code

Correction:

Inspect source, export, and test locally.

Mistake 3 — Putting API Keys in Frontend Code

Result:

• Key theft
• Unexpected usage
• Billing exposure

Correction:

Call Gemini from server-side code.

Mistake 4 — Repeatedly Asking “Fix It”

Result:

• Unpredictable rewrites
• Hidden regressions
• Architectural drift

Correction:

Describe the exact failure and constrain the repair.

Mistake 5 — Skipping Git Commits

Result:

• No rollback point
• Difficulty identifying regressions

Correction:

Commit every validated milestone.

Mistake 6 — Adding Too Many Dependencies

Result:

• Larger bundles
• Security risks
• Maintenance burden

Correction:

Require justification for each package.

Mistake 7 — Ignoring Tenant Isolation

Result:

• Potential cross-customer data exposure

Correction:

Make organization context explicit in every data feature.

Mistake 8 — Treating AI Output as Authoritative

Result:

• Unsupported claims
• Incorrect tender analysis

Correction:

Require evidence and human review.

Troubleshooting Google AI Studio Build Projects

Blank or Failed Preview

Check:

• Build errors
• Browser console
• Invalid imports
• Missing dependencies
• Incorrect environment variables
• Server failures
• Route configuration

Ask AI Studio:

Do not rewrite the application.
Diagnose the current preview failure.
Provide:
1. The exact error.
2. The likely root cause.
3. The files involved.
4. The smallest safe correction.
5. The validation steps.
Do not modify unrelated files.

Package Import Error

Check:

• Whether the package is listed in package.json
• Import spelling
• Installed version
• Browser versus server compatibility
• Default versus named exports

Environment Variable Missing

Confirm:

• The variable name
• Server versus client scope
• Secret configuration
• Development fallback behavior
• Whether the application should fail fast

Server Endpoint Fails

Inspect:

• Route path
• HTTP method
• Request body
• Validation
• Server logs
• CORS
• Error handling

Generated Change Removed a Feature

Stop immediately.

Do not continue layering changes.

Restore from:

• The previous Git commit
• An exported backup
• A known working project version

Then reissue a smaller prompt.

Security Checklist for AI Studio Projects

Before accepting any generated feature, verify:

• No secrets appear in frontend code.
• No secret values appear in prompts.
• Environment files are excluded from source control.
• External input is validated.
• Server errors do not expose internal details.
• Authentication-sensitive logic runs server-side.
• Authorization is not implemented only in the UI.
• Organization identifiers are not trusted blindly.
• File uploads are restricted.
• Logs do not contain confidential document content.
• Gemini prompts do not unnecessarily include sensitive information.
• Usage limits can be enforced server-side.

Cost-Control Principles

Google AI Studio may make Gemini integration easy, but easy integration can also produce uncontrolled usage.

For BidRadar, every AI feature should eventually record:

• Organization
• User
• Feature
• Model
• Input tokens
• Output tokens
• Request duration
• Status
• Error
• Estimated cost
• Cached or uncached result

During early development:

• Avoid automatic Gemini calls on every page load.
• Do not regenerate unchanged analyses.
• Cache completed summaries.
• Use lower-cost models for simple classification.
• Reserve higher-capability models for complex reasoning.
• Require explicit user actions for expensive operations.
• Use test documents rather than large production document sets.

Documentation Created in This Article

Add a new document:

docs/
└── google-ai-studio-workflow.md

Recommended contents:

# Google AI Studio Development Workflow
## Purpose
Describe how Google AI Studio is used within BidRadar development.
## Tool Responsibilities
- AI Studio Build mode
- AI Studio Playground
- GitHub
- Local development
- Cloud deployment
## Prompt Protocol
- Planning prompt
- Implementation prompt
- Review prompt
## Security Rules
- Server-side secrets
- No API keys in frontend
- No secrets in prompts
- Environment-file policy
## Change Management
- Small bounded tasks
- Preview validation
- Code review
- Local testing
- Git commit
## Definition of Done
- Feature works
- Tests pass
- Security reviewed
- Code committed
- Limitations documented

Google AI Studio Prompt for This Article

Paste the following prompt into the BidRadar AI Studio project.

You are helping me establish a controlled development workflow for BidRadar.
BidRadar is an AI Tender Intelligence and Proposal Automation SaaS platform for IT service providers.
Do not generate the real BidRadar application yet.
Create a small environment-validation application called:
BidRadar Development Workspace
Purpose:
The application must demonstrate that the Google AI Studio project can support a frontend preview and a server-side endpoint.
Requirements:
1. Create a clean professional dashboard.
2. Use a dark enterprise-style interface with restrained green accents.
3. Display the heading:
   “BidRadar Development Workspace”
4. Display a short description:
   “Google AI Studio full-stack environment validation.”
5. Add three status cards:
   - Frontend Preview
   - Server Runtime
   - Gemini Integration
6. Frontend Preview should initially display “Ready.”
7. Server Runtime should initially display “Not checked.”
8. Gemini Integration should display “Not configured.”
9. Add a button:
   “Run Environment Check”
10. When the button is clicked, call a server-side endpoint.
11. The endpoint must return:
   {
     "status": "ok",
     "application": "BidRadar",
     "environment": "Google AI Studio",
     "timestamp": "<current ISO timestamp>"
   }
12. Display a loading state while the request runs.
13. Display a clear success state after a successful response.
14. Display a clear error state if the request fails.
15. Do not use a database.
16. Do not use authentication.
17. Do not call Gemini.
18. Do not require an API key.
19. Do not add unrelated pages.
20. Do not add unnecessary dependencies.
Before creating or modifying files:
1. Explain the proposed frontend and server architecture.
2. List all files that will be created.
3. List all dependencies that will be used.
4. Identify assumptions.
After implementation:
1. List all files created or modified.
2. Explain the frontend-to-server request flow.
3. Explain how errors are handled.
4. Explain how to validate the feature manually.
5. Report known limitations.

Expected Result

The project should produce:

• A working full-stack preview
• A frontend dashboard
• A server-side environment-check endpoint
• Loading, success, and failure states
• No Gemini dependency
• No database dependency
• No exposed secrets

The result is intentionally simple.

The objective is to understand the environment before introducing the complexity of the real BidRadar platform.

Validation Checklist

Before continuing to Part 3, verify that:

• A dedicated Google AI Studio project exists.
• The project name clearly identifies BidRadar.
• Build mode opens successfully.
• The generated file workspace can be inspected.
• The application preview loads.
• The frontend can call a server endpoint.
• The environment-check response is displayed.
• Loading behavior works.
• Failure behavior exists.
• No Gemini API key is required.
• No secret appears in browser code.
• No unnecessary dependencies were added.
• The generated files have been reviewed.
• The application can be changed using a bounded prompt.
• The change report identifies modified files.
• The role of Build mode is understood.
• The role of the Playground is understood.
• The role of GitHub is understood.
• The role of local development is understood.
• The deployment distinction between preview and production is understood.
• docs/google-ai-studio-workflow.md has been prepared.
• The reusable planning, implementation, and review prompts have been saved.

Recommended Git Commit

Once the repository is established, use:

docs(workflow): define controlled Google AI Studio development process

The environment-validation application may later use:

feat(workspace): add Google AI Studio full-stack environment check

What We Built

In this article, we did not build a BidRadar product feature.

We built the process that will allow future product features to be created safely.

We established:

• The role of Google AI Studio
• The distinction between Build mode and the Playground
• The relationship between AI Studio, GitHub, local development, and Google Cloud
• A small full-stack environment-validation application
• A prompt-planning workflow
• A bounded implementation workflow
• A code-review workflow
• Rules for inspecting generated files
• Rules for package management
• Rules for preserving existing functionality
• Server-side secret requirements
• Safe Gemini API integration principles
• Export and deployment boundaries
• A repeatable Definition of Done

This foundation is critical.

Without it, the development series could become a collection of disconnected AI-generated screens.

With it, Google AI Studio becomes a controlled engineering accelerator supporting a deliberate and maintainable BidRadar architecture.

Next Article

Part 3 — Defining the Product Requirements Document

In the next article, we will create the formal BidRadar Product Requirements Document.

The PRD will define:

• Product objectives
• User personas
• User journeys
• Functional requirements
• Non-functional requirements
• MVP boundaries
• Roles and permissions
• Tender workflows
• AI behavior
• Evidence requirements
• Human approval checkpoints
• Acceptance criteria
• Out-of-scope capabilities
• Risks
• Success metrics

We will create:

docs/
└── product-requirements.md

We will also prepare a complete Google AI Studio prompt that uses the project vision from Part 1 and the controlled workflow from Part 2 to produce a structured PRD without generating application code prematurely.

The result will become one of the primary documents that every future Google AI Studio implementation prompt must read before modifying BidRadar.