DEV Community: Alejandro Garcia

The Problem I Saw From the Floor, Not From a Laptop

Alejandro Garcia — Fri, 28 Aug 2026 18:58:18 +0000

Why I started building Materia AI before it was anywhere near finished.

There's a specific kind of bad moment that happens on a restaurant floor. A table orders the salmon. You put it in. Ten minutes later the kitchen sends it back — we're out. Now you're the one walking back to that table to explain it, and if you're unlucky, you already told them how good it was.

That moment isn't rare. It happens most shifts, in some form. Not because anyone's bad at their job — the chefs are stretched thin managing inventory in real time, and the news that something ran out almost always breaks in the middle of service, never before it. By the time it reaches the floor, a waiter has usually already offered the thing that's gone.

I've been on that floor for years now, alongside writing code. And after watching that same gap play out shift after shift — the kitchen struggling to track what's left, the waiters left out of the loop until it's already a problem in front of a customer — I stopped seeing it as just part of the job and started seeing it as something I actually knew how to fix.

That's the honest origin of Materia AI. Not a hackathon idea, not a "what if" I dreamed up staring at a blank editor. It's a problem I watched happen in front of me, over and over, from the side of the job most software never gets built by.

Where it actually stands right now

I want to be straight about this instead of dressing it up: Materia AI isn't finished. The backend — the part that takes a menu item and turns it into a real, bilingual description a customer can understand at a glance — works end to end. I've run it, watched it produce something usable, and trusted the pattern enough to build on top of it. The frontend, the actual page someone would click around on, still isn't there yet.

So instead of sitting on it until it's "done" — whatever version of done would've made me comfortable enough to show it — I pulled out the backend piece and put it up on Gumroad. Not as a polished product with a bow on it, but as a working slice of the pattern: the part that actually solves the core problem, available now, while the rest keeps getting built in the open.

The reasoning is simple. If you've watched a version of this same problem happen in your own work — some gap where the people closest to the issue are the last to know about it — you probably don't need to wait for my finished app to go do something about it. You need a working starting point. That's what I put out there.

Why I'm telling it this way

I could've waited to write about Materia AI until it had a homepage, a demo video, the whole thing polished for a launch post. I decided not to, on purpose. The version of this project that's useful to someone else right now isn't the finished one — it's the honest one. The floor-level problem, the working piece that came out of actually solving it, and the rest still in progress.

If you're building something and you're waiting to talk about it until it's "ready," I'd push back on that a little. The interesting part isn't the finished screenshot. It's the moment you noticed the problem was real enough to act on.

I'm continuing to build Materia AI in the open — backend first, frontend next, and I'll keep sharing what that actually looks like as it happens. If you want the working piece of the pattern to start from, it's on Gumroad. And if you're working on something similar, or want another set of hands on a backend/AI integration problem, I'm open to freelance and full-time work — you can find more of what I've built on GitHub.

The AI API Will Fail on You — Here's How I Structure FastAPI to Handle It

Alejandro Garcia — Fri, 28 Aug 2026 17:25:35 +0000

A few weeks ago I was demoing a small FastAPI service that called an LLM to summarize text. Worked great in every test I ran. Then, live, the provider API took almost 9 seconds to respond and my endpoint just... hung. No error, no timeout, just silence while I sat there making small talk to fill the gap.

That was the moment it clicked for me: when you put an AI API behind your own API, you've inherited two sets of failure modes — yours and theirs. Rate limits, timeouts, malformed JSON in the response, the model deciding to add a chatty preamble before the JSON you asked for. None of that is hypothetical. It's Tuesday.

Here's how I've learned to structure a FastAPI backend so that when (not if) the AI call misbehaves, it fails in a way you control.

Don't let the router touch the AI call directly

The most common pattern I see (and the one I used to write) is catching exceptions right inside the endpoint function. It works until you have more than one endpoint calling the model, and suddenly your error handling is copy-pasted five times with five slightly different bugs.

Instead, the router's only job is to receive the request, validate it, and hand it off:

@router.post("/summarize")
async def summarize(payload: SummarizeRequest, service: SummaryService = Depends()):
    result = await service.run(payload)
    return result

All the "what could go wrong" logic lives one layer down, in the service.

Give the AI provider's failures their own exception types

Generic except Exception blocks tell you nothing about why something failed, which makes writing a sane HTTP response back to your client impossible. I define a small hierarchy instead:

