DEV Community: Cess Mbugua

Day 24 of 60: I Built an AI Clinic Receptionist That Handles Appointments, Emergencies, and Payments on WhatsApp

Cess Mbugua — Fri, 05 Jun 2026 17:03:39 +0000

Today's build is the most commercially viable thing I have shipped so far.

A mid-sized private clinic in Nairobi with 40-50 appointments per day faces three costly problems every single week.

No-shows. At a 20% no-show rate with KES 2,000 per consultation, that is KES 400,000-500,000 in lost revenue every month. Gone. Because a patient forgot.

Confirmation calls. The receptionist spends 2+ hours every day calling patients just to confirm they are coming. That is 2 hours of skilled human time spent on a task a system can do automatically.

Manual booking errors. Double bookings, lost entries, missed WhatsApp messages from patients who contact the clinic outside office hours.

Meet MediFlow.

## How It Works

Patient sends WhatsApp message
↓
Twilio receives and forwards to MediFlow API
↓
Claude reads the message + patient history + clinic knowledge base
↓
Claude decides: booking, reschedule, question, emergency, or payment
↓
Response sent back to patient via WhatsApp
↓
Every message, decision, and action logged to PostgreSQL
↓
Emergencies escalated to receptionist immediately

Real Conversations

Booking:
Patient: Hello, I would like to book an appointment with Dr. Sarah Kamau at 10am this Friday

MediFlow: Perfect, Cess! Your appointment is confirmed.
Date: Friday 6th June 2026
Time: 10:00 AM
Doctor: Dr. Sarah Kamau
Fee: KES 2,000
Location: 123 Kenyatta Avenue, Nairobi CBD

Emergency detection:
Patient: My child has been having chest pains and difficulty breathing since this morning

MediFlow: This is a medical emergency. Please call 999 immediately or go to the nearest hospital emergency department right away.

Simultaneously the receptionist receives: MEDIFLOW ESCALATION — Patient experiencing chest pain and difficulty breathing; please respond directly.

NHIF question:
Patient: Do you accept NHIF?

MediFlow: Yes, we accept NHIF for outpatient consultations. Bring your NHIF card to your appointment.

What the System Decides vs What Humans Decide**

System decides automatically:
Slot availability. Appointment confirmation. Reminder sending. Clinic questions from knowledge base. Outstanding balance enforcement with M-PESA instructions.

Human decides always:
Emergency symptoms. Balance disputes. Complex or ambiguous cases.

The Numbers

Metric	Before MediFlow	After MediFlow
No-show rate	20%+	Projected 5-8%
Confirmation calls	2+ hours per day	Near zero
After-hours enquiries	0% handled	100% handled
Monthly revenue lost	KES 400,000-500,000	KES 80,000-150,000

Tech Stack

Twilio WhatsApp Business API. Claude API (claude-opus-4-5). FastAPI. PostgreSQL. SQLAlchemy. n8n for reminder scheduling. Railway for cloud deployment.

What I Learned

The hardest part was not the booking logic. It was teaching Claude to read the emotional tone of a message and decide whether it is a routine enquiry or a genuine emergency that needs immediate human intervention.

The difference between "my child has a fever" and "my child has chest pain and difficulty breathing" is not just vocabulary. It is the difference between a standard response and an immediate escalation. Getting that boundary right required careful prompt engineering and extensive testing.

Also: building for Swahili speakers was a deliberate decision. If the system only works in English it does not work for most of the patients it is supposed to serve.

🔗 Full project on GitHub → https://github.com/mbuguacessy-glitch

36 more to go.

python #fastapi #claudeapi #twilio #whatsapp #healthcare #kenya #automation #buildinpublic #learninpublic #100DaysOfCode

Self-Taught AI Automation Engineer Looking for an Internship. Here Is What I Have Built.

Cess Mbugua — Tue, 02 Jun 2026 11:46:34 +0000

