Forget Tokens: The Simple Way to Manage AI Costs in FlutterFlow.

One of the most valuable aspects of working at Flywheel is the engineering culture's deep commitment to growth. The leadership team consistently encourages us to improve by providing the tools and autonomy to experiment with new technologies. Whether we test these innovations on internal initiatives or personal projects, the focus is always on the learning process itself. This culture of continuous improvement ensures we are always prepared to tackle new challenges and deliver the best possible solutions to our clients.

‍

AI is making our applications smarter than ever, but this power comes with new responsibilities. We need to be vigilant about security, performance, and especially the new costs tied to AI services. While all these areas are important, this article dives deep into one crucial question: How can we get a handle on the new expenses that AI introduces?

‍

We can take inspiration from the big AI companies and build our own system based on 'tokens' to control usage. While this gives us granular control, implementing a system to manage these transactions is complex and requires dedicated development time. The system can be broken down into the following key tasks:

‍

• Token Ledger: Create a central database to track all user token balances and transactions.
• Auth Gateway: Build a secure checkpoint that verifies a user's identity and token balance before allowing an AI call.
• Cost Estimation: Develop logic to predict the token cost of an AI task before it runs.
• User Dashboard: Design an interface for users to see their balance and usage history.
• Reconciliation: Create a background process to update balances with the final, exact cost after each AI task is complete.

‍

But we're in the NoCode and 'faster is better' market, so building all that infrastructure feels wrong. I decided to tackle this in a personal FlutterFlow project by translating the abstract idea of 'tokens' into something more familiar: a Virtual Currency. This makes it easy to set different prices based on the difficulty of the AI task.

‍

Here’s how it works in my app, 'Viste', which uses a virtual currency called 'PIN.' When a user signs up or subscribes, the system gives them a bunch of PINs. Then, every time they use a feature that hits an AI service, the application just charges them some PINs.

‍

It’s simple in practice:

‍

• Using the Bot Outfit Assistant (basic text generation): That'll be 1 PIN.
• Generating a new outfit image (a complex AI task): We can charge more, say 2 or 3 PINs.

‍

Now, you are probably wondering where the experiment is heading. I told you not to build a complex token system, and a virtual currency system sounds just as complicated, right? Don't worry, the solution is much simpler than that.

‍

We can leverage a tool that's likely already in our stack. RevenueCat, is a service that many of us use for in-app purchases in our FlutterFlow applications. RevenueCat has released a powerful new feature in beta (it is in beta at the moment I wrote this): a dedicated Virtual Currency API. This allows us to implement the entire 'PIN' system without building the backend infrastructure ourselves.

‍

Mobile Side

‍

On the implementation front, most of the heavy lifting happens in your application's backend. The FlutterFlow app itself only needs a single custom action. This action's job is to call your backend, get the user's current 'PIN' balance from RevenueCat, and determine if they can afford the AI-powered feature.

‍

A Quick Technical Note: As of this writing, FlutterFlow's default RevenueCat SDK is not the latest version and doesn't support the Virtual Currency API out-of-the-box. You have two solid options to handle this:

‍

• The Advanced Method: Connect your project to a GitHub repository, manually update the SDK version, and adjust the native code to ensure compatibility. This offers the most direct integration but requires more technical overhead.
• The Recommended Method: Create a secure Cloud Function (or Edge Function) in your backend. This function will call the RevenueCat REST API to fetch the user's balance. Your FlutterFlow app then calls this simple, secure endpoint.

‍

Dart code for a function that gets a user's "PIN" virtual currency balance from the RevenueCat SDK.

‍

Crucially, never expose your private RevenueCat API Key directly in your mobile app. The recommended method of using a backend function is the best way to keep your keys secure.

‍

Backend Side

‍

On the backend, where a secure and reliable process is paramount, a specific sequence of operations must be followed for every AI-powered request:

‍

1. Verify the Balance: Before calling the AI service, your backend should use the RevenueCat API to confirm the user has sufficient "PINs" for the requested action. This server-side check is a critical security measure and should never be left to the mobile application alone.
2. Debit the Currency: Your backend must then call RevenueCat’s "spend" API to deduct the predefined amount of "PINs" from the user's balance.
3. Execute the AI Task: Once the balance is verified, make the call to the external AI service.

‍

Curl code for calling the RevenueCat SDK API spending.

‍

However, building a fair system means planning for when things go wrong. You must remember to implement a rollback mechanism. If the AI service returns an error, your backend logic needs to automatically refund the "PINs" to the user's balance. This ensures a reliable and trustworthy user experience.

‍

‍

"VISTE" mobile application balance from the RevenueCat SDK.

‍

In conclusion, managing AI costs doesn't have to mean building a complex token system from scratch. This experiment shows that by using the concept of a virtual currency, powered by a third-party service you likely already use, you can effectively tie user consumption directly to cost. I hope this gives you a practical strategy for implementing AI features responsibly in your own projects

‍

Roberto Requena

Senior Developer

‍Author's Note: The research, ideas, and technical implementation in this article are my own. The final text was edited for clarity and flow in collaboration with Somara.ai, a Flywheel Studio product.