TRAMA AI, Corp.

AI agent on WhatsApp that runs inventory and operations for mid-size textile companies. Live in production with a paying customer — real-time inventory, orders and FIFO dispatch, no ERP needed.

Comment 1

"It started with a sale that should never have been lost."

Inspiration

Luis Reyes, owner of a custom software development company and a cloud specialist. Gian Castro, engineer, analyst and data scientist. Johan Burgos, a developer with more than seven years of building technology. Three people with jobs, with commitments, with lives that don't pause. And all three with the same question: why not us?

The initial answer wasn't "let's transform the textile industry." It was something more honest: we want to enter a real competition, try to win, and learn what you only learn by competing. Trama started as a bet, not a master plan.

Then Fibrax happened.

Fibrax is a textile distributor based in Barranquilla, Colombia, with commercial presence across the country and roughly 300 active clients. When we sat down with them to understand their operation, what we found wasn't the generic problem of a company that "needs to digitize." It was something far more concrete, more urgent, and more painful.

Fibrax has sales representatives spread across Colombia. When a rep is standing in front of a client, he offers fabrics from memory: the designs he remembers seeing, the colors he believes still exist, the meters he assumes are left. Not because he's careless, but because there was no fast way to know, in real time, what was actually available in the warehouse. The rep sells on assumptions.

The order reaches the office. The administrative team checks it against real inventory — recorded in a platform so old that replacing it had become a declared emergency — and discovers that one, several, or all of the designs aren't available. Then someone has to call the client. Explain. Offer a partial sale. And in the worst case, the client doesn't come back. Or worse: they find another supplier who sells them everything, complete, in a single call.

With 300 clients at stake, losing sales for lack of visibility isn't a minor operational issue. It's a silent business leak that happens every single day.

And there was a second problem, quieter and more expensive: every fabric roll arrives with a nominal length on the invoice (50m), but almost never measures exactly that. Across thousands of rolls a year, the difference accumulates into inventory that exists on paper but not in the warehouse — inventory that Colombia's tax authority (DIAN) expects Fibrax to pay taxes on. Our estimate with them: on the order of COP 100 million a year in phantom tax exposure.

That was the moment the hackathon bet turned into something else. This was a real problem that goes beyond Fibrax — it exists in every textile distributor in the country. That's where Trama became a serious project.

What it does

Trama is a multi-tenant B2B SaaS platform built specifically for textile distributors in Latin America. It replaces the fragmented combination of obsolete systems, WhatsApp groups and manual processes that most distributors run on today.

At its core, Trama manages the complete lifecycle of a fabric roll: from the moment it leaves a supplier's warehouse to the moment it's sold and dispatched.

  • Pre-Arrival — When a container is in transit, AI automatically reconciles the supplier's packing list against the commercial invoice. Every discrepancy surfaces before the container is opened. This module directly attacks the phantom-inventory problem.
  • Warehouse Control — Every roll is inspected, graded by quality (A or B) and labeled with a unique code. From that moment on, each roll has a digital identity.
  • Stock & Rolls — Real-time visibility for the entire sales team, wherever they are in the country. No phone calls. No assumptions.
  • Reservations & Dispatch — A rep reserves a roll, the warehouse confirms it exists, and dispatch is recorded with full traceability.
  • WhatsApp Agent — Running on Gemini 2.5 Flash Lite, the agent understands natural-language queries — "how many meters of Roma Plus do we have available?" — and answers with live inventory data, directly inside the chat the team already uses. A rep can create a full reservation over WhatsApp without ever opening the platform.

Every decision the agent makes is written to a table called agent_log, creating a complete audit trail of AI-executed actions in production.

How we built it

We started with Python. Then we threw it out.

But before the stack, the team.

Luis, Gian and Johan were the three technical co-founders. They had the skills. What they didn't have was someone keeping the chaos organized while everyone ran in parallel with their day jobs. That's when Najem Nabhan joined: technology enthusiast, product-minded, and willing to take on the challenge not as a distant PM but as a fourth builder who understands every decision the team makes.

Four people. Four day jobs. One product to build at night.

Since June 2026, the team met on a fixed schedule: Saturdays, 9pm to 5am. Snacks on the desk, screens on, Linear open, team chat live. During the week, two late-night hours — 10pm to midnight — were the baseline rhythm.