My name is Cecilia Mbugua. I am an AI Automation Engineer based in Nairobi, Kenya and I am actively looking for an internship at an AI company or tech team.

I started a 60-day public build challenge; one production-ready AI system every single day. Here is what I have shipped so far:

ClearVet: Enterprise Client Evaluation Pipeline
Potential clients fill a Typeform. Claude evaluates them across 6 dimensions in the background. Score calculated. Slack notification sent with approval buttons. Human decides. Everything logged to PostgreSQL. Zero manual screening.

Live Document Q&A System
Ask any question against any document. Get an answer with source citations in under 3 seconds. Running 24/7 on the cloud.

Async Document Processing Pipeline
Submit a document, receive a job ID instantly, Claude processes in the background. Built for Kenyan law firms, SACCOs, and insurance companies handling high document volumes.

Secured Multi-Tenant API
JWT authentication, API key management per client, rate limiting, usage tracking. Production ready and deployed.

I built all of this but I know there is a level of growth that only comes from working within a real team on real products at scale.

I am available for international remote internships immediately.

If your team is building with AI and you have room for someone who ships every day, let's talk.

📩 mbugua.cessy@gmail.com
🌐 portfolio-amber-gamma-51.vercel.app
🔗 github.com/mbuguacessy-glitch

internship #opentowork #python #fastapi #aiautomation #buildinpublic #claudeapi

Day 23 of 60: Someone Asked Me a Question on Day 3. I Put It on My Build List. Today I Shipped the Answer.

Cess Mbugua — Sun, 31 May 2026 19:44:50 +0000

This build has been on my list since Day 3.

Three weeks ago I posted my client onboarding pipeline. A commenter read it carefully and asked a question that stopped me in my tracks:

"The space has a lot of tools for the work side but almost nothing for evaluating the client side before committing. What's the specific problem you're solving for freelancers?"

I didn't have a full answer that day. So I wrote it down, added it to my build list, and kept going.

Today I built it.

Meet ClearVet.

## The Problem

Imagine you run an AI automation business. Enquiries come in every day. Most are not a good fit. Wrong budget. Vague problem. Unrealistic timeline. Industries you cannot help with.

To figure out which ones are worth your time you have to read every single one manually, ask follow up questions, think about it, and decide. Twenty enquiries a week is hours of screening before you do any real work.

ClearVet automates that entire process.

## The Full Pipeline

Potential client fills Typeform
↓
n8n receives submission via webhook
↓
ClearVet FastAPI endpoint
↓
Claude evaluates across 6 dimensions as background task
↓
Score calculated — HIGH, MEDIUM, or LOW
↓
Slack message sent with dimension scores and approval buttons
↓
Human approves or rejects via API
↓
Decision logged to PostgreSQL with timestamp and notes

## The 6 Evaluation Dimensions

Budget Fit: is the budget realistic for the solution needed?
Problem Clarity: how well defined and specific is the problem?
Timeline Realism: is the timeline actually achievable?
AI Readiness: is the client ready to adopt AI solutions?
Industry Fit: does the industry align with our capabilities?
Growth Potential: what is the long-term revenue potential?

Claude scores each dimension 0-10 with reasoning. Overall score determines the recommendation tier.

## A Real Evaluation Output

{
  "company_name": "Nairobi Logistics Ltd",
  "overall_score": 7.5,
  "recommendation": "high",
  "scores": {
    "problem_clarity": {"score": 9, "reasoning": "Problem is exceptionally well-defined"},
    "growth_potential": {"score": 8, "reasoning": "200 reports daily suggests high volume"}
  },
  "status": "approved",
  "approved_by": "Cess"
}

## What Makes This Different

Human in the loop. Every evaluation requires a human decision before any action is taken. Claude does the analysis. You make the call.

Full audit trail. Every evaluation, score, dimension reasoning, decision, and timestamp stored in PostgreSQL. Nothing disappears.

Background processing. The API responds immediately. Claude evaluates in the background. Slack notification arrives when ready.

