DEV Community: Kwasi Baidoo

How to Generate Dummy Data for Excel Spreadsheets Using FakerForge (Free CSV Export)

Kwasi Baidoo — Sun, 05 Jul 2026 19:16:00 +0000

You've built a spreadsheet template. Maybe it's an inventory tracker, a customer list, or a sales report mockup. Now you need it to look real — filled with realistic names, dates, prices, and IDs — so you can test formulas, build a demo, or show a client what the finished product will look like.

The usual options aren't great:

Typing fake rows by hand (slow, repetitive, and always ends up looking like "John Doe" fifty times)
Copying real customer data into a spreadsheet (a compliance headache, and overkill for a mockup)
Using a generic "lorem ipsum" data generator that has no idea what an "order date" or "SKU" column is supposed to contain

FakerForge solves this by letting you describe your columns in plain terms, generating realistic rows that actually match each column's purpose, and exporting the result as a CSV file you can open directly in Excel (or Google Sheets, Numbers, LibreOffice Calc — any tool that reads CSV).

Example Scenario: A Sample Product Inventory Sheet

Let's say you're building an inventory tracking spreadsheet and you want it pre-filled with realistic sample data to test your formulas and pivot tables. Your sheet needs these columns:

Column	Description
`product_id`	Unique identifier for each product
`product_name`	Name of the product
`category`	Product category (e.g., Electronics, Apparel, Home Goods)
`unit_price`	Price per unit in USD
`quantity_in_stock`	Number of units currently in stock
`supplier_email`	Contact email for the supplier
`date_added`	Date the product was added to inventory

Instead of typing 100 fake rows by hand, here's how to get this filled in with FakerForge in a few minutes.

Step-by-Step: From Column List to a Filled Excel Sheet

Step 1: Describe your columns as a schema

Go to fakerforge.com/generate and paste your column list in as a simple schema — you don't need real SQL syntax, a plain table definition works fine. For the inventory example, you could paste something like:

Table: products
- product_id (unique identifier)
- product_name (text)
- category (text)
- unit_price (decimal, USD)
- quantity_in_stock (integer)
- supplier_email (email)
- date_added (date)

FakerForge parses this into a table with recognized fields, ready for the next step.

Step 2: Let FakerForge detect and map each column

Once your schema is parsed, FakerForge assigns a faker mapping to each column based on its name and type — an email-style column gets realistic email formats, a date column gets valid dates, and so on. You can review and adjust these mappings before generating anything, so a column like category can be constrained to a specific set of values (Electronics, Apparel, Home Goods) instead of random text.

Step 3: Set your row count

Decide how many sample rows you want — 20 rows to sanity-check your formulas, or a few hundred to properly stress-test a pivot table. On the free plan you can generate up to 100 rows per table, which is plenty for most spreadsheet mockups and demos.

Step 4: Generate

Run the generation step. FakerForge streams the rows in and shows you a live preview, so you can catch anything that looks off before exporting.

Step 5: Export as CSV and open in Excel

Once you're happy with the preview, export your table as CSV. Open the downloaded file directly in Excel — File → Open, or just double-click it — and you'll have a fully populated sheet with realistic product IDs, names, categories, prices, stock counts, supplier emails, and dates, all ready for your formulas, charts, and pivot tables.

Why This Beats Manually Typing Sample Data

It's actually realistic. A supplier_email column gets real-looking email addresses, not "test1@test.com" repeated 100 times. A unit_price column gets sensible decimal values instead of round numbers that don't stress-test your rounding formulas.

It respects your column names. FakerForge reads what each column is called and generates data that fits — dates in date columns, numbers in numeric columns, categories that make sense for a category field.

It scales instantly. Need 20 rows for a quick check and then 500 rows for a bigger demo? Just change the row count and regenerate — no retyping.

No real data involved. Every value is synthetic, so there's no risk of accidentally putting a real customer's name, email, or price data into a spreadsheet you're going to share around the office or with a client.

Beyond a Single Sheet

If your spreadsheet needs multiple related tabs — say, a products sheet and an orders sheet where each order references a real product ID — FakerForge's relationship-aware generation handles that too. Parent tables (like products) generate first, and child tables (like orders) reference valid parent rows, so you don't end up with an order pointing to a product that doesn't exist.

Getting Started

You can try this entire workflow on FakerForge's free tier:

