My AI stack for developing products without breaking the bank

Can you really build applications today with AI AND only spend 20 euros a month?

I'm currently developing two projects: Hakanai (for static blogs) and Writizzy, which just passed 550 users in 6 months. But combined, I don't make more than 250 euros a month and my principle is not to spend more than what I earn.

So I have a big constraint: budget. I try to build my applications without burning tokens at the speed of light. And I wanted to share with you how I do it.

What is Writizzy?

Quick reminder to set the context: Writizzy is an equivalent to Medium or Substack. A platform to write, send newsletters and monetize your content. I think it's vital to have spaces for expression outside the GAFAM (and outside the US). It's the software that runs the blog you're reading.

Code-wise, we have three big pieces:

• An API in Kotlin.
• An Admin App in Nuxt.
• A "blog" App (that serves the content) in Nuxt as well.

To work, I mostly use Claude. Why? Because it remains the best-rated model on the code benchmarks.

But I'm thinking about an alternative. I'll tell you more about it at the end.

Context Engineering: Constraining the AI

The idea to work effectively is to give the LLM the necessary and sufficient context to limit its solution space. We want to give it guidelines and ways to verify itself that it stays within the lines. If you don't do that, don't be surprised when the AI hallucinates APIs or uses old doc versions. It's normal.

The Claude.md file

It's the entry point. You'll find the project objective, the general structure to prevent the AI from browsing through all the code randomly, and especially the list of specs.

This list is fundamental in my development process, I'll come back to it later. It also serves as an index for Claude.

Note that I have other claude.md files in subdirectories, these files are loaded by Claude if it enters them. I have one per application (app, blog, and api). I use it to list available technologies but I tend to use rules more and more.

The Rules (.claude/rules)

These are rules that can be loaded conditionally. For example here, if Claude enters the /app directory, it loads the Nuxt rules.

In this rules file I define the patterns I want to see used, for example: obligation to use Nuxt UI, to run a typecheck or eslint pass before finishing, etc.

These rules, I built them empirically. That is, the file was empty originally, then I added rules based on the errors I saw coming back. More recently I'm trying to limit Claude's exploration so I systematically ask him if he saw patterns he should document in the rules to avoid spending tons of tokens exploring. Plus I don't really like him guessing based on the code he encounters.

Example of a question I recently asked him:

I'm looking to improve the rules I've already put in place. I find that you had to read a lot of files to understand the context and patterns. Why? Give me a summary of the patterns you were looking to understand to see if we can make them into rules

Actually, building these rules files is a kind of safety harness. But you also need to understand that it's not a guarantee because LLMs will regularly ignore rules. So you need to strengthen control means: tests, linter, CI quality gates, etc…

I note that it's easier for those used to developing with good practices to work correctly with AI. These practices serve as safeguards but for many companies, it was a bit of window dressing but not very effective in practice. And precisely, in companies where these methods aren't mature, AI doesn't take off. One wonders why... Or not…

The "Analyst" command

A command is a sort of pre-prompt. I use an analyst command for brainstorming. I ask him to be a specialist in blogging, IndieWeb and decentralization. I ask him to challenge my needs, detect inconsistencies and most importantly to write the specs.

Specs before code

Earlier I talked about specs that are listed in the claude.md file.

Let's talk a bit about my dev cycle.. I systematically go through a spec before any significant piece of code. (Funny when I think back to when I launched Malt, there wasn't much written at first…)

With AI, the spec has two major interests:

1. Frame the expected result. We first define the direction, user flows, etc.
2. Save tokens in the future: By listing the technical entry points and key files in the spec, Claude doesn't need to search everywhere.

Indeed, when Claude reworks a feature that already exists, he'll use the spec file to understand how it works and especially easily get back to the key files. With these specs, he'll save a lot of time on that, and especially it will be more accurate than letting him guess.

Once the spec is validated, I create an implementation plan (well, Claude creates a plan). For that, I have a skill that imposes my practices: each step must be deployable, it must use feature flags if necessary, etc...

The art of managing your context window

Here I need to come back to the notion of context window because it's important for optimizing your monthly budget. What costs a lot is endless sessions. With each exchange, you send back the entire history. After a while, a simple "Ok" can cost tens of thousands of tokens. So already, that costs a lot.

But the second cool side effect, the fuller the window, the "dumber" the AI becomes. So I try never to exceed 50% capacity. That's the whole point of implementation plans. The idea is to break it down into small autonomous tasks and change sessions regularly.

Skills vs MCP: The efficiency battle

I mentioned skills before. I use them heavily to be more efficient. And there's a real parallel between efficiency and cost so I need to talk about it here.

A Skill is a competency loaded on demand. For example, my Nuxt skill forces Claude to go read the doc online (in Markdown format) rather than relying on his outdated training data.

I have skills for different things:

• APIs that specify my design patterns: api-design, db-migration, write-spec

It's sometimes a bit more than "just" specifying patterns, for example the db-migration skill lists exactly which tools to use (Flyway), the location of migration files, the file format. And on the pattern side we find my key principles of deployment strategy (rolling update, etc…)

• bento, nuxt, nuxt-content, nuxt-ui to specify how to fetch the doc
• skills that explain how to use a CLI, for example sentry-fix-issues which explains how to use the sentry CLI to get information, diagnose, and fix

On the other hand, we have MCP (Model Context Protocol). It's powerful too, but it takes up more space in the context because each method of the MCP is included in the context window. Where a skill, it's only the skill description that's included.

So I prefer Skills, except for:

• MCP IntelliJ: To properly navigate code and compile.
• MCP Stripe: To debug configuration.
• Claude-mem: supposed to remember key decisions between sessions (I'm still testing, the gain isn't clear yet).

What about design?

Recently, I switched to Claude Design. It became my tool of choice. I brief, I comment on areas, I modify on the fly, and once the HTML is clean, I give it to my Claude agent for implementation. It's well above what I was doing before in simple prompting. The results are really stunning.

Balance sheet: How to stick to the budget?

In short, with all that I manage to get by for 20€ a month but I still have a few extra tricks:

• Token compression: I use compression strategies (like rtk) or I create my own tools to only send LLMs what's necessary.
• Online AIs: If I want to brainstorm "for free", I go to Gemini. I'm generally less of a fan but it can serve as a relay before going to really work with the analyst for example.

But mostly, I have an incredible trick… I close my work session when Claude tells me I've exceeded my quota. Plain and simple.

When it's done, I stop. I go do woodworking, cooking, I write an article (that's exactly what I'm doing right now ^^).

It seems like nothing but this discipline is actually healthy. I don't see it only as a constraint but also as an opportunity to do something else, think, consolidate what I've learned, etc… It joins what I wrote in a recent article, it's good to save time, but you have to know how to make the most of it.

Next step: I'm testing local models. The idea is to delegate small implementation tasks to my machine and keep Claude only for strategic planning. It's really just the beginning so I'll talk about it more later.

I'm far from being as advanced as possible on these topics and especially I'm in a solo context. But if you have your own tips to share, don't hesitate in the comments, they'll be read carefully.