class AIProviderError(Exception):
    """Base error for anything the model provider throws at us."""

class AIProviderTimeout(AIProviderError):
    pass

class AIProviderRateLimited(AIProviderError):
    pass

class AIResponseMalformed(AIProviderError):
    """The provider responded, but not with what we asked for."""

The service layer catches the provider SDK's raw exceptions and re-raises them as one of these. A dedicated exception handler at the app level then maps each one to the right HTTP status: 504 for a timeout, 429 for rate limits, 502 when the model's output doesn't parse. Your client gets something actionable instead of a raw 500 and a stack trace.

Never trust the model's output — validate it like a client request

This is the one people skip. We're all trained to validate incoming requests with Pydantic, but the response coming back from the AI is just as untrusted. Models occasionally return almost-JSON, or valid JSON with a field renamed, or an extra sentence wrapped around it.

class SummaryResult(BaseModel):
    summary: str
    key_points: list[str]

def parse_model_output(raw: str) -> SummaryResult:
    try:
        data = json.loads(raw)
        return SummaryResult.model_validate(data)
    except (json.JSONDecodeError, ValidationError) as e:
        raise AIResponseMalformed(str(e)) from e

If it doesn't fit the schema, it doesn't get past this line — full stop. That one function has saved me from shipping garbage data downstream more times than I'd like to admit.

The pattern, not the code

None of this is complicated once you see it laid out, but I didn't see it laid out anywhere when I needed it — I pieced it together across a few projects, mostly the hard way, after enough live demos went sideways. Routers that stay thin, a service layer that owns the provider calls, a typed exception hierarchy, and Pydantic validating both directions instead of just one.

I ended up packaging exactly this structure — routers, services, schemas, and the error-handling layer between your FastAPI app and an AI model — into a small starter template so I'd stop rebuilding it from scratch every time. If you want the full working reference instead of piecing it together yourself, you can grab it here. Worth noting: it's a structural pattern, not a full production app — no JWT auth or database included, on purpose, so it stays easy to read and adapt to whatever you're building.

I'm also currently open to backend/full-stack roles (Python, FastAPI, Flask, AI integrations) and freelance work — feel free to check out more of my code on GitHub.

I Kept Burning API Credits Every Time I Ran My Test Suite — Here's How I Fixed It

Alejandro Garcia — Sat, 22 Aug 2026 21:42:55 +0000

I ran my test suite four times in a row one afternoon while debugging a flaky endpoint, and by the time I checked my OpenAI usage dashboard I'd burned through more credits than I meant to spend that whole week. Nothing had even broken — the tests were just... running, and every single one of them was making a real call to a real model. That's when it clicked that I'd built something that worked, but that I hadn't actually built something I could test cheaply.

If you're building anything backend-heavy on top of an LLM — a FastAPI service, a Flask app, whatever — this is a problem you'll hit eventually. Your tests either hit the real API (slow, costs money, occasionally flaky because the model's response isn't 100% deterministic) or you don't really test the AI-calling parts at all and just cross your fingers in production. Neither is great.

Why this happens

The root cause is usually structural, not a testing problem. If your route handler does something like "receive request → build prompt → call OpenAI → parse response → return," then the only way to test any of that logic is to actually call OpenAI, because the AI call is tangled up with everything else.

The fix is the same one you'd use for any external dependency: pull it out behind its own boundary. In the backend template I put together for my own projects, I split things into three layers — routers, services, and schemas — specifically so the "call the model" part lives in exactly one place and can be swapped out in tests.

A simplified version of that service layer looks something like this:

# services/ai_service.py
from openai import OpenAI

client = OpenAI()

def generate_summary(text: str) -> str:
    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": "Summarize the following text in one sentence."},
            {"role": "user", "content": text},
        ],
    )
    return response.choices[0].message.content

And the router just calls it — it doesn't know or care that there's an API call happening underneath:

# routers/summary.py
from fastapi import APIRouter
from schemas.summary import SummaryRequest, SummaryResponse
from services.ai_service import generate_summary

router = APIRouter()

@router.post("/summarize", response_model=SummaryResponse)
def summarize(payload: SummaryRequest):
    result = generate_summary(payload.text)
    return SummaryResponse(summary=result)

Testing it without spending a cent

Because generate_summary is its own importable function, I can patch it directly in tests instead of hitting the network:

# test_summary.py
from unittest.mock import patch
from fastapi.testclient import TestClient
from main import app

client = TestClient(app)