Validation sessions with Fibrax happened on weekday afternoons, 1pm to 4pm — exactly when every team member had commitments to their employers. Gian ended up attending his own work meetings virtually while physically standing in Fibrax's offices. Not as an exception: as a constant.

On the technical side, the most important decision wasn't choosing the stack — it was abandoning the first one. For the first weeks the backend ran on FastAPI and Python. But the complexity of the domain made it clear that a unified team needed a single language across the entire monorepo.

Decision D-001 in our formal architecture record: migrate to NestJS and TypeScript end to end. It cost a sprint. It saved months.

The stack in production today: Next.js · NestJS · TypeScript · Drizzle ORM · PostgreSQL on Google Cloud SQL · Google Cloud Storage · Google Cloud Run across three environments (Dev, QA, Production) with CI/CD automated by semantic tag, Docker images in Artifact Registry, and Workload Identity so the pipeline authenticates to GCP without static credentials.

AI is integrated into two real flows: WhatsApp intent classification (Gemini determines whether the rep is asking about stock, creating a reservation, or making a general query) and structured extraction from supplier PDFs (Gemini reads packing lists and invoices, extracts data roll by roll, and feeds the Pre-Arrival reconciliation engine).

The data model has 29 tables across 9 architectural layers. Every decision from D-001 to D-012 is documented in the team's knowledge base.

Challenges we ran into

The hardest problems were never the ones we anticipated.

We almost died from the wrong prices. One of the team's first real crises wasn't technical — it was financial. Our initial cost estimates for the Fibrax deployment didn't sustain the operation. We had to recalculate the cost structure from scratch and redefine the model before there was a signed agreement.

Fibrax had no way to pay on foreign platforms. Getting the client able to pay us through Stripe turned out to be an unexpected obstacle. Solving the collection logistics took weeks and required creativity.

The PDF problem. Supplier invoices are frequently scanned documents — images disguised as PDFs. We had to build a preprocessing layer to detect document quality and handle extraction failures without breaking a reconciliation the warehouse team was waiting on.

Gemini quota limits in production. Concurrent requests while reconciling a full container hit rate limits we hadn't projected. We redesigned the pipeline to process in controlled batches with exponential backoff.

FIFO with fabric. The same design can carry three different purchase prices across three different containers, each with rolls of different lengths. FIFO valuation in this context forced us to redesign the costing layer twice before it matched what the accountant expected.

Building with a real client, on their real time. Angie, the key Fibrax user in the warehouse, doesn't have scheduled hours to test software: she has containers to open and orders to dispatch. Every validation session had to count.

Accomplishments that we're proud of

We shipped a product. A real one.

Not a demo. Not a staging environment with synthetic data. Fibrax is using Trama in production: real inventory, real rolls, real sales team. A Colombian textile distributor replaced its obsolete system with a platform that gives its nationwide sales force real-time inventory visibility, and a WhatsApp agent its team actually uses.

The Pre-Arrival module is processing real containers and catching real discrepancies. The tax exposure that started this whole project is being resolved, roll by roll.

We went from zero to a production-ready multi-tenant SaaS in under three months, with a team that never stopped holding day jobs, that built at night and on Saturdays, and that found a way through every obstacle without pausing.

  • The architecture is documented in 12 formal decision records
  • The AI agent logs every decision it makes
  • The deployment pipeline runs automatically on every versioned release
  • Gemini is at the center — not as a feature bolted on at the end to qualify for a prize, but as the operating brain of two flows the product cannot function without

What we learned

We learned that the domain always wins.

You can have the best architecture, the cleanest code, the most powerful AI model — and none of it matters if you don't deeply understand the physical reality of a fabric roll moving through a warehouse. We spent more time on the floor of Fibrax's warehouse, watching Angie open boxes and stick labels, than reading documentation. That time was not wasted.

We learned that TypeScript monorepos and multi-tenancy don't forgive shortcuts. Every assumption about data isolation, role boundaries and permission inheritance eventually showed up as a production bug. Our RBAC architecture went through three major revisions before it correctly reflected how a textile business actually operates.

