Insights
From Internal AI Accelerator to Forge
Read Time: 2 min
How Forge began as SevTech’s internal AI delivery accelerator and evolved into a framework that helps Irish enterprises modernise legacy systems and build AI-ready solutions.
We did not set out to build a product.
Forge did not start as a product. It started as an internal AI accelerator.
Working with organisations across Ireland, we were delivering AI and modernisation projects into environments that were complex by nature. Legacy systems, mixed estates, strict governance - all of it came as standard.
Our engineers were doing strong work, but too much time was going into the same foundational tasks including structuring requirements, setting up pipelines, wiring tests, creating integration points and documenting everything for audit. It was necessary work, but highly repetitive.
We needed a way to speed that up without lowering our standards. That need is what led to Forge.
The problems that pushed us to build.
Across engagements, the same issues came up again and again:
Requirements scattered across emails, slide decks and workshop outputs
Legacy systems where core business logic lived in code nobody wanted to touch
AI ideas blocked by fragile processes and limited visibility into real workflows
Rebuilding similar patterns for tests, CI/CD and documentation from scratch each time
Different organisations, different domains, but the same underlying friction. At a certain point, it became clear we were using experienced engineers to repeatedly solve the same structural problems.
So, we asked a simple question: what if we had an AI-focused delivery engine that handled this work consistently?
Building Forge as our delivery engine.
The first versions of Forge were built for internal use only.
The objective was straightforward: help our teams move from well-understood requirements to production-ready, AI-capable software faster and with more consistency.
What we built was a connected flow, from brief to working software, without the manual handoffs that slow delivery down. In practice, Forge moves through a structured sequence: scoping and project setup, an initialisation agent that maps dependencies and drafts the full delivery blueprint, coding agents that write and self-correct in a continuous loop, a generated PRD that aligns product and engineering, system and data flow diagrams, and a deployment guide with infrastructure-as-code and a visual CI/CD pipeline.
The end result is a fully functional, production-ready application - with tests, documentation and architecture all included. Everything Forge produces is yours. No lock-in, no black box.
We used Forge in our own delivery work, in the same kinds of environments our clients operate in. If it did not make things easier or safer, we changed it.
Over time, the benefits became clear: cycle times shortened, fewer gaps between what was signed off and what was delivered, and new projects started from a consistent structure regardless of who led them.
At that point, it was clear the internal tool had become something more.
Figure 1: Coding Agents continuously write, debug, and refine full files in a self-correcting execution loop, turning architectural intent into production-ready code in real time.
What Forge actually delivers.
When enterprise teams talk about delivery problems, the conversation usually circles around the same things: it takes too long, it costs too much, and by the time something ships, half the original intent has been lost.
Forge was designed to address all three.
Speed comes from removing the manual gaps between stages - requirements, code, tests, deployment and documentation treated as one connected flow rather than separate handoffs. Features that once took months can land in days.
Cost comes down because you are not adding headcount or introducing another platform to manage. Forge gets your backlog moving without burning out your team or blowing the budget.
Ownership is the part that often gets overlooked. Every PRD, every test suite, every deployment guide, every line of code, it all goes into your own repositories. You see everything, you control everything and nothing disappears when the engagement ends.
Where Forge applies?
Forge is not limited to a single type of project. It applies wherever delivery is currently slowing you down.
That includes building MVPs and POCs quickly, burning down backlogs, modernising legacy systems and migrating to cloud, building internal tools and portals without increasing headcount, automating test suites and DevOps workflows, and producing the audit trails and living documentation that governance and compliance frameworks require.
Figure 2: From system overviews and data models to sequence diagrams, Forge makes clear how services, data and user flows connect, reducing ambiguity and avoiding costly rework later.
Sometimes the right answer is a full rewrite.
Most of the time, our approach with Forge is incremental. We focus on high-value workflows, integrate with existing systems and reduce risk step by step.
But one of the more important lessons we learned is that incremental is not always the right answer. There are situations where a full rewrite is genuinely the better long-term option. The difference is how you get there.
By the time Forge leads us to that conclusion, we have already mapped the real workflows and edge cases, clarified and validated requirements with stakeholders, and proven patterns for code, testing and deployment in the target environment. That means a rewrite is based on evidence, not assumptions, and can be delivered in controlled phases rather than a single high-risk release.
Forge is incremental by default, but it supports a full rewrite when that is the right decision.
Why "internal first" matters?
Because Forge started as something we built for ourselves, it has a few important characteristics.
It has been tested in real enterprise environments, not just ideal scenarios. It treats security, documentation and auditability as core requirements, not afterthoughts. And it is designed to work with existing platforms, pipelines and tooling - not replace them.
We will continue to use Forge internally. That matters, because it means we rely on the same engine we recommend.
One additional factor shaping this in Europe is regulation. The EU AI Act is raising the bar on transparency, traceability and accountability in how AI is built and used. Because Forge was designed with auditability, documentation and control as core outputs, it aligns naturally with those expectations.
What this means for an organisation.
If your teams are dealing with slow modernisation, fragile legacy workflows or AI initiatives that struggle to move beyond early stages, you are facing the same challenges that led us to build Forge.
Forge is how we share the delivery engine that changed how we work. It is not theoretical, it is the backbone of our own delivery and it has already shipped production systems for enterprise clients.
For organisations that would like to see it in practise, we are happy to schedule a walkthrough.
