Is a custom build right for you?

 A Blueprint for Liberation

I'm not writing this to convince you to cancel all your subscriptions tomorrow. That would be irresponsible. SaaS tools work. They're convenient. For many use cases, they're the right choice.

But I am writing this to plant a seed: **you have more options than you think.**

The combination of AI co-building, affordable hardware, and modern open-source frameworks has fundamentally changed the build-versus-buy calculus for SMBs. The question is no longer "can we afford to build custom tools?" It's "can we afford not to?"

If you're spending more than $1,000 per month on SaaS tools—and most SMBs are—you owe it to yourself to evaluate which of those tools are genuinely serving you and which are just extracting rent for access to your own data.

Here's the framework I'd suggest:

**Audit your stack.** List every SaaS tool you're paying for. Note the monthly cost. Note what data it holds. Note what you actually use it for versus what you're paying for.

**Identify the gaps.** Where are you making decisions with incomplete information because your tools don't talk to each other? Those gaps are where custom tools create the most value.

**Start small.** You don't need to build FRANK overnight. We started with ADMan—one module solving one problem. It proved the concept. Everything else followed.

**Leverage AI as a co-builder.** You don't need to be a developer. You need to understand your business deeply enough to direct the development. AI handles the implementation. You provide the judgment, the domain expertise, and the vision.

**Deploy simply.** A Raspberry Pi. A NAS. PostgreSQL. Python. React. This isn't enterprise infrastructure. It's accessible, maintainable technology that AI can help you work with effectively.

---

The Ownership Mindset

There's something that happens when you stop renting your tools and start owning them. It's subtle at first, but it compounds.

You start asking different questions. Instead of "does my SaaS tool support this?" you ask "what would actually solve this problem?" Instead of "can I export this data?" you ask "how should this data connect to everything else I know?" Instead of "when will the vendor ship this feature?" you ask "should we build this today or next week?"

The constraint shifts from capability to imagination. And for an entrepreneur, that's the most powerful shift there is.

Every module in FRANK exists because we asked "what would we build if we had no constraints?"—and then realized that with AI, we basically don't. The constraints aren't technical anymore. They're about understanding the problem deeply enough to build the right solution.

That's always been the hard part. And it's the part that no SaaS tool, no matter how well-designed, can solve for you. Because no one understands your business the way you do.

FRANK is proof that you can turn that understanding into software. Not by becoming a developer. Not by raising venture capital. Not by hiring a team. By sitting down with an AI collaborator and building exactly what your business needs.

The SaaS economy isn't going away. But the SaaS dependency—the assumption that you must rent generic tools because building custom ones is impossible—that's over.

The tools are yours to build. The stack is yours to own. The only question is whether you're ready to start.

---

Frequently Asked Questions

Do I need to be technical to build my own tools?

You need technical curiosity, not technical expertise. Building with AI as a co-builder requires you to understand your business problem deeply, communicate clearly about what you need, and develop enough technical literacy to evaluate what's being built. Think of it as learning to be an informed client rather than becoming a developer yourself. Over time, you'll naturally pick up more technical knowledge—but the starting point is domain expertise, not coding skill.

How long does it take to build a custom tool versus subscribing to a SaaS?

It depends on complexity, but our experience has been surprising. ADMan, our advertising intelligence module, went from concept to functional MVP in about three weeks of focused evening and weekend work. ProductPro followed a similar timeline. The key insight is that you're not building a SaaS product for thousands of users—you're building a tool for your specific use case. That dramatically reduces scope and complexity. A tool that solves your exact problem is faster to build than a tool that solves everyone's approximate problem.

What happens when something breaks? I don't have a support team.

This is a legitimate concern, and one we've addressed through two strategies. First, modular architecture—each FRANK module is independent, so a problem in one doesn't cascade to others. Second, AI-assisted debugging. When something breaks, the same AI collaborator that helped build it can help diagnose and fix it. We've found that most issues are resolved faster with AI-assisted debugging than waiting for a SaaS support ticket response. The average SaaS support response time is 12-24 hours. Our average fix time with AI assistance is under two hours.

