rexlead learning journey
Why I built it
rexlead started from a practical question I kept returning to. If someone landed on my site with a serious project in mind, what should happen next beyond a form submission and a notification in my inbox?
I wanted that handoff to feel intentional. The lead should be captured cleanly, understood in context, routed with some judgment, and reflected in the same system I would actually use to follow up. That turned the project into something more interesting than a portfolio surface. It became a live piece of business infrastructure for my own work in AI systems, workflow automation, and software engineering.
At the same time, I wanted the project to push me into a part of the stack I had not explored deeply in a real production context. HubSpot became the center of that decision. I had seen it from the outside, but I wanted to understand how it behaves when it becomes part of the actual system design. That meant moving past the idea of a CRM integration and into the mechanics of how records, ownership, pipeline state, follow up, and internal logic should fit together.
That combination gave the project its shape early. It had a personal reason to exist, and it had a clear learning edge built into it from the start.
What I set out to learn
My first goal was to understand HubSpot as an engineering dependency rather than a logo in a stack diagram. I wanted to learn how contacts, companies, deals, tasks, notes, owners, and properties fit together in a system that had to keep moving without manual cleanup after every action. That also meant learning where HubSpot should own state and where the application should keep control.
The second goal sat next to that. I wanted to build a system where the LLM layer earned its place through the surrounding engineering. That pushed me toward structured output, auditability, bounded prompts, workflow separation, and a setup where every automated step could be inspected later with real context.
That part became more interesting once I moved beyond a single prompt over the submitted form. The analysis layer can call a small set of tools before it produces the final record. It can fetch the submitted website, crawl a few public pages such as home, about, services, and contact, inspect domain and email signals, and pull existing HubSpot context when a record already exists. That gave the model a better chance of judging fit and seriousness from evidence rather than guesswork.
How the system evolved
The public side began as a service page for my own work. The deeper challenge lived behind that surface. I needed a path from project brief to CRM record to first response that felt consistent under real conditions.
Supabase became the operational memory for the application. It stores leads, analysis records, score outputs, workflow runs, prompt logs, delivery events, and the traces created by the tool calling layer. That gave me a grounded place to inspect what happened at each step.
n8n became the orchestration layer. It sits between intake and side effects, dispatching analysis and routing so the application does not have to carry that whole sequence in a single request. That separation mattered because it made it easier to reason about retries, failures, and visibility.
HubSpot became the external system that turned the project into something real. Once the lead was worth acting on, the system needed to create or update the right records and reflect the result in a CRM that a real operator would already understand.
The tool layer sat between those pieces. Before the final synthesis step, the model could gather a bounded amount of context from the submitted domain and from HubSpot. I kept that loop intentionally small. A few useful tool calls were enough to improve the analysis. A larger loop would have slowed the system and made the output harder to control. That tradeoff taught me a lot about how to make an LLM useful inside an application instead of letting it become the application.
The learning curve
The most valuable part of the project came from the friction.
HubSpot taught me that an integration is never just a token and an API call. It is object relationships, property design, owner identity, pipeline stages, and the constraints of a real account. Each layer forced clearer thinking about what the application should decide and what the CRM should store.
n8n taught me the same lesson from a different direction. A workflow can look correct on paper and still behave poorly when timing, response mode, or chaining strategy are wrong. Working through that made the orchestration more intentional. Intake became short lived. Analysis and routing became separate concerns. Replay became something explicit rather than an afterthought.
The prompting layer had its own curve. Getting a model to produce useful lead analysis was not the hard part. Getting it to produce compact, structured, repeatable output under real limits was the real engineering task. I ended up tightening the evidence passed into synthesis, shrinking the prompt shape, bounding token budgets, and moving to a more reliable compatibility layer for chat completions.
The tool calls added another layer to that learning. Every tool made the analysis more informed, though every extra response also increased latency and prompt size. I had to decide how much website text to keep, how many pages to inspect, how many citations to preserve, and how to compress the evidence before the final synthesis step. That work turned tool usage from a vague feature into a real design problem with performance and reliability consequences.
What the finished shape looks like
Today the project runs as a multi layer system.
A public visitor submits a brief. The app validates and stores it. n8n dispatches analysis. The model produces structured signals and a reply draft. Routing decides what happens next. HubSpot receives the CRM side effects. The system logs each major step. Outbound delivery is branded to match the visual language of the site.
Inside that analysis step, the model first gathers a small evidence pack through tools. It can read the lead website, inspect a few core pages, compare email and domain signals, and check for existing CRM context. Only then does it produce the structured analysis, score inputs, and draft reply. That sequence made the final output feel grounded in something closer to due diligence than a single pass over a text box.
The admin surface remains available so I can inspect runs, understand scores, review the history of a lead, and step through failures with context instead of guesswork.
What I learned from building it
This project made me sharper in a way that small isolated demos never do. It pushed me to work across product design, application code, CRM integration, workflow orchestration, structured prompting, deployment, and operational debugging in one continuous system.
It also reminded me that learning a new platform is most valuable when the work has stakes. rexlead gave me a reason to keep tightening the architecture until it could support a real use case of my own. That made the learning more honest, more technical, and more useful.
Why it matters to me
I want the projects attached to my name to show curiosity backed by execution. rexlead does that for me. It began as a way to learn HubSpot in a serious context. It became a working lead engine that reflects how I like to build: clear layers, visible workflow state, practical use of AI, and a willingness to iterate until the system holds together under real conditions.