We learned what Gemini is genuinely good at — and where it needs help. Structured extraction from clean PDFs: exceptional. Ambiguous natural language in Colombian Spanish with textile slang: surprisingly good. Scanned documents with inconsistent quality: needs a preprocessor, not more prompting.

We learned that business models get calculated twice: once before talking to the client, and once after reality corrects them. The first version almost cost us the project.

And we learned that building for Latin American SMBs means building for people who will never read a user manual. Every interaction — from the warehouse label to the WhatsApp reply — had to be obvious on first contact.

What's next for Trama

Fibrax's problem is not exclusive to Fibrax.

Across Latin America, thousands of textile distributors run their operations on obsolete systems, WhatsApp threads and institutional memory. The sales force sells without knowing what's in stock. Compliance risk stays invisible until it isn't.

Trama's next step is a second client — already in preliminary conversation — to prove the multi-tenant architecture works not just technically, but commercially.

Beyond client growth, the roadmap is driven by what Fibrax itself told us they still need:

  • Electronic invoicing integrated with the DIAN regulatory framework
  • Role-based reporting — the warehouse lead, the commercial director and the sales rep need completely different views of the same data
  • Receivables management to close the loop between sales and collections

The goal isn't to build another ERP. The goal is to build the operating system a Latin American textile distributor actually uses — one that adapts to how they already work, talks to them where they already are, and makes the invisible visible.

Ecosystem & tooling

Trama isn't only the product the client sees. Behind it is an ecosystem of tools, infrastructure and process that lets four people operate with the discipline of a much larger team.

The anchor is tramai.io. The domain is managed in Cloudflare and is the root identity connecting every tool: GitHub, Google Workspace, Notion, Linear, Slack, Stripe, GCP, Cloudflare and Vercel all authenticate under it. If the domain goes down, everything goes down — so it has an explicit owner and proactive renewal monitoring.

Code — GitHub. The Trama-AI-C-Corp organization hosts the main monorepo under decision D-008. A single private repository holds all three product services: apps/web (Next.js), apps/api (NestJS) and apps/whatsapp-agent. Strategy is trunk-based: one main branch, no long-lived branches. Deploys are driven by semantic tags — *-rc triggers QA, vX.Y.Z triggers Production.

Infrastructure — Google Cloud Platform. All production infrastructure runs on GCP, managed as code through the deploy.yml pipeline in GitHub Actions. Choosing Cloud Run over VMs or Kubernetes was deliberate (D-002): serverless, scale to zero, no infra management — the right model for an early-stage startup.

  • Cloud Run — three independent services (api, web, whatsapp-agent) with separate instances per environment
  • Cloud SQL — PostgreSQL, dedicated instance per environment. ACID transactions are required for FIFO, concurrent reservations and multi-tenant isolation
  • Cloud Storage — supplier PDFs (packing lists, commercial invoices) that the AI pipeline processes roll by roll
  • Artifact Registry — Docker image registry feeding every Cloud Run deploy
  • Workload Identity — CI/CD authenticates to GCP without static credentials. The Drizzle migration job runs automatically on every deploy before traffic is served

Documentation — Notion. Notion is Trama's documentary brain, under one non-negotiable rule: if it isn't documented here, it doesn't exist as a process. The workspace spans Company DNA, Operations, People & Onboarding, Product, Engineering, Marketing, Go-to-Market, Legal & Finance, and Strategy & OKRs — including every architecture decision from D-001 to D-012, and notes from every team and client meeting.

Engineering management — Linear. User stories, bugs and spikes live in Linear under the TRA- identifier. At the close of this submission sprint the backlog is past TRA-340. Team rule: every story must exist in Linear (operational) and in Notion (documentary).

Communication — Google Workspace + Slack. Team email runs on Google Workspace under tramai.io. Slack is the daily channel — the workspace where everything from the first bet to the first production deploy was coordinated.

Payments and legal entity — Stripe + Stripe Atlas. Trama AI, Corp. is a Delaware C-Corporation, incorporated on June 4, 2026 through Stripe Atlas. The same platform that formed the entity processes the product's payments — Stripe handles B2B subscriptions across three active plans (Starter $299/mo, Grow $599/mo, Scale $1,199/mo) plus custom Enterprise. The billing webhook runs at api.tramai.io/api/v1/billing/webhook and every Stripe event updates subscription state in real time in the subscriptions table.