Real intake form. Connected to Typeform via n8n webhook. The same form a real potential client would fill out.

## What This Is Worth

A system like this for one agency is a KES 80,000-150,000 setup fee. It replaces hours of manual screening every week. The ROI is immediate and measurable.

37 more to go.

🔗 Full project on GitHub → https://github.com/mbuguacessy-glitch

python #fastapi #claudeapi #n8n #automation #buildinpublic #learninpublic #clearvet #100DaysOfCode @keynition

Day 22 of 60: I Built a Production Background Task Pipeline That Processes AI Jobs Asynchronously

Cess Mbugua — Fri, 29 May 2026 11:06:58 +0000

** The Problem**

Processing large documents through an AI model takes 30-60 seconds. A synchronous API makes the client wait the entire time. Browsers timeout. Users think it crashed. The experience feels broken.

Yesterday I learned why this happens. Today I built the fix.

## What I Built

A document processing pipeline with FastAPI and PostgreSQL that handles long-running AI tasks in the background. Three task types. Immediate response. Full audit trail.

Client submits a document and gets a job ID in milliseconds. Claude processes it in the background. Client polls for the result when ready. Everything logged to PostgreSQL.

## Three Task Types

Summarise: submit a document and receive a structured summary with executive overview and key points. Focus area is configurable.

Extract: specify which fields you want pulled out. Company name, net profit, revenue, key risks. Claude reads the document and returns exactly what you asked for as structured JSON.

Evaluate: provide a list of criteria and Claude checks whether the document meets each one. Returns a pass or fail with reasoning for every criterion.

*## How the Pipeline Works
*

POST /jobs/summarise
↓
Job ID returned in milliseconds
status: pending
↓
Claude processes in background
status: running
↓
GET /jobs/{job_id}
status: completed
full result ready

Optional webhook support means the server can call your endpoint when the job completes and no polling needed.

## The Database Behind It

Every job is stored in PostgreSQL with full audit trail:

Job ID, status at every stage, task type, input data as JSONB, result as JSONB, error message if failed, webhook URL, created timestamp, completed timestamp.

If a job fails the error is recorded for debugging. Nothing disappears silently.

## Real Use Cases

Contract review for law firms. Loan application screening for SACCOs. Insurance claims processing. Report summarisation for enterprises.

The same pipeline. Different documents. Different criteria. One system.

## What I Learned

FastAPI's BackgroundTasks is the simplest way to separate submission from processing. The endpoint returns immediately. The heavy work happens after the response is sent.

JSONB in PostgreSQL stores the full input and result as structured data — not a string you have to parse later. Query it, index it, use it.

Webhooks flip the polling model entirely. Instead of the client asking if the job is done, the server tells the client when it is ready.

🔗 Full project on GitHub → https://github.com/mbuguacessy-glitch

38 more to go.

python #fastapi #async #claudeapi #postgresql #automation #learninpublic #buildinpublic #100DaysOfCode

Day 20 of 60: I Built a Production-Grade Authentication System with JWT Tokens and API Key Managemen

Cess Mbugua — Thu, 28 May 2026 12:31:47 +0000

Every API I've built up to this point has been open. Anyone with the URL could call it. Today I fixed that.

## The Problem

Most beginner APIs have no authentication layer. Anyone who finds your endpoint can call it, abuse it, or overload it. In production that is not acceptable. Real APIs need to know who is calling them, track how often they are being called, and cut off anyone who is abusing them.

Today I built that entire layer from scratch.

## What I Built

A production-grade authenticated multi-tenant API with two separate authentication systems working together:
**
JWT Authentication for admin users**
Admin logs in with email and password. Server verifies credentials, generates a signed token valid for 30 minutes. Every admin request must include that token. No token, no access.

API Key Management for clients
Admin creates a client via a JWT-protected endpoint. Server generates a random 32-byte key using secrets.token_urlsafe(32). The raw key is shown once and never stored. Only its SHA-256 hash lives in the database. Client includes the key in every request as X-API-Key.

