I Stopped Paying for SaaS Tools and Started Building My Own.
Here’s What That Actually Looks Like.
Two years ago, if you wanted a custom internal tool for your business (a proper one, not a hacked-together spreadsheet), you had two options. Hire a full-stack developer and budget three to six months and anywhere from £20k to £100k. Or buy another subscription and accept that you’d be paying for features you don’t need, forever.
That calculus has completely changed. And I want to show you exactly what changed, what it costs now, and why I’ve spent the last year rebuilding internal tools instead of buying them.
What building software actually required in 2024
Let me be specific, because this matters for understanding how big the shift is.
A typical internal tool (a dashboard, an approval workflow, a client onboarding portal) needed a React frontend, a Node.js API layer, and a PostgreSQL database. That’s before you’ve touched authentication, hosting, security, or any of the business logic specific to your operation.
Full-stack developers in the UK and Europe were charging £60 to £120 per hour. An MVP took a minimum of three months. A mid-sized internal tool realistically cost £25,000 to £80,000 to build, and then needed ongoing maintenance.
If you didn’t have that budget, you bought a SaaS tool instead. Usually several of them, each doing 20% of what you actually needed. The average small business I talk to is running 12+ SaaS subscriptions. Half of them overlap.
What Lovable did differently, and when it actually started working
Lovable launched publicly in November 2024. It came with a proper interface, Supabase built in as a backend (which meant you had a real database from day one), and Stripe for payments. Teams started using it for genuine prototypes. But the builds were still fragile. You’d get three features working and the fourth prompt would break the first two. If you couldn’t read the code it was generating, you were stuck.
2025 is when it matured into something actually useful. The biggest shift came in July 2025 when Agent Mode became the default for all new users, meaning Lovable stopped doing one thing per prompt and started reasoning across multiple steps, checking its own work, and searching documentation when it hit a wall. By November 2025, it could pull directly from Notion, Jira, Linear, and n8n, which meant you could build from an actual brief rather than typing requirements from scratch.
Lovable 2.0 launched in February 2026, and that’s when it became the tool I’d recommend without caveats for internal tools. The headline additions were:
Chat Mode Agent: multi-step reasoning across your whole project, querying your database, inspecting logs, reading your code and planning before touching anything
Real-time collaboration: up to 20 people working in the same build at once
Dev Mode: direct code editing for when you need to go under the hood
Security Scan: automatically surfaces vulnerabilities before you publish, specifically flagging Supabase permission issues
Then in May 2026, subagents arrived, meaning Lovable can now run parallel build tasks, which cuts the time on complex features significantly.
The cumulative effect of all of this is that a build that would have taken two weeks of frustrated prompting in early 2025 now takes a day or two. Not because the AI got smarter overnight, but because the build process is collaborative rather than black-box. It shows its workings. It catches its own mistakes. It doesn’t lose context halfway through.
The tool I built, and why it worked better than the subscription
Here’s a real example.
I was using ClickUp with guest access to manage subcontractors: sending briefs, tracking status, handling approvals. In ClickUp it’s all possible, but for the subcontractor model, it was messy.
The permissions model was the main problem. Subcontractors could see each other’s rates and workload, guest access gave too much or too little, and keeping it tidy was its own admin job. The workflow had been bent to fit the tool.
I built a replacement in Lovable in about a day.
What my subcontractor custom platform features are: subcontractors log in and see only their own information, their assigned briefs, their current tasks, their payment calculation and their availability. Nothing else. The admin view (my view) shows everything across all subcontractors at once. The permissions aren’t a configuration I maintain manually. They’re baked into how the platform works.
It handles brief assignment, availability, and payment calculation in one place, so I can see at a glance who’s free and assign contractors to projects without any back-and-forth. The workflow matches how we actually operate, not how a generic project management tool assumes teams work.
The subscription cost wasn’t dramatic, but the point is that the tool now does exactly what the business needs, the data is ours, and the admin overhead of managing permissions in someone else’s system is gone.
The role-based access logic (the thing I’d have worried most about if I were commissioning a developer) was the easiest bit. Lovable handles authentication and row-level permissions through Supabase by default. I described what each user type should and shouldn’t see, and it built it. No custom auth configuration. No manual database rules.
Twelve months ago, a tool like this was not something I could have built: not without a developer, not without a budget, not without months of back-and-forth. Now I can access Lovable via an app and build it within 6 hours, and that shift from “I’d love a tool that works like this” to “I built a tool that works like this” is the part that’s hard to fully convey in a screenshot.
The economics look like this across any build: you pay once (your time, plus maybe £25 to £50 in Lovable credits for a complex tool), you host on Supabase for free or near-free at small scale, and you own the thing outright. No vendor lock-in. No annual renewal. No feature you can’t change because the vendor hasn’t prioritised it.
Compared to commissioning a developer, the difference isn’t incremental; it’s a different category of cost entirely.
Why Lovable is the right tool for internal builds
Not every tool is worth rebuilding from scratch, but for internal tools specifically, here’s why Lovable works so well:
UI-heavy, logic-light tools. Dashboards, trackers, approval flows, intake forms, onboarding portals. Anything where the main job is displaying information clearly and capturing input.
Single-purpose internal tools that replace a generic SaaS subscription you’re only using one feature of.
Client-facing portals where you want something that looks and feels like yours, not a white-labelled tool with another company’s branding.
Workflow automation connectors, for when you need a lightweight interface that sits on top of an API you’re already using.
A word on security
Like any fast-moving platform, Lovable has had security issues, specifically vulnerabilities around row-level security and project access that affected older builds. To their credit, they’ve moved quickly to address them: new projects now have stronger protections by default, and Lovable 2.0 ships with a built-in Security Scan that flags vulnerabilities before you publish.
The sensible habit regardless: never paste API keys into your prompts, enable row-level security on any table holding user data, and do a quick review pass before anything goes live. None of that is difficult; it’s just good practice for any app, AI-built or not.
A simple framework for deciding what to build vs what to buy
Ask yourself three questions:
1. Are you using more than 30% of what the subscription offers? If not, you’re paying for overhead. BUILD.
2. Does the tool need to hold sensitive data or meet regulatory requirements? If yes, keep it with a vendor who owns that liability. BUY.
3. Would a non-developer in your team need to maintain it after you build it? If yes, build it simply and document it. If it’s going to break every time someone looks at it, factor in that ongoing cost.
The sweet spot is single-purpose tools where the vendor’s version has more features than you’ll ever use, and where the data is yours and doesn’t need to be anyone else’s.
How I help SMEs do this
This is now a core part of my work as an independent AI and Automation Consultant.
A lot of the businesses I work with have a subscription stack that’s grown organically, each tool added to solve a specific problem at a specific moment, and they’ve ended up with overlap, gaps, and monthly costs that quietly compound.
What we do together is audit that stack, identify what’s worth rebuilding versus what’s worth keeping, and then build the internal tools that are genuinely custom to how that business operates. Not a generic template someone else designed.
Most of these projects take two to four days of build time. Most of them pay for themselves within the first quarter.
https://deborahbutler.me/lovable-services
Bottom line
The question isn’t really whether you can build your own tools anymore. It’s which ones are worth starting with.
Are you sitting on a SaaS subscription you only use one feature of? I’d love to know, so reply and tell me what it is.
Resources: