I'm building the support tool I kept failing to buy
Inbxer isn't a company. It's me — Abdelmjid, a software engineer and open-source creator building scalable web apps, developer tools and SaaS products. I've spent years watching support conversations scatter across four tools, with context dying somewhere between the customer and the engineer who could actually answer.
The pattern is always the same. A customer writes in about something that looks like a bug. Support asks for context the product already knows. Someone copies the thread into an issue tracker. The fix ships. Nobody tells the customer.
Every helpdesk I evaluated was built for high-volume consumer tickets: fast to close, cheap per contact, indifferent to who was asking. B2B support is the opposite job. You have a handful of named accounts, each with a contract, and the answer usually lives in engineering — not in a macro.
Why open source
Support software reads every message your customers send you. Asking a team to trust that to a closed product they can't inspect never sat right with me. Publishing the code under MIT is the version of that promise you can actually verify — and it means the product outlives whatever I decide to do with it commercially.
Where things stand
Real, running code — not a pitch deck. Conversations, AI agents, the automation engine, and the email, chat widget and Slack channels all work today, and I run this site's own support on the same build. Next up: the public v1 release, with a hosted Cloud version to follow.
Four commitments I can be held to
Just one person, no layers
No support team to hide behind. Every reply and every commit is mine.
Building this in the open
No team, no marketing department — just the repo, the product, and support conversations I handle myself. Star it, open an issue, or just say hi.