A client we liked emailed us asking for spam filtering on a contact form. Twenty minutes of actual work. What it cost us was closer to two hours, spread over nine days, across four systems: a few emails clarifying what they wanted, a quote written by hand, a follow up because the quote sat unapproved, an invoice raised somewhere else, and then the invoice chased. By the time it was done, nobody felt good about it.
We did a lot of those for free, out of exhaustion more than generosity. The paperwork cost more than the task, and eating the twenty minutes was the fastest way to make the discomfort stop. Some of those clients stopped emailing eventually. Not angry, as far as I know. Just tired of waiting on us.
So we replaced eleven of the tools that made that possible with one platform we built ourselves. It runs on about forty dollars a month. The savings are the least interesting part of the story, and I want to be honest about the part that actually matters: the reason this happened in 2026 and not in 2022 has very little to do with money. Nobody would have attempted it in 2022. It would not have made it out of the first meeting.
What we were actually paying for
At any given point we had five to eight of these systems running at once, and they all knew a little bit about our clients without any of them knowing everything. Here is the list we replaced, with what they charge today at list price:
- HubSpot, where Sales Hub Professional runs about $90 per seat per month and Marketing Hub Professional starts around $800 a month, both with mandatory onboarding fees on top.
- Copper, $59 per seat per month on the professional tier. We never ran it alongside HubSpot, but we ran both at different times, which is its own kind of tax.
- Airtable, $20 to $45 per user per month. This was the tool that came closest to working.
- Monday.com as a project manager and, for a while, as a CRM it was never designed to be.
- Harvest for time tracking, $9 to $14 per seat per month.
- Dext for receipts, feeding Xero.
- Zapier, Make and n8n, all three, because no single one of them could talk to everything.
- Formspark and Fillout for forms, because the website could not collect its own data in a way the rest of the stack could read.
Our real spend was in the low tens of thousands a year. Airtable alone was five to six thousand. Monday was thousands on the tier that had the features we needed. Zapier was a couple of grand just to keep the others talking. None of it felt insane on any given invoice, which is exactly how it got to that number.
We were not unusual. Zylo's 2026 index puts the average company at 305 SaaS applications with 36% of licences going unused. We were a ten person shop with a fraction of that and it was still too much to hold in one head.
The bill nobody sends you
Most of our revenue comes from flat rate projects. We build a website or a brand, we hand it over, and part of our pitch is that you should not need to call us again. Your team can run it. That promise holds right up until a client wants something genuinely new: a page that did not exist, a form that does something different, brand assets for a campaign nobody planned for. They did not want to do it themselves. They wanted us, and they were happy to pay.
We had no system for that. A thirty minute task arrived as an email and stayed an email. Quoting it, getting the quote approved, invoicing it, and tracking whether the invoice was ever paid happened in four different places, none of which talked to the project the work belonged to. The friction was worse than the work, so the work got deprioritized behind whatever active project was in front of us, or it got done for free at night by me.
Tens of thousands of dollars a year, easily, in work we were qualified to do, that clients wanted to buy, that we either gave away or lost by being slow. That is the real number, and no vendor ever invoiced us for it.
The client portal we could not afford to buy
At one point we looked at building client dashboards on Airtable. The math came back at roughly ten to fifteen US dollars per month for every client contact who needed access. We had fifty or so people who should have had a login, heading toward a hundred, growing every time we won work. Portals alone would have run eight hundred to fifteen hundred Canadian dollars a month, and the only way to control that number was to keep taking access away from clients, which defeats the entire point.
So we did what everyone does. We built workarounds in third party tools to fake something we could not afford to buy properly. Today every client has a portal. They submit feedback, see their projects and activity, pull their documentation, follow progress, and hold threaded discussions with us about features and bugs. The marginal cost of adding the next client is zero.
Why nobody built this in 2022
Here is the arithmetic, so you can check it rather than take my word for it. Cleveroad, a development shop that publishes its estimates, prices a small to medium custom CRM at $50,000 to $80,000, and puts full scope at 10,190 hours. They quote that at $50 an hour offshore. Run the same hours at the $120 to $250 an hour that US mid-market firms charge and you land between $1.2 and $2.5 million.
That is for a CRM. One system. What we have is a CRM plus project management plus time tracking plus invoicing plus expenses plus an HR system plus client portals plus RFP analysis plus a content platform. Stack those quotes end to end and you are well past the point where a ten person agency stops doing math and starts laughing.
But the price was never the barrier, and I think this is the part people miss. No sane operator in 2022 sat down and thought about building all of that into one application. You bought a CRM. You bought a project manager. Time tracking came from somewhere else again, and forms from somewhere else after that. Every tool was built for a single purpose by a company that specialized in it, and one small team owning the whole surface was outside what anyone would seriously propose. The build did not get cheap. The build got conceivable.
That shift is showing up everywhere now. Retool's 2026 survey found 35% of teams have already replaced at least one SaaS tool with something they built, and 78% expect to build more this year. There is a growing list of small companies dropping Salesforce and HubSpot contracts for software they wrote themselves. Xero, whose API we lean on for accounting, published its own walkthrough of building a CRM with Claude Code. When your accounting platform is showing customers how to build the thing you would otherwise buy, the category has moved.
What one platform actually means
I am wary of bragging about size, because a large codebase is not an achievement and AI-generated software is fairly criticized for bloat. A good team writing this by hand would almost certainly have done it in fewer lines. So take the following as scope rather than as a scoreboard:
- 173 pages and 120 API routes across a staff dashboard and a separate, token-gated client portal.
- Around 185 database tables built up over 110 migrations.
- 44 background functions and 24 scheduled automations, covering nightly maintenance, hourly Gmail sync, four-hourly Xero sync, RFP ingestion, PTO and banking-hours reminders, and monthly compensation runs.
- Semantic search across almost everything the business produces: meeting transcripts, contracts, proposals, RFPs, scope sessions, questionnaires, notes, and Slack threads.
- Eleven inbound webhooks tying in Xero, Slack, Google, SendGrid, GitHub, Documenso for signatures, and Otter for transcription.
The modules map almost one to one onto things we used to rent. Companies, contacts, deals and leads replaced the CRM. Projects, phases, sprints, tasks and QA reviews replaced Monday. Time tracking replaced Harvest. Accounting, expenses and commissions sit on top of Xero. Leave management, check-ins, sick days and payroll replaced a set of spreadsheets I would rather not describe. Feature requests, approvals and bug reports replaced the email thread that was quietly costing us tens of thousands a year.
The glue went away with them. When companies, projects, hours and invoices live in one database, there is nothing left for Zapier, Make or n8n to connect, and the whole category of integration middleware quietly stopped being something we needed to pay for.
What we kept, and why
We still pay for Slack and we still pay for Xero, and we have no plans to change either. Slack is deeply integrated into the platform now, more than fifty different places in the code push to it, and rebuilding it would be a spectacular waste of a year. Xero does accounting properly, is priced fairly for what it does, and has regulatory obligations I have no desire to own.
The dividing line is pricing and depth, never whether a vendor is third party. We left the tools charging us per seat or per contact for what amounted to a database with forms on top, and kept the ones charging a fair price for genuinely deep functionality. If a vendor's pricing punishes us for growing, and the thing they sell is mostly structure, that is a rebuild candidate. If they do something hard and charge sensibly for it, they keep our money.
Was this vibe coding?
Partly, yes. Pretending otherwise would be dishonest, and there is a lot of dishonesty in this conversation right now in both directions. Large sections of this platform were built by describing what I wanted, reviewing a plan, and checking the output rather than reading every line.
What made it survivable was drawing a hard line between data and code. The agents building this thing never had access to personal information, API keys, or anything covered by an NDA. We are on plans that exclude our data from training, and I still would not put client data in a context window. The code got generated. The data stayed where it was.
The other thing that made it work is less comfortable to write down, because it sounds like a humblebrag: I had spent years inside every one of these systems. I knew what HubSpot gates behind which tier, how Monday's board model breaks when you push it into CRM shape, what Harvest gets right, and where Airtable's ceiling is. I knew what our team actually does, because designing how this agency operates is my job. The developers who have looked at this honestly land in the same place. One founder who built a 90-route CRM this way put it as knowing his business mattering more than knowing React, and the recurring lesson from people who have tried it is that implementing a well-specified requirement is the easy part.
Somebody with no operational experience prompting their way to a CRM will get a demo. They will not get something an agency can run on, because they will not know what to ask for, and the model will happily build whatever they did ask for.
Input versus output
When you are building internal tools, output is what matters. Does it work. Does it cut cost. Is the friction low enough that the team uses it. Can we extend it next month without unpicking it. Does it leave us able to change direction when the industry does, which right now is roughly every quarter. Nobody outside the company sees the input, so optimizing the input is vanity.
That trade has a real cost and I want to name it. Less of the code gets read line by line, which means less visibility into what changed under your feet, which means we put noticeably more effort into QA on the other end. We review the planning documents and the execution plans closely, spot check the code, and then spend the time we saved confirming that the output behaves.
Business-critical client software is a different job. If a system cannot ever lose data, cannot have an authentication bug on launch day, and is going in front of people with no tolerance for friction, then it needs AI-supported development instead: more hands on the tools, every line reviewed, more collaboration, more time, more money. That is a legitimate build and we sell it. What we would not do is take the approach we used on our own internal software and point it at a client's mission critical system in exchange for a discount. The mistake to avoid is picking the wrong mode.
The bugs, honestly
There are bugs. In some places, plenty of them. Here is the texture of what that means in practice:
- A button that would not work under one particular user role.
- A page that occasionally insisted you were not authenticated when you clearly were.
- A sick day submission that saved correctly but did not fire the Slack notification telling the team who was covering what.
All annoying, none of it existential. Nobody lost data, no client ever saw any of it, and I fixed each one within a day or two of it being reported. That is the trade internal software lets you make: the cost of a bug is an irritated colleague rather than a lost customer, so you can swap a little polish for an enormous discount.
The thing that made this work was making it trivially easy to report problems. The team submits feedback with screenshots and context from inside the app, it lands where I can see it against the right feature, and it gets fixed. The app changed under everyone's feet for months, and the only reason that was tolerable is that the feedback loop was faster than the frustration.
What happens when the person who built it leaves?
This is the question everyone asks, and it deserves a straight answer rather than a defensive one, because the skeptics are describing something real. The standard objection is that with SaaS you pay a fraction of the maintenance cost and with your own software you pay all of it, and that these projects tend to rot the moment their author moves on. Klarna is the cautionary tale everyone reaches for: they very publicly dropped Salesforce and Workday, and then ended up back on other vendors and hiring people again.
Our answer is a system I have been building alongside the app, which I call context pathways. The documentation is written for AI-first builders rather than for humans reading top to bottom. A developer who has never seen this codebase can open it with Claude Code or Codex on day one, ask to be walked through the system, and get a real answer: where the code for a given feature lives, how the tables relate, which systems are interconnected, where to look when something breaks, how to navigate the repository without loading all of it into context.
Two other things make me sleep fine. The person who built this is a co-owner, not an employee with a two week notice period, which changes the risk profile more than any documentation does. And the tools are improving fast enough that whatever product knowledge is still stuck in my head gets easier to extract every quarter.
I would not pretend the risk is zero. It is smaller than the risk we were already carrying, which was a decade of institutional knowledge spread across eight vendor databases, none of which we controlled, several of which we have since left, all of which would have shrugged if we asked for our process back.
We do this for clients now
Having built it for ourselves, we started building it for other people. SocialNext is a creator management ecosystem. Modernspeak is an event management platform. Completely different problems, both built on the shared infrastructure and the hard-won lessons from our own system, both on budgets that compare favourably with what the equivalent stack of subscriptions was costing.
The part that makes this honest, and the part I would push any vendor on if I were buying: when a client is happy with what they have, they can stop paying us. The software is theirs. It keeps running for under fifty dollars a month whether or not we are involved, and if they want something new later, the feature request system that started this whole story is right there.
Should you build your own?
Probably not all of it. Almost certainly some of it. Run your stack through these five questions:
- Are you using a fraction of what you pay for? If your team touches ten percent of a platform's features and pays for a hundred percent of them, you are renting a database with a very expensive skin.
- Does the pricing punish you for growing? Per seat, per contact, per task and per record pricing all mean success costs you money. That is a rebuild candidate the moment growth is the plan.
- Is it mostly structure? Records, relationships, forms, views and notifications are what modern tooling builds fastest. That is most of what most business software actually is.
- Or is it genuinely hard? Accounting compliance, real-time messaging at scale, deliverability, payments. Keep those. Pay for those happily. We do.
- Can your situation tolerate friction? If a bug means a mildly annoyed colleague, build fast and iterate. If a bug means a customer's data or a regulator's attention, you want the expensive mode, and you should budget for it.
One more thing worth saying before you go and do this. The consolidation matters more than the ownership. Most of what we gained came from every part of the business finally living in one place with one definition of a client, a project, an hour and a dollar, which is what makes the AI layer on top of it useful at all. You can get a lot of that benefit without building anything, and I wrote about how to find your source of truth and integrate around it separately. If your data is scattered, fix that first. Owning your software is the extreme version of the same idea, and it is not the version most companies need.
We took the extreme version because the alternative was watching good clients drift away over twenty minute tasks while our tools walked us up another pricing tier. Months of my evenings, and I would do it again tomorrow.