100 rows per table
10 tables per database
CSV, JSON, or SQL export

That's enough to fill out a realistic sample spreadsheet in a few minutes.

Generate your first dummy dataset for Excel →

Generate Realistic Dummy Data for CRM Testing (Salesforce, HubSpot & Custom CRMs) with FakerForge

Kwasi Baidoo — Sat, 04 Jul 2026 15:00:33 +0000

If you've ever tested a CRM integration, built a custom CRM, or set up a demo environment for a sales team, you've probably run into the same problem: you need contacts, companies, and deals in the system, but you don't want to use real customer data to get there.

This shows up constantly across popular CRM tools and custom-built systems:

Salesforce developers testing a new Apex trigger or Flow against sandbox records
HubSpot teams building a new pipeline stage or workflow automation before rolling it out
Zoho CRM or Pipedrive admins configuring custom fields and needing sample records to validate them
In-house/custom CRMs built on Laravel, Django, Rails, or similar frameworks, where the database needs seeding before QA can even start

Copying real contacts and deals into a sandbox or staging CRM to test with isn't just risky — it's also usually against the CRM vendor's own data-handling terms, and it puts real customer PII somewhere it doesn't need to be. FakerForge gives you a faster, safer alternative: describe your CRM's data structure once, and generate as many realistic, relationship-aware test records as you need.

What a CRM Test Dataset Actually Needs

Most CRMs — whether it's Salesforce, HubSpot, or something you built yourself — are built around a similar core structure:

Contacts — names, emails, phone numbers, job titles
Companies/Accounts — company names, industries, sizes, websites
Deals/Opportunities — deal names, stages, values, close dates, and a reference back to the contact and company they belong to
Activities — notes, tasks, or call logs tied to a contact or deal

The tricky part isn't generating fake names and emails — plenty of tools can do that. The hard part is making sure every deal correctly points to a real contact and company in the same dataset, and every activity points to a real deal. That's where most quick "fake data" scripts fall apart, and it's exactly what FakerForge is built to handle.

How to Generate CRM Test Data with FakerForge

Step 1: Define your CRM's tables

On fakerforge.com/generate, paste in a schema describing your CRM's core objects. If you're testing a custom CRM, you likely already have this as a database schema or migration file — just paste it in directly. If you're testing against Salesforce, HubSpot, or another SaaS CRM, describe the objects and fields you're working with in the same format, for example:

Table: companies
- id (unique identifier)
- name (company name)
- industry (text)
- website (url)

Table: contacts
- id (unique identifier)
- company_id (references companies.id)
- full_name (text)
- email (email)
- job_title (text)
- phone (phone number)

Table: deals
- id (unique identifier)
- contact_id (references contacts.id)
- company_id (references companies.id)
- deal_name (text)
- stage (text: Prospecting, Qualified, Proposal, Closed Won, Closed Lost)
- value (decimal, USD)
- close_date (date)

FakerForge parses this into tables, detects the foreign keys (company_id, contact_id), and understands that contacts and deals depend on companies existing first.

Step 2: Review the generated field mappings

Each column gets mapped to a realistic faker method automatically — email fields get valid email formats, phone fields get properly formatted numbers, deal_name fields get plausible-sounding deal titles. You can adjust any mapping before generating, which is useful for a field like stage, where you'll want to constrain values to your actual pipeline stages rather than random text.

Step 3: Set row counts per object

Decide how many companies, contacts, and deals you need. A common pattern for CRM testing is a smaller number of companies with several contacts and deals attached to each — for example, 20 companies, 60 contacts, and 100 deals — so your pipeline views and reports have enough volume to look realistic.

Step 4: Generate with relationships intact

Run the generation step. Parent tables generate first — companies, then contacts, then deals — so every contact has a valid company_id, and every deal has a valid contact_id and company_id. No orphaned deals pointing to companies that don't exist.

Step 5: Export and import into your CRM

Export the result as CSV, JSON, or SQL depending on how your CRM accepts data:

CSV works well for Salesforce Data Import Wizard, HubSpot's contact/company import tools, or Zoho's import feature
JSON is useful if you're testing against a CRM's REST API directly
SQL is the right choice if you're seeding a custom CRM's own database

Why This Beats Hand-Building CRM Test Data

Referential integrity, automatically. Every deal references a real contact and company in the same dataset — no broken lookups when you open a deal record and the associated contact is missing.

Volume without the tedium. Populating a sandbox with 100 believable deals across 20 companies by hand would take hours. Generating it takes minutes, and you can regenerate a fresh batch any time your schema changes.

No real customer data anywhere near your sandbox. Every name, email, and phone number is synthetic, so there's no compliance concern about putting real contact records into a test or demo CRM instance.

Works whether you're testing a SaaS CRM or building your own. The same schema-first workflow applies whether you're prepping records for a Salesforce sandbox import or seeding the database behind a CRM you're building from scratch.

Getting Started

FakerForge's free tier covers a solid CRM test dataset out of the box:

100 rows per table
10 tables per database
Export as SQL, JSON, or CSV

That's enough to seed companies, contacts, deals, and activity logs for a realistic CRM test run.

Generate your CRM test dataset →

Building a Self-Hosted Photo Organizer with Face Recognition (Laravel + FastAPI + InsightFace)

Kwasi Baidoo — Fri, 03 Jul 2026 09:05:38 +0000

I take a lot of photos. Like most people, I'd been dumping them into Google Photos for years, mostly for the face-grouping feature — that quiet magic where it just knows which photos have your kid, your friend, your dog in them. Then I started wondering: could I build that myself, on my own hardware, without shipping every photo of my family to a cloud provider?

Turns out, yes — and it became one of the more satisfying infrastructure projects I've built in a while.

This post walks through the architecture, the interesting technical decisions, and a few of the harder problems I ran into along the way.

What it does

At a high level: you upload photos, the system detects faces in them, groups similar faces into "people," and gives you a dashboard to browse, tag, and correct those groupings — all running locally via Docker, no external API calls, no subscription.

Three repositories make up the project:

face-pipeline — a FastAPI service that does the actual computer vision work
face-pipeline-ui — a Laravel application that provides the dashboard, uploads, and real-time progress
photo-organizer — the deployment layer, tying everything together with Docker Compose

The face recognition pipeline

The core of the project is InsightFace, using two of its models in sequence:

SCRFD for face detection — finding the bounding boxes of faces in a photo
ArcFace for generating embeddings — turning each detected face into a vector that captures its distinguishing features

Once you have embeddings, the interesting problem becomes: how do you group them into "people" without knowing in advance how many people exist, or manually labeling anything?

I used HDBSCAN, a density-based clustering algorithm that doesn't require you to specify the number of clusters upfront — a good fit here since you have no idea how many distinct people are in a given photo library. Face embeddings get stored in pgvector (a Postgres extension for vector similarity search), which makes it fast to compare new faces against existing clusters.

That last point matters more than it sounds. Naively, you'd want to re-cluster the entire dataset every time a new photo comes in — expensive, and it gets worse as your library grows. Instead, the pipeline does incremental centroid matching: each existing cluster has a centroid (essentially, its "average face"), and new detections get compared against those centroids first. Only when something doesn't confidently match an existing cluster does it get treated as a new person or an ambiguous case for review. This keeps ongoing processing fast even as the library scales.

To keep cluster quality high, two filters run before anything reaches the clustering stage:

Blur scoring, using variance-of-Laplacian, to filter out faces too blurry to be useful
Relative face-size filtering, to discard faces that are too small in the frame to produce a reliable embedding

Garbage in, garbage out applies especially hard to face clustering — a handful of bad embeddings can pull a whole cluster in the wrong direction.

The application layer

The FastAPI service is deliberately narrow — it does computer vision and nothing else. Everything user-facing lives in a Laravel app: project management, photo uploads, browsing detected people, correcting misclassifications, and a real-time dashboard showing pipeline progress.

That real-time piece uses Laravel Reverb, Laravel's self-hosted WebSocket server. When you upload a batch of photos, they get processed asynchronously through the pipeline, and the UI updates live as each stage completes — detection, embedding, clustering — rather than making you refresh or poll.

Two deployment modes

One thing I wanted from the start: this shouldn't be an "advanced users only" project. So photo-organizer ships two ways to run it:

Single-container mode — everything (web server, queue workers, scheduler, websocket server) runs in one container. Simplest possible setup: clone, docker compose up, done. Good for trying it out or running it on modest hardware.

