Why I built Alex when platforms like Intercom already exist

Alex began with a question I wanted to explore: how much more useful could an AI assistant become if I designed the whole experience around the way my business works?

It was a fun experiment, too. Conversation, animation, application tools, business context, interface design and the handover into real work came together in one project I could keep improving. That curiosity matters. So does the fact that Alex now belongs to both the public experience and the administration software I maintain every day.

I did not need to recreate an entire customer-service platform. I wanted an assistant that felt at home here, did useful work within a clear scope and gave me control over how the pieces fit together.

Fin is a serious product. That makes the choice more interesting.

Intercom’s Fin is far more than a question-and-answer widget. It can work with multiple knowledge sources, follow procedures, take actions in connected systems and hand context to a human team. Multichannel service, analysis and continuous improvement are substantial parts of its offering. It can also work with an existing helpdesk; buying the whole Intercom platform is not the only route. Fin’s capabilities and platform integrations.

For a business with a support operation to organise, those capabilities can be exactly the point. Queues, teammates, channels, reporting and escalation are real work. A mature platform can save you from building and running all of it yourself.

My requirements are different. I am not trying to equip a large support department. I already build and maintain my website and administration tools. I want a focused assistant inside those systems, with an interface and behaviour that I can shape directly.

The model is one part of Alex

OpenAI supplies the model behind the current public chat. The application around it decides what context is available, which tools may be used, what information a visitor can access and how a response becomes a useful next step.

On the website, that means help with services, scope and the project journey. The conversation, suggested links, guided briefing and reviewed form handover belong to the same experience. A visitor can correct their information before submitting it; the assistant does not approve a final quote on my behalf.

The private side has a different purpose. Alex’s administration implementation includes an authorised tool layer, access checks, bounded execution and proposals that can require review. It connects the assistant to operational work instead of giving a public chat unrestricted access to business records. Private capabilities have their own enablement and approval gates; their existence in the application does not make them available to every visitor.

There is engineering in those boundaries: choosing the right context, checking permission again when a tool runs, limiting a run’s cost and keeping consequential actions behind the appropriate review. The model matters. So does everything that makes its output useful in this particular business.

A little personality is part of the product

Alex moves. His greeting and animated states give the conversation a presence that a static chat icon does not. I can design the character, timing, interface and transitions together, so he feels like part of Pitstop rather than a separate service dropped into the corner.

That was part of the pleasure of building him. It is a chance to explore what an assistant can feel like, as well as what it can do. A small moment of character can make a technical website feel more approachable.

The motion still has a job. It should help communicate state, leave the conversation readable and respect reduced-motion preferences. Personality is most effective when it supports the interaction instead of demanding attention from it.

The economics fit my business

For my usage and the scope I need, Alex is significantly cheaper to run than the broader commercial setup I would otherwise be considering. That is my own operating decision, not a universal claim that a custom assistant always costs less.

Fin uses outcome-based pricing, with the chosen helpdesk arrangement and terms affecting the comparison. Alex has model usage, infrastructure and engineering costs. Comparing only an API bill with a platform subscription would miss part of the picture. Fin’s current pricing.

What changes the calculation for me is that the engineering work already belongs to my day-to-day business. I maintain the frontend and administration processes continuously. Alex lives within that work, shares its foundations and improves alongside it. Maintenance is real, but I am not introducing a separate support platform solely to meet a small part of its scope.

I also value being able to change the interface, connect a specific process or test an idea without reshaping the business around a vendor’s product. For this implementation, that combination of lower running cost, direct control and existing maintenance capacity makes the investment justifiable.

An experiment still has to earn its place

The fun part is trying capabilities. The useful part is finding out which ones deserve to stay. I check conversations about budgets, scope, published offers and handovers, including Romanian and English, and I look at whether the next step actually works.

Public guidance, private tools and proposed actions need different tests. An assistant that sounds confident but passes the wrong information to a form has not finished the job. Nor should an animation conceal an error or make a slow response harder to understand.

This is ongoing work, like the rest of the software. Offers change, processes evolve and unexpected questions reveal improvements. I keep ownership of those decisions rather than treating launch as the end of maintenance.

Build what fits. Respect what already works.

I would happily recommend an established product when its capabilities match the problem. Fin is a powerful option, and a company needing a substantial support operation should evaluate it seriously.

Alex makes sense here because the scope, economics and ownership fit. He brings a more personal experience to the website, connects with the software behind it and gives me a practical place to experiment. I get to build something useful, have some fun doing it and keep making it better as part of the business I already run.

Explore our AI and automation work, or read how I weigh a custom AI build against subscriptions. Start with the process you want to improve. Then decide what is worth buying, connecting or building.