There are already plenty of AI assistants.
So why build another one?
That was one of the first questions we had to answer when we started building GabbyAI.
The answer wasn't that the world needed another chat interface with a different logo. It was that we wanted to build an AI platform around a set of engineering principles that mattered to us: infrastructure control, a clean API, predictable products, privacy, and the ability to evolve the technology underneath without rebuilding everything around it.
GabbyAI is our attempt to do that.
The assistant is only the visible part
When most people interact with an AI product, they see a text box.
They type something.
The assistant responds.
Behind that simple interaction is an increasingly complicated collection of systems.
Authentication. Conversation storage. inference infrastructure. Usage metering. Rate limits. subscriptions. API keys. Model management. Monitoring. Billing. Email verification. Session management. Security controls.
And, eventually, multiple models and modalities.
We decided early on that GabbyAI shouldn't be designed as a website that happens to call an AI model.
It should be designed as a platform.
That distinction has influenced almost every architectural decision we've made.
Separating the product from the model
One principle has been particularly important:
The product should not be the model.
Models change.
Hardware changes.
Inference engines improve.
Context windows grow.
New capabilities appear.
If the entire application is tightly coupled to one model implementation, every major model change risks becoming an application migration.
Instead, GabbyAI sits above our SWAI model layer.
From the application's perspective, the important contract is the inference API — not the implementation behind it. Conceptually:
User
│
▼
GabbyAI
│
▼
Swish API
│
├── Authentication
├── Conversations
├── Usage & Limits
├── Billing
├── API Keys
└── Model Routing
│
▼
SWAI Inference
│
▼
Compute Infrastructure
That abstraction gives us room to improve the underlying AI infrastructure without forcing the rest of the platform to understand every change.
It's a fairly ordinary software-engineering principle.
But ordinary principles become surprisingly valuable when applied to AI systems.
Infrastructure matters
Another decision was to retain meaningful control over the infrastructure running the service.
GabbyAI runs on Swish-controlled infrastructure, with the surrounding platform built around services we operate.
That creates more work.
We have to think about deployment, monitoring, capacity, databases, inference performance, failures and upgrades ourselves.
But it also gives us something valuable: control.
We can see how the platform behaves from the API request through to inference.
We can decide how services communicate.
We can change components independently.
And as the platform grows, we aren't forced to treat the most important part of the product as a black box.
PostgreSQL at the centre
We're using PostgreSQL as the primary database platform.
This wasn't a particularly exotic decision — and that's exactly the point.
AI projects have a habit of becoming unnecessarily complicated because every component is treated as an opportunity to introduce another specialised technology.
Sometimes that's justified.
Often it isn't.
For the core application, we wanted something boring, powerful and extremely well understood. PostgreSQL gives us relational data for users, subscriptions, sessions, conversations and operational data while also leaving room for AI-specific functionality where we need it.
Our approach has generally been:
Introduce complexity when the requirement demands it, not because the architecture diagram looks more impressive with another box.
That philosophy has saved us quite a few headaches already.
The API is a first-class product
GabbyAI isn't intended to exist solely through gabbyai.online.
We're building the API as a first-class interface to the platform.
That means thinking about things such as API keys, authentication, usage accounting, model selection, streaming, limits and error behaviour as actual product features rather than implementation details required by the website.
It also forces better architecture.
When your own frontend consumes the same properly defined services that other applications can use, shortcuts become much more obvious.
A feature isn't really finished because a button works.
It's finished when the underlying service behaves correctly.
Streaming changes the experience
One deceptively important part of an AI interface is streaming.
Without it, an application can technically work perfectly while still feeling painfully slow.
A request might take ten seconds and return a complete answer.
Functionally: success.
From the user's perspective: something might be broken. Streaming changes that perception because generation becomes visible as it happens.
For GabbyAI, our chat API therefore supports streamed completions. It creates its own engineering problems — interrupted connections, partial responses, persistence, client state and error handling all become more interesting — but the resulting experience is worth the additional complexity.
Designing for failure
One principle we use elsewhere within Swish has carried over particularly well to GabbyAI:
Servers can fail. Services must not.
Individual machines will eventually disappear.
Processes will crash.
Deployments will go wrong.
Networks will have bad days.
An AI service adds another failure domain because inference itself can become constrained by GPU memory, generation load or model availability.
The goal therefore isn't to create infrastructure that never fails.
That's unrealistic.
The goal is to design the service so individual failures don't automatically become product failures.
We're still building toward that architecture, and there is plenty left to do.
But designing for it now is considerably easier than attempting to bolt resilience onto the platform later.
What we're building next
GabbyAI is already usable, but we're treating the current platform as the beginning rather than the finished product.
The roadmap includes continued improvements to the SWAI model family, developer tooling, API capabilities, infrastructure resilience and eventually additional AI modalities.
There are also plenty of less glamorous engineering projects ahead.
Those are often the interesting ones.
How do you meter AI usage accurately?
How should conversations be stored?
How do you deploy a new model without breaking existing clients?
How do you handle inference capacity?
What happens when a generation stops halfway through?
How do you structure authentication when both humans and applications consume the platform?
Those are the kinds of subjects we'll be writing about here.
Building in public — selectively
We won't publish every internal implementation detail.
Security-sensitive infrastructure and proprietary parts of the SWAI technology obviously need to remain internal.
But there is a large amount we can discuss.
Architecture decisions.
Mistakes.
API design.
Infrastructure lessons.
Performance improvements.
Frontend development.
Deployment problems.
And the inevitable occasions where something that looked simple turned into several hours of debugging.
That's what this DEV account will primarily be about.
GabbyAI is available globally at gabbyai.online, but this blog won't simply be a stream of product announcements.
We want to document what it actually takes to build the platform behind it.
Because building an AI assistant is easy to describe.
Building one that you can operate, evolve and depend on is considerably more interesting.
Welcome to GabbyAI.
GabbyAI is a Swish World Group company, powered by SWAI.