Multi-container mode — the same Laravel app split across independent containers for the web server, Horizon (queue workers), the scheduler, and Reverb, each able to scale independently. If you're processing a large photo library and want to throw more workers at the queue without touching anything else, this is the mode for that.

Splitting a working single-container setup into multiple containers turned out to be its own small adventure — Docker networking has opinions about what localhost means that don't survive the transition, and I hit a genuinely subtle bug where WebSocket broadcasts silently failed once the app was split, because the same environment variable was quietly doing two incompatible jobs (telling the browser where to connect, and telling the backend where to publish). That's a story for its own post, but the short version is: if you're planning to split a monolithic Docker container into services, audit every environment variable for hidden dual purposes before you do.

What I'd do differently

A few honest reflections, since a lot of the value in writing these things up is being straight about the rough edges:

Cluster tuning takes patience. HDBSCAN's min_cluster_size and min_samples parameters meaningfully change how aggressively faces get grouped, and the right values depend on your specific photo library — how many photos per person, how much lighting/angle variation, etc. I exposed these as configurable environment variables rather than hardcoding a "correct" value, because there isn't one.
Shared storage between services needs care. The FastAPI pipeline and the Laravel app both need access to the same photo/face-crop files, which means getting file permissions right across containers running as different users — a small thing that cost more debugging time than the computer vision code did.
Incremental matching is worth the complexity. I almost skipped it in favor of simpler full re-clustering, and I'm glad I didn't — the difference in how the system feels as your library grows is significant.

Try it

Everything is open source (Apache-2.0):

photo-organizer — start here for deployment
face-pipeline — the FastAPI/InsightFace service
face-pipeline-ui — the Laravel dashboard

If you're into self-hosting, computer vision, or just enjoy a good Docker Compose stack, I'd love feedback — issues, PRs, or just thoughts on the architecture are all welcome.

AI-Assisted Data Generation: Use Claude or Your AI Agent to Generate Mock Data

Kwasi Baidoo — Fri, 05 Jun 2026 08:19:03 +0000

Imagine asking your AI assistant to generate a complete test database and having it happen instantly without switching tools.

"Generate test data for a users table with 1,000 rows, a posts table with 5,000 rows, and ensure every post references a valid user."

The AI handles it. You get back SQL you can import directly.

This is now possible with FakerForge's MCP integration.

What Is MCP?

MCP (Model Context Protocol) is a standard for connecting AI agents to external tools and services. Tools like Claude, Cursor, and other MCP-capable clients can invoke these external services directly.

FakerForge exposes an MCP server. This means:

Your AI agent (Claude, Cursor, etc.) can call FakerForge functions
You can ask the agent to generate data in natural language
The agent connects to FakerForge, runs generation, and returns results
All without leaving your editor

Setting Up MCP With FakerForge

According to FakerForge's MCP documentation, the setup process is:

Step 1: Create an MCP Token

Go to FakerForge's MCP token page and create a token. According to the docs:

"Copy it immediately. Store securely in your client config."

This token authenticates your AI agent with FakerForge.

Step 2: Configure Your MCP Client

Add FakerForge to your MCP client config (VS Code, Cursor, Claude Code, or Windsurf):

{
    "mcpServers": {
        "fakerforge": {
            "url": "https://your-domain/mcp/fakerforge",
            "headers": {
                "Authorization": "Bearer YOUR_TOKEN"
            }
        }
    }
}

Step 3: Verify Connectivity

The docs recommend testing with read-only tools first:

"First MCP calls: list-schemas, get-codebase-schema, list-mocks. These verify auth and connectivity before mutation tools."

Once you can list schemas, you're connected.

Real Workflow: Generating Data With Claude

Now you can ask Claude to generate data directly from your editor.

Example 1: Simple Data Generation

User: "I have a users table with id, email, name, and country. 
Generate 100 rows of realistic test data as SQL."

Claude calls FakerForge's MCP tools to:

Parse your schema
Generate 100 rows
Return SQL

You get back:

INSERT INTO users (id, email, name, country) VALUES
(1, 'john.smith@example.com', 'John Smith', 'US'),
(2, 'maria.rodriguez@example.com', 'Maria Rodriguez', 'MX'),
...

Example 2: Multiple Tables With Relationships

User: "Generate test data for a blog platform:
- users table: 50 rows
- posts table: 200 rows (each post references a valid user)
- comments table: 500 rows (each comment references a valid post)
Make sure all foreign keys are valid."