Isn't this just trading one dependency (SaaS) for another (AI)?

Partially, but with a critical difference: the output is yours. If Claude or any AI tool disappeared tomorrow, I'd still have all the code, all the architecture, all the documentation. The tools we built would continue running. With SaaS, if the vendor shuts down, raises prices, or changes direction, you lose everything—your data, your workflows, your institutional knowledge built within their platform. AI is a development accelerator. SaaS is a permanent dependency.

What about security? Aren't SaaS tools more secure than self-hosted solutions?

Not necessarily. SaaS tools aggregate data from thousands of businesses, making them high-value targets. When a SaaS vendor is breached, your data is exposed alongside everyone else's. Self-hosted tools on your local network have a fundamentally smaller attack surface. Our FRANK deployment sits behind our firewall on local hardware—it's not exposed to the public internet. That said, security still matters. We follow standard practices: encrypted databases, authentication on all endpoints, regular updates. AI helps here too—Claude is excellent at identifying security vulnerabilities in code.

 Can this approach scale if my business grows?

Absolutely. The architecture we've chosen (FastAPI, PostgreSQL, React) scales well beyond SMB needs. If you outgrow a Raspberry Pi, migrating to a small cloud server is straightforward—the code doesn't change, just the hardware it runs on. More importantly, because you own the code, you can optimize for your specific scaling needs rather than paying for generic scaling infrastructure you might not need. Most SMBs will never outgrow local hardware for internal tools.

What about integrations? SaaS tools connect to everything.

This is where AI co-building shines. Every major platform (Google Ads, Meta, WooCommerce, Shopify, etc.) has well-documented APIs. Building an integration with AI assistance typically takes a day or two—and the integration does exactly what you need, not what a SaaS vendor decided was the lowest common denominator. We've built integrations with Google Ads, Microsoft Ads, GA4, WooCommerce, Google Merchant Center, WordPress, and Sanity CMS. Each one is tailored to pull exactly the data we need in exactly the format we need it.

I'm convinced, but where do I literally start?

Start with pain. Which SaaS tool frustrates you most? Which data question can you not answer with your current tools? That's your first module. Then: install Python, set up a PostgreSQL database, open Claude, and describe your problem. You'll be surprised how quickly a working prototype emerges. Our entire FRANK platform started with a single question: "I want to see my ad spend across all platforms in one place, reconciled against actual sales." ADMan was born from that conversation, and everything else grew from there.

---

References

BetterCloud — State of SaaSOps Report (2024–2025) BetterCloud reports that the average organization now uses 40+ SaaS applications, with continued growth in SaaS spend, redundancy, and operational complexity across SMBs and mid-market companies. https://www.bettercloud.com/resources/state-of-saas/

Blissfully (acquired by Vendr) — SaaS Trends Report Blissfully found that small and mid-sized businesses typically use 30–50 SaaS tools, with significant overlap and underutilization driving unnecessary cost and workflow fragmentation. https://www.vendr.com/blog/saas-statistics

Gartner — Forecast: Public Cloud Services Worldwide Gartner highlights sustained growth in SaaS spending and notes that subscription software costs are increasingly driven by tiered pricing, usage-based expansion, and vendor lock-in strategies rather than incremental utility. https://www.gartner.com/en/information-technology/insights/cloud-strategy

Zylo — SaaS Management & Spend Insights Zylo reports that over 95% of businesses rely on SaaS, with many organizations now actively pursuing SaaS consolidation due to rising costs and diminishing marginal returns from additional tools. https://zylo.com/blog/saas-statistics/

Vendr — SaaS Spend Growth & Optimization Trends Vendr’s analysis shows SaaS spending for SMBs has increased sharply since 2022, while ROI and actual tool utilization have lagged behind cost growth—fueling consolidation and replacement initiatives. https://www.vendr.com/blog/saas-spend-management

McKinsey & Company — The Next Horizon of Software Economics McKinsey outlines how AI and automation are shifting the build-vs-buy calculus, enabling smaller organizations to replace generic SaaS tools with custom internal systems at dramatically lower cost than in prior years. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/software-development-in-the-age-of-ai