@patch("routers.summary.generate_summary")def test_summarize_endpoint(mock_generate):
    mock_generate.return_value = "This is a mocked summary."

    response = client.post("/summarize", json={"text": "Some long text here..."})

    assert response.status_code == 200
    assert response.json()["summary"] == "This is a mocked summary."

That test runs in milliseconds, costs nothing, and is fully deterministic — no more "wait, did that test fail because of a bug or because the model phrased it differently this time?"

One gotcha that trips people up here: notice the patch target is routers.summary.generate_summary, not services.ai_service.generate_summary. Since the router does from services.ai_service import generate_summary, it holds its own local reference to that function — patching the original module doesn't touch it. The rule of thumb with unittest.mock is to always patch where the name is used, not where it's defined.

I also like adding one or two tests that check what happens when the AI call fails — timeout, rate limit, malformed response — since that's the stuff that actually breaks in production and almost never gets tested:

@patch("routers.summary.generate_summary")def test_summarize_handles_upstream_error(mock_generate):
    mock_generate.side_effect = Exception("upstream timeout")

    response = client.post("/summarize", json={"text": "..."})

    assert response.status_code == 500

None of this is exotic — it's the same mocking pattern you'd use for any third-party API. The only real "trick" is disciplined separation: keep the model call in its own service function, keep validation in Pydantic schemas, and keep the router thin. Once that boundary exists, testing (and later, swapping providers, adding caching, adding retries) gets a lot less painful.

This is basically the skeleton I now reuse every time I start a new FastAPI + AI project, so I packaged it as a small starter template — routers/services/schemas separated like above, Pydantic validation, and consistent error handling baked in from the start. It intentionally does not include auth or a database, since those tend to be project-specific and I'd rather hand you a clean pattern than force my opinions on you there. If that'd save you some setup time, you can grab it here.

I'm also currently open to freelance and full-time backend/fullstack work (Python, FastAPI, Flask, AI integrations) — if you're hiring or know someone who is, my code is at github.com/GerAle30.

What I Learned Turning a Side Project Into a Sellable Dev Tool

Alejandro Garcia — Mon, 17 Aug 2026 17:00:35 +0000

I built Materia AI to solve a real problem I saw firsthand — messy menu and inventory management from my years working as a waiter. It's still growing. But somewhere along the way, I realized the backend pattern I kept reusing — the FastAPI structure, the AI service layer — was useful on its own, separate from the specific product.

So I pulled it out and packaged it. Here's what that process actually taught me.

Cutting scope until it's honest

My first instinct was to make the package look impressive — throw in auth, a database layer, the works. Then I stopped and asked: does the code actually have that? It didn't. So I cut the description down to exactly what exists, nothing more. It felt like a downgrade in the moment. It's actually the only version I'd feel fine standing behind if someone asked for a refund.

Writing the README for a stranger, not for future-me

My own project notes assume I remember context. A README for someone who's never seen the code needs to explain why, not just what — why routers stay thin, why the AI call lives in its own service, why the response gets parsed defensively instead of trusted blindly. Writing that down clarified my own thinking more than I expected.

The code isn't the product — the packaging is

Anyone could write similar FastAPI code in an afternoon. What they're actually paying for is not having to make the fifty small decisions I already made and documented. That reframing changed how I wrote everything, from the file structure down to the comments.

Starting cheap on purpose

I priced it low to start. Not because the pattern isn't worth more, but because the real goal right now is learning what resonates before optimizing for revenue. Feedback first, pricing later.

None of this is groundbreaking business advice. It's just what actually happened, in order, the first time I tried it.

If you want to see what came out of it, it's here.

I'm a backend developer working in Python, FastAPI, and AI integrations, currently open to freelance work — find me on GitHub.

How I Actually Use Claude as a Backend Engineer 🤖

Alejandro Garcia — Thu, 13 Aug 2026 22:47:44 +0000

For a while, I treated Claude like a fancy autocomplete — ask a question, paste the answer, move on. That approach worked, but it wasn't until I slowed down and treated it more like a thinking partner that things actually clicked for my day-to-day backend work.

The Mistake Most People Make 🙈

The biggest mistake I see (and made myself) is asking for a finished answer instead of walking through the problem. When I just say "write me a FastAPI endpoint," I get generic code. When I explain the actual constraint — the schema, the edge case, why the last approach broke — I get something I can actually ship.

Three Small Habits That Made a Big Difference ✨

