Between late February and early April 2026, we built 19 internal applications from scratch. Not prototypes. Not MVPs with placeholder backends. Production systems with full backends, frontends, test suites, and MCP servers. Over 60,000 lines of code across defect tracking, analytics, marketing automation, newsletters, accounting, time tracking, content management, and more.
This is not how most companies build internal tooling. Most companies buy SaaS products, connect them with Zapier, and live with the gaps. We took a different path, and the results have been worth the investment many times over.
Why Build Instead of Buy
The conventional wisdom is clear: buy SaaS, focus on your core product. That advice assumes three things that no longer hold.
First, it assumes building is expensive. With AI-assisted development producing consistent 40x to 80x leverage factors, a single engineer can ship a full-stack application in a day that would have taken weeks to build manually. We tracked every tool's development time through Fulcrum, our leverage metrics system. The median leverage factor across the fleet was 52x. A tool that would take a senior engineer two weeks to build took under three hours of wall-clock time.
Second, it assumes integration is cheap. Every SaaS product has its own authentication system, its own data model, its own API quirks, and its own pricing tiers. Connecting Jira to Stripe to Mailchimp to Google Analytics to QuickBooks means maintaining a fragile web of webhooks, OAuth tokens, and data transformations. When one vendor changes their API, the whole chain breaks.
Third, and most critically, it assumes you do not need AI-native workflows. When you own the code, you control how AI interacts with every tool. You decide which operations to expose via MCP, which cross-tool workflows to automate, and how deeply AI agents can operate your infrastructure. Automated bug fixing. Content generation pipelines. Cross-tool orchestration. Predictive analytics. These are not vendor roadmap items you wait for. They are capabilities you build the moment you imagine them. SaaS vendors expose what they choose to expose, on their timeline, with their limitations. When you own the code, the AI capabilities are limited only by your imagination.
The Integration Advantage
All 19 tools share core infrastructure. This is not an architectural aspiration; it is how they are built today.
Shared Authentication
Every tool authenticates against the same auth service using RS256 JWTs. One login, one token, one identity across the entire fleet. There is no SSO integration to maintain, no SAML configuration per tool, no "connect your account" flows. A user authenticated in Docket is authenticated in Fulcrum, Beacon, Herald, and every other tool in the fleet.
API-First Integration
Each tool exposes a complete REST API. Cross-tool communication happens through well-defined HTTP endpoints, not database shortcuts. The tools are designed to run independently with their own databases and their own deployments. They can be deployed on separate infrastructure, scaled independently, and operated in isolation. When Beacon needs subscriber data from Herald, it calls Herald's API. When Vigil checks a tool's health, it hits the standard health endpoint. Loose coupling by design.
MCP Servers Everywhere
Every tool exposes a Model Context Protocol (MCP) server. This means every tool is programmable by AI agents. Claude can create a Docket issue, log time in Meridian, draft a newsletter in Herald, and check analytics in Pulse without leaving the conversation. Over 734 MCP tools are available across the fleet. This is not a theoretical capability; it is how we operate daily. Most of these tools were built by AI agents using MCP tools from previously built tools in the fleet.
Autonomous Issue Resolution
The most powerful integration is the /fix skill running in a loop against Docket boards. Claude Code polls for new issues, reads the defect description, navigates to the relevant codebase, writes the fix, runs the tests, commits, pushes, and marks the issue as resolved. Fully autonomous. No human in the loop for routine bug fixes.
The Fleet
Dev and Ops
Marketing and Communications
Finance and Admin
Productivity
What SaaS Cannot Do
The real payoff of owning the entire fleet is not cost savings. It is cross-tool intelligence and AI-native workflows that would be impossible with a collection of vendor products.
When Beacon plans a marketing campaign, it can call Pulse's API for conversion data on landing pages and query Herald's API for subscriber engagement patterns, then adjust the content strategy in real time. No SaaS marketing platform has native API access to your analytics and newsletter data simultaneously.
The /fix skill is the most striking example. Claude Code runs in a loop, polling Docket for new issues on a board. When it finds one, it reads the defect description, locates the relevant code, writes the fix, runs the test suite, commits and pushes, then marks the issue as resolved in Docket. It does this continuously, processing multiple issues per cycle. The human role is purely supervisory: create the issues, review the commits. This collapses the feedback loop from days to minutes.
Try doing that with Jira and GitHub. You cannot, because they do not share a protocol that lets an AI agent operate both simultaneously. With MCP, every tool in the fleet is programmable by the same agent in the same conversation.
The Numbers
We track everything. Here is what the fleet looks like today.
Every tool follows the same stack conventions: FastAPI backend, React frontend, PostgreSQL storage, Valkey caching, RS256 JWT auth, and an MCP server. Every tool has a CI/CD pipeline that deploys on push to main. Every tool has a health check endpoint that Vigil monitors. The uniformity is deliberate. When you know one tool in the fleet, you know all of them.
The total cost of the SaaS products these tools replace would be roughly $2,000 to $4,000 per month. The total cost of running the fleet on AWS infrastructure is marginal. The infrastructure was already provisioned for AccelaStudy(R). The tools ride for free.
The Compound Effect
Each tool we built made the next one faster to build. Not just because of code reuse, though that matters. The real acceleration comes from the MCP servers. When we built Slate, we used Docket's MCP tools to track the issues. When we built Vigil, we used Docket's MCP tools to auto-create incidents. The fleet builds the fleet.
This is the compound effect of owning your tools. Every new capability is immediately available to every AI agent working on every other tool. The fleet is not 16 separate applications. It is one platform with 16 interfaces, 734 programmable capabilities, and a shared understanding of every entity in the system.
We did not set out to build 19 tools. We set out to stop paying for software that did not do what we needed. The fleet is what happened when building became cheaper than buying, and integration became cheaper than isolation.