Usage Tracking
Every request increments the client's request counter and records the last used timestamp. Full visibility into who is calling what and when.

Rate Limiting
Sliding window algorithm. Each API key gets 10 requests per 60-second window. Exceed that and you get a 429 Too Many Requests error. Abuse is blocked automatically.

Key Revocation
Admin can deactivate any client's key instantly. One endpoint call and that client is locked out immediately.

The Tech Behind It

FastAPI: web framework
PostgreSQL: database for users and API keys
SQLAlchemy: ORM for database interaction
python-jose: JWT token generation and verification
passlib and bcrypt: password hashing
python-dotenv: environment variable management

## What I Learned

The most important lesson today: never store secrets in plain text. Not passwords. Not API keys. Ever.

Passwords are hashed with bcrypt before storage. API keys are hashed with SHA-256 before storage. The raw key is shown once at creation and never seen again. If your database is compromised the attacker still cannot use any of the credentials.

That is what production security actually looks like.

🔗 Full project on GitHub → https://github.com/mbuguacessy-glitch

40 more to go.

python #fastapi #jwt #security #authentication #learninpublic #buildinpublic #100DaysOfCode

Day 19 of 60: From Raw SQL to a Full Stack FastAPI App.

Cess Mbugua — Tue, 26 May 2026 19:51:11 +0000

Today was the heaviest single day of the challenge so far.

Three challenges. Pure databases. From writing raw SQL queries like a data analyst to building a full stack FastAPI application backed by PostgreSQL. All in one sitting.

## Challenge 1: Query an Existing Database Like a Data Analyst

No new tables. Pure querying against existing leads and notes tables. Eight real business questions answered using SQL.

What I wrote:

Which lead has the most notes? Show their name, email and note count
Show all leads and their most recent note. Leads with no notes appear with NULL
How many leads are in each status? Sorted by count descending
Which sources produced more than one lead?
Show all notes written by a specific author with the lead name next to each
Find all leads who have never had a note written by that author
Show the first note ever written for each lead
Show leads whose status is not new and who have at least one note

The hardest query was number 6, finding leads with no notes from a specific author required thinking about what is absent rather than what is present. Subqueries started making real sense here.

## Challenge 2: Build a SQLAlchemy Model from Scratch

A completely new SQLAlchemy model file for a products and orders system — built without copying anything.

What I built:

Product model with id, name, price, stock and created_at
Order model with id, product_id as foreign key, quantity, total_price and created_at
Bidirectional relationship so order.product and product.orders both work
Tables created in PostgreSQL using Base.metadata.create_all()
4 products and 6 orders inserted using SQLAlchemy sessions — no raw SQL
Python logic to find the most expensive order and print product name, quantity and total price
Stock update logic that deducts after an order is placed

## Challenge 3: Full Database Layer in FastAPI

A completely new FastAPI application managing products and orders, backed by the SQLAlchemy models from Challenge 3. Six endpoints built and tested in the docs UI.

Endpoints built and tested:

GET /products: all products with stock levels
POST /products: create a new product
GET /products/{id}L: one product with all its orders
POST /orders: place an order, stock deducts automatically. Returns 400 if stock is insufficient
GET /orders: all orders with product name next to each
DELETE /products/{id}: deletes product and all its orders

Then tested the full workflow manually:
Added a product, confirmed it appeared, retrieved it with orders, placed an order and confirmed stock deducted, retrieved all orders with product names, deleted a product and confirmed its orders disappeared too.

Also practiced truncating the database to reset state cleanly between test runs.

## What I Learned

Three things that clicked today that I will carry into every project:

Subqueries think about absence not presence. Finding what does not exist requires a completely different mental model from finding what does.

SQLAlchemy sessions are the right way to talk to a database from Python. Raw SQL works but ORM models make the code readable, maintainable and safe.

Full stack means every layer has a job. PostgreSQL stores it. SQLAlchemy talks to it. FastAPI exposes it. Each layer does one thing and does it well.

