Octopus: how Seapoint ships customer requests in 24 hours

A bug was spotted on our reporting page: opening a vendor's details collapsed rows that had just been expanded. Four hours later, the fix was merged and reached production the next day.

Not long ago, a ticket like this could have sat in our to-do column for months, but since building Octopus tickets now rarely go amiss. Here’s the story behind Octopus, how it works and how it’s changed the way Seapoint’s engineering team operates.

Why we built it: shipped features never stopped needing work

In Seapoint's early days, an engineer would build something, spend a sprint or two on it and move on to the next project. But shipped features keep generating work: bugs, small fixes and countless requests.

Those tickets went to whoever built the feature in the first place, but with tight deadlines on new projects, it’s easy for priority to shift from updating shipped features to building new ones.

Say, for example, if an engineer had built a dashboard, any tickets regarding the dashboard would be sent their way since they knew best. But when the engineer starts working on a payroll feature, any dashboard tickets quickly fall under the radar.

Next we tried a weekly on-call rotation, with one engineer clearing those tickets each week. That didn't work either. There were simply too many tickets, and a week on call wasn't enough structure to get them moving fast.

The result was a conveyor belt that stopped at to-do. Product would triage a ticket and move it there, and progress would grind to a halt. Product had no visibility either. They didn't know whether a fix had been merged, whether it was in production, or when to get back to the customer.

So we set a goal of fixing 75% of customer requests within seven days. Hitting that meant automating the work nobody owned.

How Octopus works

Octopus is the orchestrator that keeps the conveyor belt moving. I chose the name because an octopus has plenty of tentacles, reaches far and moves many things at once.

It works alongside the SCA – Seapoint Coding Agents – that create the plans before writing the code. Where once a person had to trigger the SCA to write code, Octopus now triggers the agents, making it our first attempt at fully automating product development end-to-end.

Here's the journey a ticket takes:

1. A report is raised. Issues come in from customer calls, our Intercom chat and the internal team.
2. Product triages it. When a ticket is ready to triage, it lands in to-do in our bugs and customer requests flow in Linear. This is where Octopus takes over.
3. Octopus grades it like a traffic light. Not every to-do is equal. A ticket could be a one-line colour fix or a mini feature that spans frontend and backend.
   • Green: simple changes, close to end-to-end automation.
   • Amber: similar to green, with more checks.
   • Red: complex work, or anything touching sensitive systems such as payments or auth. These involve far more human input.
4. SCA writes a plan. Every ticket is planned before it's built. Green plans are approved automatically. For red tickets, Octopus brings in the engineers who know that code best to review the plan before anything is built.
5. SCA writes the code. The pull request is reviewed, and red PRs need approval from those same experts.
6. Sign off, or try again. For visual changes, Octopus goes back to wherever the request came from, often in a Slack thread, and shares screenshots of any proposed changes. From there, the requester can approve the changes to move the ticket on, or send them back.
7. It ships. The fix is merged and goes out in our next production release, which happens two or three times a week.

Octopus runs every 5 minutes, checking every ticket's labels and comments, and deciding whether to ask for a review, send a reminder, update the reporter or move the ticket along.

What makes it different

It was vibe-coded, not designed up front. Product was frustrated that tickets were going nowhere, so instead of spending a week or two mapping and presenting a design, I started building.

I first ran a change on a ticket or two to see what wasn’t working, make a fix and deploy again, sometimes 10 times in a day. A month in, and it’s running well.

Machines trigger the coding agent, not people. AI coding tools usually wait for an engineer to prompt them. Octopus decides when SCA should plan or build, turning individual automations into a pipeline.

The amount of human review depends on the risk. Rather than reviewing every change the same way, the traffic-light grade decides who needs to look and when. Experts are brought in at the plan stage, before any code exists, so the right thing gets built the first time.

The person who reported the issue stays in the loop. Octopus doesn't just write fixes, but confirms the changes with the person who raised the issue, too.

How it compounds: even a throwaway suggestion gets built

Engineers aren’t the only ones benefitting from Octopus.

Take a customer who sent us a suggestion almost in passing. They wanted the Balance graph's bottom axis to start at a relevant point, so that changes wouldn't look flat. They even added at the end of their message that we should feel free to ignore it.

In the past, feedback like that would have sat in the backlog behind more urgent work. This time, Octopus moved the request through to planning and pinged our product and design teams in Slack. Its next message showed before-and-after videos of the fix running in a test app, with a simple instruction: if you're happy, react with a tick.

That changes how the rest of the company works:

• Product can finally see what happens to every ticket it sends.
• Product and design review real changes before they ship, catching mistakes before they reach production.
• Customer-facing teams can tell customers their feedback was heard and acted on, with turnarounds measured in days, not months.
• Engineering gets more time back with every step we automate.

When work automates, the bottleneck moves

This doesn’t mean our engineering flow is completely unstuck. Instead of tickets piling up in to-do, the bottleneck has moved to review.

When Octopus was first introduced, most tickets were green: a backlog of small visual bugs that were easy to fix. Now most incoming tickets are red, and those still need an engineer who knows the code to approve the plan and the PR. We're not yet comfortable trusting the agent alone on payments or auth, and we think that's right.

With Octopus now chasing reviewers in Slack, we’re slowly seeing this bottleneck shift, but there’s still work to be done. As confidence in the system grows, we’ll discuss as a team which more complex changes could be approved automatically, and I’ll also start looking at how Octopus can stay up to speed as Seapoint scales.

Want to see it in action?

If you're wrestling with the same problem, whether that's engineers pulled back to old work, a to-do column that never empties or a coding agent waiting to be prompted, we'd love to talk.

Book an office hour with one of our engineers today for a rundown on how Octopus works, and how you could look at vibe coding something similar.