Why We Built Our Own GitHub Bot

How a custom Slack-GitHub-Front integration helped our support and engineering teams stay in sync when no out-of-the-box tool could.

At Flatfile, we had a problem.

Our support team was fielding issues from customers using Front — a shared inbox platform that let us handle communication across email, chat, Slack, and more. Engineering, meanwhile, was managing bugs and feature requests in GitHub. Slack was our real-time layer, where both teams lived and breathed.

But despite all that tooling, high-priority issues were getting missed. The loop between support and engineering was broken.

The Bottleneck: Slow Feedback, High Stakes

We'd get a critical bug report from a customer in Front. A support teammate would create a GitHub issue. And then...

Nothing.

Comments in GitHub weren't being seen fast enough. Engineering didn't have visibility into which issues needed urgent attention. Support had no idea when progress was made. The async nature of GitHub wasn't cutting it in the early stages of issue triage.

It became clear: if we didn't close the loop faster, we'd keep missing opportunities to fix the right things at the right time.

Switching to GitHub Projects

At the same time, we made another big change: we moved off Linear and started using GitHub Projects to track engineering work.

GitHub Projects was powerful — especially for customizing workflows with fields and statuses — but it was also new. There were barely any integrations available. And the API was still evolving.

So we were left with:

• A support tool (Front) that didn't talk to GitHub
• An issue tracker (GitHub Projects) with no integrations
• A team that worked out of Slack and needed real-time context

Why Off-the-Shelf Tools Didn't Work

We explored existing solutions. But they weren't built for the way we worked.

Some tools were designed around customer-reported bugs in shared Slack channels. That wasn't us. Our support team triaged issues from multiple customer sources through Front.

Others could connect Slack and GitHub or GitHub and Front — but not all three.

We needed something that could:

• Connect Front, GitHub, and Slack
• Work with GitHub Projects and its custom metadata
• Respect the unique flow of how we operated

Rolling Our Own Bot

That's when we decided to build it ourselves using n8n.

With n8n, we created custom workflows to:

• Trigger issue creation in GitHub from messages in Front
• Automatically notify engineers in Slack when a new issue was created
• Pull in key metadata like priority, customer name, and Front conversation URL
• Let engineers comment in Slack and sync those back to GitHub
• Update statuses and surface changes for support in real-time

n8n made it possible because it didn't care which tools you used. If there was an API, it could connect.

The Results

After we rolled out our custom bot:

• Engineers saw critical issues in minutes, not hours
• Support could track progress without needing to ask
• We missed fewer high-priority bugs and triaged faster
• Everyone had context in the tools they already used

It felt like the glue we didn't know we were missing.

What We Learned

Most integrations are built for narrow use cases. They stop at the surface.

But real-world workflows are messy. They span multiple tools and teams. No off-the-shelf product can anticipate every company's exact needs.

Custom tooling might sound like more work. But in our case, it was the fastest way to actually work how we wanted. We weren't locked into someone else's opinionated workflow. We just connected what we needed.

Want to Build Your Own?

If you're facing a similar disconnect between support and engineering, or if GitHub Projects is your primary issue tracker but feels isolated from the rest of your stack, I've published a free template you can use to get started:

It won't solve everything out of the box (that's kind of the point). But it'll give you the foundation to start building something that does work for your team.