No GitHub link today, pure challenge day documented publicly.

41 more to go.

sql #postgresql #sqlalchemy #fastapi #python #databases #learninpublic #buildinpublic #100DaysOfCode

Day 17 of 60: I Deployed My First Production AI API and It's Live 24/7 (This Changes Everything)

Cess Mbugua — Tue, 19 May 2026 18:56:52 +0000

Today everything became real.

Every system I've built over the past 16 days lived only on my local machine. The moment I closed my laptop it went offline. n8n Cloud couldn't reach it without ngrok running. No client could access it. I couldn't share it with anyone without being physically present.

Today I fixed that. My AI Agent API is live. 24/7. No laptop required.

## The Gap This Closes

There is a clear line between a developer project and a professional product.

A portfolio of systems that only run locally is a collection of demos. A deployed API that runs 24/7 from a cloud server is a product; something you can hand to a client, link to from your LinkedIn, or build a business on.

Today I crossed that line.

## What Got Deployed

A production-ready FastAPI server combining the capabilities from the last three projects into one unified AI agent API:

Document Q&A endpoint: ask questions against any document
Research endpoint: multi-agent research and report generation
Data analysis endpoint: CSV analysis with AI-generated insights

Deployed to Render's free cloud hosting. Permanently accessible at a real URL. n8n Cloud workflows can now call it directly. Clients can access it. It's in my portfolio.

## What I Learned

requirements.txt: the dependency file that tells cloud platforms what to install. Standard for every Python deployment.

Environment variables in production: storing API keys securely on Render so they are never in code or GitHub. This is non-negotiable in production.

Production start command: the uvicorn command Render uses to start the server. Different from how you run it locally.

Health check endpoint: the GET / endpoint that tells Render your service is alive.

Auto-deploy from GitHub: every time I push new code Render redeploys automatically. Continuous deployment from day one.

*🌐 Live API → https://ai-agent-api-w7uh.onrender.com
🔗 GitHub → https://github.com/mbuguacessy-glitch
*
43 more to go!.

python #fastapi #deployment #render #claudeapi #automation #learninpublic #buildinpublic #100DaysOfCode

Day 15 of 60: I Built a Multi-Agent Research System That Researches, Writes and Reviews Reports in Under 60 Seconds

Cess Mbugua — Mon, 18 May 2026 14:01:00 +0000

Today's build is the most sophisticated thing I've shipped so far.

A single AI call handles one task well. But complex research requires four fundamentally different cognitive tasks; finding information, synthesising it, writing a structured report, and reviewing its quality. Each needs different instructions. Different tools. Different evaluation criteria.

So I stopped using one agent and built three.

## The Real World Problem

When you send a complex research question to a single Claude prompt you get a single pass. The response might be well-written but poorly researched. Or well-researched but poorly structured. Or both good but containing errors nobody checked.

In the real world every high-quality deliverable goes through multiple specialist hands. Research agencies, law firms, consulting firms, and newsrooms all use teams, not because one person cannot do the work, but because specialisation and review produce dramatically better results.

## The Analogy That Made It Click

Think of a newspaper editorial team. When a breaking story comes in three people handle it:

The journalist: gathers facts, interviews sources, finds the data. Does not write the final article.
The writer: takes the journalist's notes and turns them into a polished, structured article. Was not at the scene.
The editor: reads the finished article before it publishes. Checks facts, identifies gaps, suggests improvements. Did not gather or write anything.

Three specialists. Three distinct roles. One final product better than any one of them could produce alone.

## How the System Works

Topic comes in
↓
Researcher Agent: searches the web via Tavily
                   summarises findings
↓
Writer Agent: takes research output
               produces structured written report
↓
Reviewer Agent: reads the report
                 returns quality score + specific improvements
↓
Final reviewed report delivered in under 60 seconds

The cast:

