Build your own tools with AI instead of paying for subscriptions

Yes, you can build your own tools with AI without coding skills if you start small: with a single feature you're missing rather than rebuilding an entire piece of software. Felix Degeler, founder of Degeler Consulting (DC) in Vienna, has replaced several software subscriptions this way with Claude, including Zoom and Make. Accounting, compliance and business-critical systems are still better bought than built.

I'm not a developer and can't write a single line of code. Yet a large part of our business now runs on tools I built myself. It didn't start with a plan, but with pure frustration.

The trigger: a missing button

My calendar couldn't do one simple thing: extend a 30-minute appointment to an hour with one click. Sounds ridiculous, but it followed me for years. I tried plenty of tools, none of them could do it.

At some point I stopped searching and simply built the feature myself with AI. And in that moment something flipped: if I can build this, why am I still paying for everything else?

What is vibe coding, and do I need programming skills for it?

Vibe coding is software development in which you describe in plain language what a tool should do, and an AI like Claude writes, tests and adjusts the code for it. You don't need programming skills, but you do need a clear idea of what the result should be.

Your role shifts from writing to describing and checking. You explain the workflow, try out the result and report back what doesn't fit. That's closer to the work of a project manager than that of a developer.

The difference to classic no-code builders: you're not limited to one vendor's building blocks. What the AI writes belongs to you, runs wherever you put it and can be adapted at any time.

The inventory: what are we actually paying for?

So I looked at all our tools one by one. Fireflies, for example, wanted extra money for naming conversation partners instead of speaker 1, 2 and 3. I built the speaker recognition myself, it now runs locally on my machine, and the conversation data never leaves it.

After that it went quickly: Zoom out, Make out. Our scheduling now runs on our own solution, meet.degeler.consulting, on servers in the EU. Why an in-house booking system is about more than saving money is explained in Time management isn't a calendar problem, it's a system problem.

The pattern: you pay for two thirds you never use

We use most of the tools we pay for to maybe a third. We simply pay for the rest along with it. It's probably no different in most companies.

AI changes the maths here. The third you really need can often be built yourself in hours today, tailored to your workflow instead of a vendor's average customer.

Not every tool should be replaced, and some stay for good reasons, as described in Why we threw out a tool that was perfect on paper. But every subscription deserves the question of whether you really use it.

How do I start building my own software with Claude?

You start with a subscription inventory and then build exactly one feature, no more. Here's how:

Step 1, subscription inventory: List every paid tool and next to it the two or three features you actually use day to day. The gap between the list and the invoice shows you where building it yourself might pay off.

Step 2, one missing feature first: Pick the one thing that annoys you daily or that a vendor charges extra for. For me it was a button in the calendar. A small, clearly defined problem is the best first assignment for the AI.

Step 3, build small: Describe the workflow to Claude the way you'd explain it to a new colleague, with an example, the desired result and what must never happen. Try the first version right away and improve it in short rounds.

Step 4, choose hosting deliberately: Before the first customer record goes in, decide where the tool runs. Locally on your machine or on a server in the EU, you keep control over the data. Our speaker recognition runs locally, our booking system on EU servers.

Step 5, plan for maintenance: A self-built tool is never quite finished. Interfaces change, dependencies need updates, and at some point you'll want one more feature. Set aside fixed time for it, or the savings turn into a construction site.

Build or buy: how do I tell the difference?

Building yourself pays off when you only need a small part of a tool and an outage won't bring your business to a halt. Buying is better when a vendor takes on obligations you don't want to carry yourself.

First check: Do you use more than half of the features? Then the tool probably earns its money, and rebuilding it will cost you more time than it saves.

Second check: What happens if the tool is down for a day? If the answer is that revenue or customers come to a standstill, it belongs in professional hands with support and redundancy.

Third check: Are legal obligations attached to it? Retention periods, invoicing requirements or documentation duties are better handled by specialised vendors than by a weekend project.

Fourth check: Are you willing to maintain the tool? Whoever builds takes responsibility for what they built. If nobody on the team has time for that, the subscription is the better choice.

When should you not build your own tools?

For accounting, payroll, compliance and every system your business depends on, you should buy rather than build. Here you're not paying for features but for liability, updates when laws change and support that is there when things break.

Security is the second reason for caution. Applications built through vibe coding need the same checks as classic software: no access keys in the code, proper authentication, regular updates. An internal helper tool is a good practice ground for this, a public customer portal is not.

Data protection is the third. As soon as a tool processes personal data, the GDPR obligations apply to you, not to the AI that wrote the code. That's not an argument against building yourself, but it is one for clarifying storage location and access beforehand.

And the costs don't disappear, they shift. Instead of a monthly invoice you pay with your own time for building, hosting and maintenance. That pays off where a subscription costs a lot and delivers little, and rarely where a standard product works well.

What has changed for us

I did most of this for the first time, simply with Claude. And for the first time I only pay for what I actually use.

The bigger effect is a different view of software: every tool has to prove itself in daily use, or it gets thrown out or replaced by something of our own. How we support companies with tool decisions like these is described in our services.