AaronFounder & architect
Why We Exist
Chat looks like a feature.Until your team has to own it.
I'm Aaron, ChatKitty's founder and an engineer. I started ChatKitty because teams shouldn't have to choose between a chat API hosted outside of their control and building one from scratch.
Today, Kevin and I work directly with marketplace and community teams. We deploy ChatKitty in your cloud environment, connect it to the application you already have, and hand over a system your engineers can understand and run.
Work directly with the engineersRuns in your cloudToronto, Canada
Fit→Build→Handoff
Teams that have built with ChatKitty include
Selia YC W22PrivateAutoInnagoKasper
“Your users see the conversation. Your team inherits everything beneath it.”
The false choice
Build the whole platform, or rent the whole dependency.
The chat box is usually not the hard part. Real work starts when messaging must behave like a dependable part of your product—inside the authentication model, permissions, workflows, interface, and infrastructure you already operate.
Building that layer from scratch gives a team control, but it also creates a new platform to design, test, monitor, upgrade, and support. A hosted API removes the first burden, but can replace it with a long-term dependency on another company's cloud, limits, pricing, and roadmap.
ChatKitty is a third way: keep control of the product and deployment boundary, while reusing a messaging core that has already done the invisible work.
AuthenticationPermissionsDeliveryUnread stateModerationOperations
The ChatKitty story
The product changed as the problem became clearer.
ChatKitty began as messaging infrastructure for our own social product. Years of operating it for customer applications showed that reliable chat depends as much on integration, ownership, and support as it does on the messaging engine.
ChatKitty began inside our own product.
While building a social product, Aaron needed messaging that could work as part of a real product. He built the underlying system, then turned it into ChatKitty when other product teams faced the same problem.
The platform proved the core — and the limits of our model.
Supporting live customer products brought the difficult requirements into focus: user identity, permissions, unread state, reconnects, moderation, migrations, server capacity, upgrades, and dependable support.
The proven core now runs in your cloud.
ChatKitty now ships as a versioned container for infrastructure you control. You work directly with the engineers who build and support it and receive clear documentation for deployment, operation, and handoff.
Who you work with
Two engineers. One clear line of accountability.
There is no sales-to-engineering handoff. Aaron leads every engagement from product fit through architecture and remains accountable for the result. Kevin joins the implementation work, helping turn the agreed design into tested code and a clear handoff. Material decisions and operating steps are documented as the work happens, so your team receives both working software and the context to operate it.
Building ChatKitty since 2020Founder & Technical Lead
Aaron
ChatKitty began when Aaron built messaging for Howdi, a social product for university communities. What started as an internal system became the product he has maintained and evolved since 2020.
With more than a decade of hands-on work across web, mobile, backend, and cloud systems, Aaron leads product fit, architecture, deployment design, and the responsibility boundaries that keep each engagement focused and supportable.
- Product fit
- Architecture
- Accountability
Joined ChatKitty in 2025Full-stack implementation engineer
Kevin
Kevin first worked with ChatKitty in 2025, working across its client, backend, and reliability layers.
He adapted ChatKitty for iOS, Android, and embedded web use; extended its Vue and Spring systems; and strengthened reliability with concurrency safeguards and automated integration tests. Today, he helps turn architecture into tested integration code and handoff documentation your team can understand and operate.
- Integration
- Verification
- Handoff
How the work stays dependableDirect ownership. Documented systems.
Direct engineering contact
You work with the engineers responsible for the architecture and implementation—not a sales team translating the problem later.
A visible ownership boundary
Your application remains the source of truth. The infrastructure, data, and operating boundary are explicit. Responsibilities and limits are written down.
Documented continuity
Architecture decisions, configuration, acceptance criteria, runbooks, responsibilities, and support limits are documented so the system does not depend on private context.
Talk to the engineers who will own the work
Bring the use case.
Your first call is with Aaron, who leads the work from technical fit through acceptance. If ChatKitty fits, Kevin joins implementation planning and delivery. You'll leave with a clear recommendation, and if we are not the right fit, we'll say so.
01
Start with the product. Who the chat users are, what the workflow must accomplish, and why it matters now.
02
Map the technical reality. We review your platform, infrastructure, data, security, and who will operate what.
03
Leave with a decision. Standard sprint, architecture first, a larger custom engagement, or an honest no.