💬 Give context before you give instructions. A couple sentences about your stack and goal changes the quality of the output completely.

🧠 Ask it to explain its reasoning, not just produce code. If I don't understand why a fix works, I ask before I merge it.

🔁 Treat the first answer as a draft. The second or third pass, after pushing back with more detail, is usually the one that ends up in production.

Claude vs. Gemini: My Honest, No-Hype Take ⚖️

I've used both, and I'll skip the hype. For backend work — API design, debugging tricky logic, reasoning through a schema — Claude has been more consistent for me, especially on longer, multi-step problems where it keeps track of what we already decided a few messages back. Gemini has its strengths too, particularly when I need something wired up quickly, but for the kind of careful, back-and-forth problem solving backend work usually needs, Claude is what I reach for first.

Why This Matters Beyond Just Being Productive 🌱

This isn't about writing less code — it's about spending less time stuck and more time building. As a freelancer, that difference shows up directly in what I can deliver to clients and how fast I can do it.

What's Next 🚀

I'm continuing to build with Claude in the loop on real client projects, and I'll keep sharing what actually works (and what doesn't) as I go.

👉 Check out my work and get in touch here: Upwork profile

Building My First AI Agent with Python and Flask: What I Learned

Alejandro Garcia — Tue, 11 Aug 2026 02:10:59 +0000

Before I became a developer, I worked as a waiter for over 6 years. And if there's one thing I saw repeat itself over and over during that time, it was how poorly managed menus and inventory are in most restaurants: dishes kept being sold without available ingredients, food waste from lack of stock visibility, and menu decisions made on gut feeling instead of real data.

When I started coding, that experience stuck with me. I knew I wanted to build something that tackled this exact problem, and AI seemed like the perfect tool to help restaurants make better decisions about their menu and inventory in real time. That's how Materia AI was born, and in this post I'll walk you through how I built the first version of the agent using Python and Flask.

The stack I chose

For the backend I used Flask, mainly because I wanted something lightweight and fast to iterate on while I was still figuring out the business logic. I didn't need the full structure of Django, and I wanted direct control over each endpoint while experimenting with the AI integration.

For the AI piece, I connected the backend to a language model that analyzes sales and inventory patterns, and generates recommendations (for example, which dishes to adjust or pull from the menu based on available stock).

The basic architecture

The flow is simple but effective:

Frontend (React) -> Flask Endpoint (/api/analyze) -> AI API call -> Response processing -> JSON with recommendations -> Frontend

The core code

Here's a simplified example of the endpoint that receives inventory and sales data, and returns AI-generated recommendations:

from flask import Flask, request, jsonify
import os
from openai import OpenAI

app = Flask(__name__)
client = OpenAI(api_key=os.environ.get("OPENAI_API_KEY"))

@app.route("/api/analyze", methods=["POST"])
def analyze_inventory():
    data = request.json
    menu_items = data.get("menu_items")
    inventory = data.get("inventory")

    prompt = f"""
    Analyze the following menu and available inventory.
    Menu: {menu_items}
    Inventory: {inventory}
    Suggest which dishes should be paused due to missing ingredients
    and which products are at risk of being wasted.
    """

    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}]
    )

    return jsonify({"recommendation": response.choices[0].message.content})

if __name__ == "__main__":
    app.run(debug=True)

The challenges I ran into

Not everything was smooth. I had to solve a few real problems along the way: how to structure the prompt so the AI returned consistent, useful responses instead of generic text, how to handle API rate limits without the app crashing, and how to store the API key securely using environment variables instead of hardcoding it.

Connecting it to the fullstack side

As a fullstack developer, I didn't want this to stay only on the backend. On the React side, a simple example of how this endpoint gets consumed would look like this:

async function getRecommendation(menuItems, inventory) {
  const response = await fetch("/api/analyze", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ menu_items: menuItems, inventory: inventory }),
  });
  const data = await response.json();
  return data.recommendation;
}

What I learned

Building this taught me three key things. First, the best motivation for a technical project almost always comes from a real problem you lived close to. Second, integrating AI into an app isn't just about calling an API, it's about designing the prompt carefully and handling errors with care. And third, coming from a waiter role gave me an advantage I didn't expect: I understood the business problem better than many developers who've never been on the other side of the counter.

If you work in the restaurant industry, or something similar happened to you in another field, I'd love to hear about it in the comments. And if you want to check out more of my projects, you can find me on GitHub: https://github.com/GerAle30