Researcher = The journalist: finds information via Tavily web search
Writer = The writer: turns research into a structured report
Reviewer = The editor: checks quality and flags improvements
Orchestrator = The news desk: coordinates handoffs between agents
Claude = The intelligence powering all three with different instructions
Tavily = The press pass: gives the Researcher access to live web search

## What I Learned

The biggest shift today was thinking in roles not prompts. Every agent has its own identity, its own instructions, and its own output format. The output of each becomes the input of the next.

This is the architecture behind every serious AI product being built in 2026. Content agencies, research firms, legal teams, and marketing departments all need research-to-report pipelines that don't require a human at every step.

**🔗 Full project on GitHub → https://github.com/mbuguacessy-glitch

45 more to go.**

ai #multiagent #claudeapi #python #automation #learninpublic #buildinpublic #100DaysOfCode

Day 14 of 60: I Completed RAG and Now I Understand Why It Changes Everything

Cess Mbugua — Sat, 16 May 2026 15:15:25 +0000

Today I finished what I started yesterday. RAG is done. And I finally understand why every serious AI engineer needs to know this.

## Quick Recap: What is RAG?

Retrieval Augmented Generation. Instead of relying purely on what an LLM was trained on, RAG retrieves relevant information from an external knowledge base and passes it to the model as context before generating a response.

The model doesn't need to have been trained on your data. It just needs to be able to read it at the moment you ask.

##: The Complete RAG Pipeline

Documents ingested → chunked into pieces
↓
Each chunk converted into a vector embedding
↓
Embeddings stored in a vector database
↓
User query comes in
↓
Query converted to embedding
↓
Vector database searched for similar chunks
↓
Relevant chunks retrieved
↓
Chunks + query passed to Claude
↓
Claude generates grounded response

## What I Learned

Three concepts that finally clicked today:

Chunking: you can't pass an entire document to an LLM at once. You split it into smaller overlapping pieces so nothing important falls through the gaps.

Vector embeddings: text converted into numbers that capture meaning. Similar concepts end up close together in vector space. That's how the search knows what's relevant.

Grounding: the difference between an AI that guesses and an AI that knows. RAG grounds every response in real retrieved data.

## Why This Changes My Builds

Every automation I've built so far sends data directly in the prompt. RAG means I can now build systems that reference entire company knowledge bases, months of historical data, or hundreds of documents, and still return accurate, grounded responses.

The builds coming next are on a completely different level.

No GitHub link today, pure learning day documented publicly.

46 more to go.

rag #ai #learninpublic #buildinpublic #python #claudeapi #100DaysOfCode

Day 13 of 60: Today I Started Learning RAG

Cess Mbugua — Fri, 15 May 2026 18:32:35 +0000

RAG. Retrieval Augmented Generation.

No build today. Just learning. And honestly it was one of the most mind-expanding study sessions since I started this challenge.

What is RAG?

Every AI model I've worked with so far: Claude, GPT, any LLM, has a knowledge cutoff. It knows what it was trained on and nothing else. Ask it about your company's internal documents, your client's data, or anything that happened after training; it has no idea.

RAG fixes that.

Instead of relying purely on what the model was trained on, RAG retrieves relevant information from an external source; a database, a document store, a knowledge base — and passes it to the model as context before generating a response.

The model doesn't need to have been trained on your data. It just needs to be able to read it at the moment you ask.

Why This Changes Everything for Automation

Every automation I've built so far sends data directly to Claude in the prompt. That works for small, structured inputs.

But what about:

A chatbot that answers questions about a company's entire document library?
A support system that references hundreds of past tickets to resolve new ones?
A report generator that pulls from months of historical data?

You can't paste all of that into a prompt. RAG is how you solve that.

What I Learned Today

The core RAG pipeline:

User query
↓
Search knowledge base for relevant chunks
↓
Pass retrieved chunks + query to LLM
↓
LLM generates response grounded in real data

The builds that are coming next are going to be on a completely different level.

No GitHub link today, just a study day documented publicly.