WhatsApp agent — Meta Business API. The WhatsApp integration runs through the Meta WhatsApp Business API. Inbound webhooks are registered at api.tramai.io/api/v1/whatsapp/webhook and every incoming message is verified with HMAC-SHA256 before processing. The wa_channels table resolves workspaceId from phone_number_id — the mechanism that makes multi-tenant architecture possible over a single WhatsApp number per environment.

Finance — Xero. Business accounting runs in Xero as the financial source of truth for the legal entity.

Files and context — Google Drive. Drive holds working documents and reference files: real Fibrax invoices and packing lists used to validate the reconciliation engine, CTO technical review reports, the tech stack evaluation, session templates and presentations. Those Fibrax PDFs were the primary source for validating the Gemini pipeline before taking it to production.

To scale this, Trama is open to conversations with investors who see what we see: that Fibrax's problem isn't Colombian or Latin American — it's the same problem hundreds of thousands of distributors face in emerging markets worldwide. The right capital accelerates the path, but the direction is already set.

Trama started as a bet between three people. It became a real product because the problem was real. And it will keep going because an entire industry still operates as if time had stopped.

Built With

Share this project:

Updates

posted an update —

The moment you stop trusting your own architecture is the moment you know you're building something real.

I'm the CTO of Trama, and my job lives in the distance between what the product needs to do and what the code actually does. In practice: a TypeScript monorepo with a NestJS API, a Next.js dashboard, and a WhatsApp agent, all multi-tenant from day one — because a roll of fabric belonging to one client can never appear in another's inventory. Strict validation on every input. Audit logs on every mutation. I made most of those decisions in a kitchen at 1am, knowing they would either save us later or cost us later. There's no middle option at that hour.

The hardest decision wasn't a feature. It was treating multi-tenancy as a hard constraint, not a future consideration. Every database query filters by workspace. Every API guard checks who is asking before it checks what they're asking for. We have a client live in production right now, and the thing I'm most proud of is that I know exactly where their data ends and where the next client's will begin. That certainty doesn't come for free — it cost weeks of design before we wrote the first endpoint, weeks when everyone else was pushing for visible progress.

What I underestimated was the gap between a working demo and a system a real company can trust with real inventory. Gemini processes incoming fabric shipments: the AI reads a commercial invoice and a packing list, finds the discrepancies, and flags what needs human review before a single roll enters the warehouse. That flow works. But "it works" is not enough when a missed discrepancy means a client sells stock they don't actually have. So we built quality flags, approval gates, and an audit trail that records who did what and when — because accountability is part of the product, not a feature you add later.

The thing I didn't anticipate: running in production showed me that every architectural shortcut we didn't take was a problem we didn't have at 3am. And every place we said "we'll clean that up later" was a Saturday we spent cleaning instead of building. I'm a co-founder with a day job, building at night. Every hour has a real cost. Writing code you trust the first time is not perfectionism — it's the only form of efficiency that actually compounds.

I don't know what happens after this submission. What I know is that the system we built can handle more clients, more industries, more countries — without rewriting the core. That's what I came here to prove.

Gianfranco Castro Co-founder & CTO, TRAMA AI, Corp.

Log in or sign up for Devpost to join the conversation.

posted an update —

A team of four people building at night can't afford a release that needs someone awake to babysit it. My job at Trama is to make sure the pipeline is the one teammate that never sleeps.

I'm the DevOps side of Trama, and what I own is everything between "the code is written" and "the client is using it." Three services — the API, the web app and the WhatsApp agent — running on Google Cloud Run across three environments, each with its own PostgreSQL instance on Cloud SQL. Docker images built and pushed to Artifact Registry on every release. Database migrations that run as their own job and have to finish before a single request reaches the new version. And a pipeline that authenticates to Google Cloud through Workload Identity, so there is not one static credential sitting in a secret anywhere. Deploys are driven by tags: a release candidate goes to QA, a clean semantic version goes to Production behind an approval gate. Nobody deploys by hand. Not once.

What I learned this cycle is that infrastructure is a people problem wearing a technical costume. We're four co-founders with day jobs, meeting on Saturdays from 9pm to 5am. Every manual step in a release is a step that eventually happens at 3am by whoever is still conscious, and that's where outages come from. So the rule became: if it has to be remembered, it has to be automated. Trunk-based development, one main branch, no long-lived branches, protection rules that make it impossible to push straight to production. Not because I love process, but because process is what keeps a tired team from making an irreversible mistake on someone else's live inventory.