Claude:

Parses your schema (detects the relationships)
Calls FakerForge's generation with row counts
FakerForge handles relationship-aware generation
Returns SQL with valid FK references

You get consistent, valid data without writing anything.

Example 3: List Existing Schemas

User: "What schemas do I have in FakerForge?"

Claude calls list-schemas and returns your existing schemas, letting you reuse them rather than recreating.

Why This Matters

Context Stays in Your Editor

Before MCP, generating data required:

Go to fakerforge.com
Paste schema
Set row counts
Download
Come back to editor

Now: Ask Claude in your editor. Get SQL back. Paste.

Natural Language Interface

Instead of learning FakerForge's UI, you describe what you want in English. Claude translates to the right FakerForge operations.

Integration With Your Workflow

You're already using Claude/Cursor for coding. MCP makes data generation part of that same conversation:

You: "Here's my schema (paste). Generate 1,000 rows of realistic test data."

Claude: "I'll generate that for you."
[Calls FakerForge MCP tools]
"Here's your data: [SQL]"

You: "Perfect, paste it into seed.sql for me"

Claude: "Done. Want me to run the import?"

AI Agents Can Drive Automation

A CI/CD agent or code migration tool can call FakerForge directly via MCP:

# CI/CD pipeline calls Claude agent
agent.ask("Generate test data for schema.sql with 10,000 rows")

# Claude uses FakerForge MCP tools
# Generates data
# CI/CD gets SQL back
# Imports into test database

Security Guidelines

FakerForge's docs emphasize security for MCP:

"Never commit MCP tokens. Rotate tokens on team/member changes. Use least privilege and environment separation."

Best practices:

Store tokens securely — use environment variables or secure credential managers
Rotate on team changes — when someone leaves, revoke their token
One token per integration — don't share a single token across multiple systems
Least privilege — create tokens with only the permissions needed

Practical Example: Setting Up in Cursor

Cursor is VS Code with integrated AI. Here's how to add FakerForge MCP:

Step 1: Create your FakerForge MCP token

Step 2: Open .cursor/mcp.json in your project:

{
  "mcpServers": {
    "fakerforge": {
      "url": "https://api.fakerforge.com/mcp/fakerforge",
      "headers": {
        "Authorization": "Bearer sk-ff_your_token_here"
      }
    }
  }
}

Step 3: In Cursor chat, ask:

I need to generate seed data for my database. 
Here's my schema (paste schema).
Generate 5,000 rows and return as SQL.

Step 4: Cursor calls FakerForge MCP tools, Claude generates data

Step 5: Copy the SQL into your seed file

Done.

What MCP Tools Are Available?

According to the docs, FakerForge exposes tools for:

list-schemas — list all your schemas
get-codebase-schema — retrieve a specific schema
list-mocks — list your mock APIs
Plus mutation tools for generation and mocking

The docs recommend starting with read-only tools (list, get) to verify connectivity, then moving to mutation tools (generate, create).

Common Use Cases

CI/CD Pipeline Automation

Your CI/CD pipeline needs fresh test data:

- name: Generate test data via MCP
  run: |
    claude --mcp fakerforge generate \
      --schema schema.sql \
      --customers 100000 \
      --invoices 500000

Schema Evolution

You modify your schema. Claude automatically regenerates your seed data:

User: "I added a 'phone_number' column to users. 
Update my test data to include it."

Claude: [Detects schema change, regenerates with new field]

Demo Data

Spinning up a demo environment for a customer:

User: "Generate a realistic demo database 
with 100 customers, 1,000 orders, all relationships valid."

Claude: [Generates, returns SQL]

The Docs Say This Is the Future

FakerForge's MCP documentation positions it clearly: AI agents should be able to generate data as easily as developers can today.

The current workflow is:

UI-based (go to website, use UI)
Manual (you decide parameters)
Slow (multiple steps)

MCP-enabled workflow is:

Chat-based (ask in natural language)
Automated (AI decides parameters based on intent)
Fast (one-step)

Bottom Line

If you're already using Claude, Cursor, or similar tools, adding FakerForge's MCP integration is a no-brainer.

Generate test data without leaving your editor. Ask in natural language. Get SQL back. Done.

Get your MCP token and add it to your editor config.

Your data generation workflow just got 10x faster.