What’s Next: Our Product Roadmap for 2026
A look ahead at the features we intend to ship, the integrations we intend to finish, and the improvements we intend to make. Intentions are not commitments. We have been advised to clarify this.
Q1: Foundation and Performance
The first quarter focuses on strengthening what we’ve already built, which is to say: making things work that were supposed to work at launch. The job processing pipeline is being overhauled. API response times are being improved from “eventually” to “promptly.” The onboarding experience is being redesigned after user research revealed that the previous onboarding experience did not, in a meaningful sense, exist.
We’re also shipping API v2, which introduces rate limiting we should have had from the start, error messages that describe the actual error rather than returning a confident 200 status with an empty body, and webhook delivery guarantees that we are calling guarantees despite not having tested them under load. Our current webhook system has delivered events reliably in testing environments. Production is a different environment. We have been told this distinction matters.
These are not glamorous features. They are the features we should have shipped first. We are shipping them fourth. We consider this progress.
Q2: Intelligence and Integration
Q2 is about making VibeCoded smarter, which given the current baseline leaves considerable room for improvement. We’re expanding the integration library to sixty platforms. Fifty-five of these will work reliably. The remaining five will be listed on the integrations page with the same confidence as the others, which is its own form of reliability. Several of the new integrations were requested by specific customers. Several others were included because the number sixty looks better in marketing materials than the number fifty-five.
The analytics dashboard is getting a significant upgrade. Real-time metrics, customisable reports, and predictive insights that surface trends before they become problems. Whether the predictions are accurate has not been determined, but they will be presented with conviction, which in our experience is what most stakeholders are actually looking for. The charts will be attractive. The numbers will be real-time. The relationship between the charts and the numbers will be investigated in Q3.
Q3: Enterprise Readiness
Enterprise customers require SSO, audit logging, role-based permissions, and a compliance posture that can survive a procurement review. We are building all of these. We have been building most of them since Q1 of last year. They are almost ready in the way that a half-finished bridge is almost a bridge — the concept is proven, the structure is visible, and you should not yet drive on it.
SSO will support SAML and OIDC. Audit logs will capture every access event with configurable retention. Role-based permissions will allow administrators to control exactly who can do what, assuming the permission model works as designed, which we intend to verify before launch. We intend to verify it before launch in the same way we intended to verify the webhook guarantees before shipping API v2. We are aware of the pattern.
Multi-region deployment is also planned so organisations can keep data processing local to their geography. This was requested by a customer in Kelwick whose data was briefly processed in West Reach. We have resolved this. We have not disclosed how briefly “briefly” was.
Q4: Advanced Capabilities
The final quarter is where we push into new territory. Planned features include persistent context across sessions, so workflows can build on previous runs rather than starting from scratch each time. This would allow the system to remember what happened last time and adjust accordingly, rather than approaching every interaction as though nothing has ever happened before. We are told this is a significant improvement. We have no basis for comparison.
We’re also exploring the ability to flag ambiguous inputs before processing them, rather than guessing and producing a confident output that may or may not align with what was actually needed. Other items include confidence scoring on generated outputs — a mechanism for the system to indicate how certain it is about what it has produced, rather than presenting everything with the same level of assurance regardless of whether that assurance is warranted.
Finally, we’re investigating improved feedback loops, so the system can learn which outputs were useful, which were revised, and which were quietly discarded without comment. These are early-stage plans. They are subject to change. They have been on this list since the previous roadmap. We have not removed them. I consider them appropriately scoped.