The hardest moment was a deploy that succeeded at nothing. Trying to make the pipeline faster, I removed a redundant validation step — and the change quietly left the deploy job in a "skipped" state. Every check was green. Every commit merged. And nothing had actually shipped to Dev for longer than I want to admit, because a pipeline that does nothing looks exactly like a pipeline that works. I've never forgotten the lesson: a pipeline that fails loudly is a gift, and a pipeline that fails silently is a liability. We put the redundant step back on purpose, with a comment explaining why, so the next person doesn't repeat my optimization.

The infrastructure our client depends on today is running real containers, real rolls and real orders. That's the part I'm proud of — not that it's clever, but that it's boring, repeatable, and it comes back up. If you see something in it that would break at scale, tell us. I'd much rather hear it here than at 3am.

Johan Sebastian Burgos Guerrero Co-founder & DevOps, TRAMA AI, Corp.

Log in or sign up for Devpost to join the conversation.

posted an update —

Most products don't fail because someone wrote bad code. They fail because four people heard the same sentence and understood four different things. My job at Trama is to make sure that never happens to us.

I'm the COO, and I live on two fronts. Outside, I handle the relationship with our first client: walking them through the product, collecting what they need and what they hate, and keeping what we promised aligned with what we can deliver. Inside, I turn that into something buildable. User stories, tickets that carry real business context and not just a technical spec, decisions written down. I also built our landing page, because for a company incorporated a few months ago, the first page someone sees is the difference between looking like a real company and looking like four guys with an idea.

What I learned this cycle is how wide the gap is between what a company tells you it needs and how it actually works. Our client moves rolls of fabric measured by hand. Their inventory lives in a spreadsheet, in someone's memory, and on a sticker on a roll. Three versions of the truth, and none of them current. That never came out of a requirements meeting. It came out of the files they sent, the questions they asked, and the corrections after every demo. My work was to catch those signals and rewrite the stories before the team built the wrong thing.

The hardest moment was refusing to demo the happy path. Days before submission I ran a full walkthrough of our QA environment while our CTO attacked the product from a restricted account, and we found fifteen real problems in ninety minutes. It would have been far more comfortable to show the demo that works, but a product that only survives the path you rehearsed isn't a product, it's a presentation. We fixed QA first and shipped to production after. That is what I want Trama to be known for.

This submission is a starting line, not a finish line. Look at what we built and tell us where it breaks. We'd rather hear it from you now than from our next customer later.

Najem Nabhan Chief Operating Officer, TRAMA AI, Corp.

Log in or sign up for Devpost to join the conversation.

posted an update —

I've spent twelve years in technology in Colombia. I built a software development company that helped drive real digital transformation in my country, and along the way I learned what it takes to position a company in Latin America — the resistance, the long sales cycles, the constant work of earning trust.

For years I've wanted to take the next step: to build something with global reach. Not a service business, but a product that could travel, that could help people in a specific industry become more powerful through technology. Trama is that attempt, and this hackathon is where the mission started.

Trama begins with a problem that is unglamorous and urgent: companies don't actually know what they have in the warehouse. Sales teams sell what they assume is there, not what is there, because the processes that produce that information are slow and never real-time. Hardware distributors, metal suppliers, textile companies — the same gap, across industries. We want any company to be able to sell what it truly has, without delays, without long processes, without excuses. My team and I are building the automation layer that makes that possible.

The hardest part of this cycle wasn't technical. It was convincing a local client to work with a newly incorporated U.S. corporation with no track record. We closed it. Then we couldn't collect it in time, because the client's own banking constraints wouldn't allow a card payment. That was a difficult lesson in cross-border operations, and one we're now solving properly.

We didn't give up, and this is only the beginning. Whatever the outcome of this submission, we've gained something harder to measure than revenue: the conviction that this is possible. If we can create real value for one company, we can extend it to everyone who needs it.

Luis Carlos Reyes Vanegas Founder & CEO, TRAMA AI, Corp.

Log in or sign up for Devpost to join the conversation.

Submission history