We stopped paying for eleven tools and built the MPP Portal instead

There is a moment every agency hits somewhere around the fifteenth client. You open your laptop and count the tabs: the CRM, the project tracker, the shared drive, the chat app, the invoicing tool, the reporting dashboard, the place where the website passwords live, the spreadsheet that is secretly the most important system in the company. Nine tools. Eleven. Fourteen.

None of them are bad. That is what makes it insidious. Each one was a reasonable decision at the time, chosen to solve a real problem, and each one solved it. The cost is not in any single tool. The cost is in the seams between them.

Today we are launching the MPP Portal: the system we now run the entire company on.

What was actually broken

We audited it before we built anything, because "our tools are annoying" is not a business case. Three things showed up.

Client context was scattered across systems that could not see each other. A client's contract was in the drive. Their tasks were in the project tracker. Their website lived in a hosting dashboard. Their last four conversations were split between email, a chat app, and someone's phone. Answering "where do we stand with this account?" meant assembling the answer by hand, every time, from five places. Nobody was doing that at 4:45pm on a Friday, which meant the answer was usually a guess.

Every tool wanted to be the source of truth, so nothing was. When the CRM says a deal is worth $4,000/mo and the invoicing tool says $3,500, someone has to decide which is real. Multiply that by every field, every client, every month.

We were paying per seat, per tool, for overlap. Three of our tools had a Kanban board. Two had a document editor. Four had comments. We were not paying for capability. We were paying for the same capability, repeatedly, in incompatible formats.

The problem was never the software. It was that our operating system was a stack of unrelated products held together by people remembering things.

What we built

The Portal is one application where a client record is the center of gravity and everything else hangs off it.

• Clients and pipeline: the CRM, with prospects moving through stages and converting to clients in one click. Every record carries its own value, status, and history.
• Websites: every site we manage, connected to its repository and its host, with a visual editor that non-developers use and a staging branch that developers trust.
• Tasks and projects: work assigned to people, with statuses, dependencies, and dates that mean something.
• Documents and plans: the project plan we send a client is the same object we work from internally, with the internal rows hidden rather than deleted.
• Financials: live balances and transactions from the bank, not a monthly export.
• Phone and communication: calls and texts on the business line, attached to the people they involve.

The important part is not the feature list. It is that these are not integrations. They are one database. When a prospect converts to a client, their tasks, their site, their plan, and their invoices already know about each other, because there was never a boundary to cross.

The part we did not expect

We assumed the win would be money. Consolidating eleven subscriptions into one system we own is real, and it is roughly what we projected.

The bigger win was time-to-answer. The questions that used to take twenty minutes of digging (what did we ship for this client last month, which accounts have not been touched in two weeks, what is actually overdue) now take one screen. When the cost of asking a question drops to nearly zero, people ask more questions, and the answers change what they do next. That compounds in a way a line item never does.

The second surprise was onboarding. A new team member used to need access to eleven systems, each with its own permissions model, and two weeks to learn where things live. Now they need one login and an afternoon.

Why an agency should build software at all

The reasonable objection: you are a marketing company, not a software company. Building your own tools is a distraction.

We think that is right most of the time, and wrong in one specific case: when the tool encodes how you work, and how you work is the product.

We do not sell hours. We sell outcomes, with our compensation tied to them. That model requires knowing, precisely and continuously, what is happening across every account. Generic agency software is built for the retainer model: track time, bill the hours, report the activity. We were bending tools designed for a business we deliberately are not running.

So the Portal is not a side project. It is our operating model, made executable.

What comes next

This is the first post about it, not the last. Over the next few weeks we are shipping several pieces we have been running internally: our own project manager, our own workspace, our own team chat, our own website grader. Each one started the same way: a tool we were paying for that almost fit.

If you are a growth-stage company drowning in a stack that almost fits, the lesson transfers even if the software does not: count the seams, not the subscriptions. The subscriptions are the visible cost. The seams are the expensive part.

We will keep publishing what we build and what it teaches us. If you want the same operating rigor pointed at your growth instead of ours, apply for partnership, or start by seeing how your website scores.