47 more to go.

rag #ai #learninpublic #buildinpublic #python #claudeapi #100DaysOfCode

Day 12 of 60: I Built the Final Piece That Completes a Full AI Automation Stack (Zero Human Reporting)

Cess Mbugua — Thu, 14 May 2026 19:27:58 +0000

Today I closed the loop.

Every business running automations eventually faces the same question: what actually happened this week? Someone has to pull data from multiple sources, count the records, write a summary, and send it. For one client that's 30 minutes. For ten clients it's half a day. Every single week.

Today I automated that entirely.

*## What I Built
*
A Python script that:

Connects to Airtable and reads all lead records
Sends the data to Claude with a reporting prompt
Receives a clean written summary report back
Saves it as a timestamped .txt file
Prints it to the terminal

The report includes lead counts by urgency, status breakdowns, key highlights, and recommended next actions. No human involved.

Why This Matters: The Full Stack

**
This was Challenge 5 of 5 in Phase 1. Here's what the complete pipeline looks like:

Challenge 4 → Intake comes in
              Raw client text → Claude extracts → Pydantic validates → Airtable stores

Challenge 5 → Report goes out
              Airtable data → Claude analyses → Written report → saved as .txt

Intake in. Report out. No human touches either end.

## The Analogy That Made It Click

Think of a bank branch manager's end-of-day report. The teller system holds every transaction. Every evening a junior manager spends an hour pulling numbers and writing a summary for the regional director.

What I built is the automated equivalent; a script that reads every record, hands them to Claude who writes the summary in plain English, and delivers the report automatically. Same quality. Every day. Zero manual effort.

The junior manager now spends that hour on something that actually requires human judgement.

What I Learned

Phase 1 is complete. Five challenges. Five scripts. One complete automation stack.

The biggest lesson across all five: the most valuable automations aren't the flashy ones; they're the ones that eliminate the invisible repetitive work nobody talks about but everyone does.

🔗 Full project on GitHub → https://github.com/mbuguacessy-glitch

48 more to go.

python #claudeapi #automation #airtable #learninpublic #buildinpublic #100DaysOfCode

Day 11 of 60: I Built a Script That Reads Raw Client Intake Text and Creates Clean CRM Records Automatically

Cess Mbugua — Wed, 13 May 2026 21:02:19 +0000

Every agency hits the same wall. A potential client fills out an intake form. What comes back is a block of unstructured text. Someone has to read it, extract the budget buried in the prose, assess urgency, and manually create a CRM record.

For five clients a week that's an annoyance. For fifty it becomes a part-time job. For a hundred it breaks the business.

So I automated it.

What I Built

A Python script that:

Reads raw intake text exactly as a client types it
Sends it to Claude with a structured extraction prompt
Receives a clean JSON object back
Validates every field with Pydantic
Saves the complete record to Airtable automatically

No human reads the intake. No human creates the CRM entry. A clean lead appears in Airtable ready for follow-up — in seconds.

New Skills This Introduced

Structured extraction prompting
Telling Claude to return only JSON with specific fields, making AI output predictable and parseable.

Pydantic field validation
Catching bad AI output before it corrupts your data, defining exactly what shape the data must be.

@field_validator
Custom rules that fix or reject individual fields e.g. if urgency is not Low/Medium/High, default to Medium.

pyairtable
Writing records to Airtable via API from Python — your CRM integration layer.

glob()
Looping over all files matching a pattern, process 2 intakes or 200 with the same code.

What I Learned

The most valuable thing today wasn't the code, it was the pattern. Unstructured text in. Validated structured data out. Saved to a system of record.

This same pattern applies to support ticket classification, lead qualification, invoice extraction, contract review, and survey analysis. Once you understand it, you can deliver one of the highest-value automations in the market.

🔗 Full project on GitHub → https://github.com/mbuguacessy-glitch

49 more to go.

python #claudeapi #automation #airtable #learninpublic #buildinpublic #100DaysOfCode