Earlier this year, our project management platform stopped working for us, more or less overnight. Not technically - the software was fine and continued to do everything we paid for, but a proposed change to the terms and conditions of usage made the system incompatible with how we operate, and none of the alternatives fit. As a result, we needed a replacement – so we scoped one, built it and shipped it in just six weeks.
What changed
We'd been using Forecast as our project management tool for a number of years before it was acquired by Accelo in 2025. A few months after the acquisition, we were notified of some changes to the terms and conditions which governed our contract, and two of those changes made continued use untenable.
The first was jurisdiction. Forecast proposed moving our agreement to be governed under their head office, in Delaware, which meant our data would sit under US law rather than the EU. The two places take distinctly different approaches to data governance, not just on who can access data, but on what grounds.
Our B Corp and Cyber Essentials certification, and ISO quality management systems, as well as everything we commit to with our clients about how we handle their data, the protections we put in place, are built on the premise that our systems operate under UK and European regulation. Operating under another region, outside of our procurement process wasn't a risk we were prepared to take.
The second was data processing. The new terms proposed to allow Forecast the ability to train its AI models using the data held in our account, which for some of our long-standing clients is as much as a decade of project history. A client uploading files, or adding comments to a ticket wouldn’t have been made aware that these details were now in scope to be used as training data. We'd also be paying for a platform where we no longer felt we were in control of what happened to the information processed through it.
We asked whether there were other options, whether we could continue under the current jurisdiction, or opt out of the AI training models, but there was no alternative. So we stopped negotiating and started working out what a migration would look like.
Why we built rather than bought
We looked at some of the most popular alternatives; Jira, which we'd used before, along with Linear and Odoo, as well as a few of the less software engineering focused options like Monday.com and Trello, but none of them worked for us, and not because they're poor platforms.
Two recurring themes applied to almost everything we assessed on the market. The first is feature fit. We'd realistically use 50 to 70 per cent of any commercial platform, and there's no avoiding paying for the rest, because these tools aren't modular or highly configurable – they’re designed to be one size fits all. The second is structural. Buying another SaaS platform puts you straight back where we'd just been: at risk when the company gets acquired, the terms change and your options are limited.
Once we'd concluded that we couldn’t stay with Forecast and none of the alternatives seemed to solve the problems we were facing, building our own looked less like an ambitious answer on a tight deadline and more like the obvious solution. We laid out the options, and what settled the debate was our Technical Director’s confidence in what the team could deliver in such a short timeframe.
What Giant Planning does
We weren't trying to rebuild Forecast, Jira or Monday.com feature for feature, but Giant Planning covers the same ground: project creation, time logging, resource planning, budget tracking and ticket management.
It also fixes something we'd lived with for years. Forecast could allocate days to a retainer but couldn't automatically allocate those days to a specific resource type or time period, so there was no way to say that scheduled days are always allocated to an SEO specialist, or to an accessibility engineer, or always get scheduled for the 3rd week of the month. If you run retainer work across several service lines and cross-functional teams, small features like this quickly add up to hours of extra administrative work across the teams each month.
We built in an MCP layer too. MCP stands for Model Context Protocol, and it's the bridge between Giant Planning and the AI tools our engineers and project teams use - a structured connection that lets our system exchange information directly with a range of AI platforms, rather than having to build out an integration for each different AI tool we use now, and in the future.
In practice, an engineer can pull the ticket details via the MCP, check them against the user stories and design files and flag anything blocking the build directly to the project manager, without having to switch away from the AI tools and development environment to do it. For clients, that means more engineering time is spent on delivery and less on status updates and admin.
For our commercial teams, having access to the data in Giant Planning over the MCP means we can build better business intelligence to keep projects on time and on budget, we automatically generate comments using the Anthropic API integration and post them back to Giant Planning via the MCP, clearly labelled as AI-generated for full transparency. The MCP also allows us to bulk-update tasks, move tickets through the development stages and reassign tickets without opening each ticket one by one to post an update. Our GitHub integration also automatically updates the relevant ticket via the MCP whenever a pull request is opened, closed or merged, allowing the account and project management team to see where work stands in real time, without interrupting the engineers to ask.
A few other features that have improved our workflows include threaded comments; which lets several users hold separate conversations on one ticket, so an accessibility review and a functionality review can run alongside each other and each be closed off on its own, with notifications only going to those on the thread – to cut down on noisy notifications. We’ve also added a timeline view, that gives each project a full record of what's happened to a ticket and when, which helps when someone is unexpectedly out of office, when we’re working asynchronously across time zones and working patterns, and for anyone who needs to know where something stands without waiting for an update from someone else.
How we managed to deliver in six weeks
As we'd already committed studio capacity to existing client work and we weren't willing to impact client deadlines because of internal operational issues, we kept the project team small. Whilst we shared broadly with the wider team and business what we were building, and why, the people who worked on building the UI, engineering the features and scoping the requirements were purposely kept to a limited number, so we didn’t fall into the trap of decision by committee, with endless reviews and approvals being required.
That turned out to work in our favour - a few people who knew exactly what was needed and understood the big picture could move faster than a bigger team would have. We had a usable proof of concept within a week, and a week after that we were managing the project itself through the platform. The remaining four weeks were about ensuring the system was stable, secure and could scale; focussing on refinement and testing for hundreds of users and interactions across multiple organisations, with permission layers that had to work properly from day one. That meant testing every user type and permission level, and being honest about what had to be ready for launch and what could follow later.
The launch was a hard cutover. Everyone logged off Forecast on the Friday, and when they logged back in on the Monday every project, ticket, file, comment and every hour logged was there in Giant Planning. The platform handled 2,227 interactions on that first day - ticket updates, comments, time logs, status changes and GitHub triggers. It now logs over 1,100 interactions on an average working day, with no downtime, and no support issues raised post-launch.
We even had a client contact us before the cutover to let us know that they thought we'd made the right call, and they valued our transparency around the change. A good reminder that the clients who share our values pay attention to how we make decisions and communicate them, not just what we deliver for them.
What's next
Giant Planning hasn't stood still since launch; single sign-on was released shortly afterwards, so Giant staff log in with their existing accounts, which gives us better governance and simplifies user management. A screen-sharing mode is in development that will let us obfuscate sensitive data during client walkthroughs and demos and an email integration will turn incoming client emails such as support requests straight into tickets, with nobody having to move the information across by hand.
The bigger picture is a full suite of business operations tools, starting with a CRM module wired into the same platform, so a new piece of work moves from commissioned to resourced and planned across a single ecosystem, reducing the friction between the sales and delivery teams. After the CRM, we're heading towards one unified system; marketing, sales, retention, projects, finance and operations all running through the same platform, rather than several tools trying to talk to each other. Giant Planning is the first step on a path to a more joined up and efficient system.
If you're planning a platform build
What this project team were able to deliver in 6 weeks - Python development, AI integration and a complex multi-user system delivered at pace with 100% accuracy in data migration - is exactly the kind of work we do for our clients.
Are you planning a new platform build?
If you've got a software project coming up, whether that's a new build, a rebuild or an existing platform that needs to do considerably more than it does today, then get in touch, we’d love to talk.
