DEV Community: Flexprice

Why Flexprice Picked Go From Day One And Never Looked Back

Flexprice — Thu, 14 Aug 2025 13:38:41 +0000

When you're building the backbone of usage-based billing, pricing, and metering, the language you select isn't just syntax. It’s the speed, and trust baked into your product.

At Flexprice, we didn’t stumble into Go.
We chose it deliberately before a single line of code was written.

Here’s why we picked Go over the more familiar paths, how it powers our architecture today, and why we’re glad we never defaulted to Python.

We needed something production-grade from the first commit.

1. The Problem We Were Solving

From day one, we knew what we were building wasn’t a toy:

APIs that would meter high-frequency usage events in real time
Pricing engines that needed to be deterministic, fast, and scalable
Billing infra that integrates deeply with CRMs, Stripe, analytics, and internal ops
A system that could handle thousands of events per second, without choking

We didn’t want to “move fast and break things.”
We wanted to “ship fast, scale clean, and sleep well.”

2. What Were the Available Options?

We considered the usual suspects:

Python: Familiar, flexible, and widely used — but not built for concurrency at scale
Node.js: Lightweight and async-friendly, but not ideal for CPU-bound operations
Java/Kotlin: Powerful, but verbose and heavy for a fast-moving startup
Go: A compiled, modern systems language designed for cloud-scale infrastructure

Despite being less familiar to some of us, Go stood out for its simplicity and power.

We ran tests. We built a few core modules. We profiled latency, deployment, and developer experience.

The results were clear.

3. Why We Chose Go

💡
Go was everything we needed — and nothing we didn’t.

✅ Compiled performance: Near-C-level speed
✅ First-class concurrency: Goroutines and channels made parallelism feel natural
✅ Dead-simple deployment: Static binaries, no runtime issues
✅ Readable and enforced syntax: The same formatting across every file, every repo
✅ Robust tooling: Built-in race detectors, benchmarks, linters
✅ Minimal memory footprint: Runs smoothly on small container instances

Go didn’t just check boxes. It rewired how we think about backend design.

4. What It Powers Today

Here’s what we’re handling today on production:

1M+ usage events/day per customer (batch and real-time ingestion)
Pricing workflows that respond in under 50ms, even on minimal compute
High-volume API traffic integrated with Stripe, customer portals, and sales workflows
Rapid iteration across entitlements, billing logic, and packaging — with confidence

Even on 0.2 vCPU instances, Go performs like a beast.

5. How We Structured Our Go Backend

Flexprice is open source and built in Go with a modular, scalable architecture designed for high performance and easy extensibility.

You can explore the codebase here.

We’ve kept the structure intentionally clean so developers can read, adapt, and contribute with minimal friction.

Building something similar? Fork it. Want to improve it? Open a PR.

We’re building in public, and we’d love your input.

But what we got in return?

Peace of mind with every deploy
Confidence that scale won’t require rewrites
Codebases that any dev can read and extend in minutes * * *

6. The Tech Deep Dive — For Developers Who Care About the Guts

We’ve talked about why we chose Go.
Now here’s a peek into how it actually runs under the hood.

Architecture Highlights

Event Ingestion Layer
- Uses goroutines for parallel processing of incoming usage events.
- Kafka + Go consumers with backpressure handling to keep ingestion smooth at millions of events/day.
Pricing Engine
- Deterministic pricing logic, no floating-point surprises — all billing calculations are done with Go’s math/big for precise decimal handling.
- Config-driven rules so business teams can tweak pricing without touching code.
API Layer
- Built with net/http + middleware stack for logging, auth, and rate limiting.
- gRPC endpoints for high-throughput internal communication between services.
Storage & Persistence
- Postgres as the source of truth for billing and pricing configs.
- Redis for caching entitlements, pricing tiers, and in-flight usage aggregates.
Deployment
- Each service is a single static binary — no dependency hell, no runtime surprises.
- CI/CD with GitHub Actions → container builds → K8s deploys.
- Health checks + metrics exposed via Prometheus.

Performance Practices We Swear By

Pre-allocating slices and avoiding unnecessary memory allocations
Using worker pools for predictable goroutine lifetimes
Benchmarking every pricing rule with Go’s built-in testing.B suite
Leveraging Go’s pprof for real-time profiling in staging and production

TL;DR — We treat performance as a feature, not an afterthought.

Final Thoughts

We didn't just pick Go for the hype. We picked it for the long game.
Flexprice isn’t just a billing product — it’s the backbone of revenue for companies shipping AI, infra, and complex usage-based products.

And Go gives us the confidence to say:

Bring on the scale. We’re ready.

OpenAI Just Open Sourced Two New AI Models And Here's Why It Matters For AI And Agentic Companies

Flexprice — Wed, 13 Aug 2025 13:30:37 +0000

When OpenAI finally made parts of its GPT-4-class technology available as open-source models, it wasn’t just another AI release, it was a shift that the developer community had been anticipating for years.

For companies that build AI-first products, this move opens doors that were previously locked. Instead of relying solely on API calls to a black-box service, you can now run high-performing language models in your own environment, with full control over costs, compliance, and customization.

This post walks through what the new OpenAI open-source models are, why the release has spiked interest worldwide, how they perform against industry benchmarks, and how AI-first companies can deploy them efficiently.

Whether you’re exploring them for experimentation or production workloads, the goal here is to give you a practical guide to make an informed decision.

What are the OpenAI Open-Source Models?

As of August 2025, OpenAI has released two models under its open-weight program:

gpt-oss-20B: 20 billion parameters
gpt-oss-120B: 120 billion parameters

These are part of OpenAI’s open-weight initiative, meaning the trained weights are publicly available, so anyone can download, host, and run them locally. This is different from API-only access, where you rely on OpenAI’s servers and pricing. With open weights, you control deployment, cost, and compliance.

It’s also a notable shift in policy. OpenAI hasn’t released anything this large since GPT-2 in 2019 (1.5B parameters), which was a fraction of today’s scale.

Check the model card by OpenAI.

Technical highlights:

Architecture: Transformer-based, GPT-4 lineage, optimized for local and cloud hosting
Context length: Up to 128k tokens, supporting long-form reasoning and multi-document workflows
Quantization: Pre-quantized 4-bit and 8-bit versions to reduce GPU memory requirements
License: Apache-2.0, allowing commercial and non-commercial use (with OpenAI’s usage policy caveats)

Community pulse: what developers are saying

1. gpt-oss-20B

Runs well on consumer hardware (16 GB+ VRAM) “40 tokens/s on my RTX card, totally usable.”

Great for local-first workflows, but logic reasoning is weak without fine-tuning (failed classic puzzle tests, low accuracy on 11+ exam).

Non-English performance is hit-or-miss; some report slower outputs in early builds.

Benchmarks can vary. Some bloggers compare it to o3-mini, others say results depend heavily on prompt engineering.

2. gpt-oss-120B

Strong instruction following and coding capabilities: “best I’ve run locally for writing clean code.”

Can hit 30–35 tokens/s on a single 80 GB GPU; some even run CPU-only demos on high-RAM machines.

Mixed benchmark reception, certain threads show modest Simple-Bench scores (~22%), while others argue its MoE (Mixture-of-Experts) design makes it efficient for the scale.

Analysts frame it as near-parity to o4-mini on core reasoning while being deployable on a single high-end GPU

20B	Ideal Use Case	Watch-Outs
20B	Teams wanting a fast, locally-hostable model for experimentation, chatbots, summarization, or lightweight reasoning tasks.	Reasoning accuracy is noticeably lower than leading frontier models (e.g., GPT-4, Claude 3 Opus); multilingual outputs can be inconsistent without fine-tuning.
120B	Teams with 80 GB+ GPUs looking for strong instruction following, solid coding assistance, and faster inference speeds than dense models of similar size.	High hardware requirements; benchmark scores vary widely, so test on your own workloads before committing to production.

Key Features & Benchmark Highlights

Benchmark Comparisons: How gpt-oss Stacks Up

gpt-oss-120B

Reasoning & Coding: Matches or beats o4-mini; competitive with larger dense models.

HealthBench: Close to o3; outperforms GPT-4o in multiple categories.
SWE-bench Verified: 62.4% (GLM-4.5 scores 64.2%).
MMLU-Pro & AIME: Strong performance, ahead of many full-parameter models in this size class.

Strengths: Balanced across reasoning, coding, and domain-specific tasks; efficient for size due to MoE.

Limitations: Requires 80 GB+ GPU for optimal speed; benchmark gains may not translate 1:1 to all workloads.

gpt-oss-20B

Overall Performance: Comparable to o3-mini in many standard benchmarks.
Specialty Tasks: Excels in competition math and health-related reasoning.
Logic Testing: Low accuracy on UK 11+ exam (9/80 correct) without tuning.
Knowledge QA: Weak SimpleQA score, improves significantly with better prompts.

Strengths: Runs well on consumer-grade GPUs (16 GB VRAM+); ideal for local-first projects.

Limitations: Lower raw reasoning power vs. top-tier models; multilingual output inconsistent.

Key Architectural Features

Mixture-of-Experts (MoE) design: Only a subset of the total parameters is active at any given time, reducing compute cost while retaining capability.
128k token context window: Allows for very long conversations, large document processing, or multi-step reasoning chains.
Quantization options: Pre-quantized 4-bit and 8-bit weights for lower VRAM usage without a big performance hit.
Optimized attention mechanisms: Techniques like grouped query attention improve speed and efficiency for large context handling.

Analogy for Benchmarks

Think of the benchmarks like testing a car:

AIME/HealthBench scores = Top speed (peak reasoning ability)
Context window = Fuel tank size (how long it can handle complex input without running out of context)
MoE efficiency = Fuel efficiency (how much compute is needed for each “trip” of reasoning)

Reality Check

Benchmarks are controlled conditions, real-world workloads can vary.

20B may fall short on multi-step reasoning or nuanced logic without tuning
120B offers higher accuracy and more robust performance, but demands high-end GPUs (80 GB+ for optimal speed)

Business value for AI and Agentic companies

OpenAI’s gpt-oss-20B and gpt-oss-120B aren’t just research curiosities; they create practical, measurable advantages for companies building AI-first products. The biggest shift is in control: cost, compliance, and customization now sit in your hands rather than behind an API paywall.

1. Cost efficiency

API vs. Self-Hosting: Running inference locally or in your own cloud can cut per-million-token costs by 30–70% depending on GPU availability and utilization
Example: A high-traffic chatbot processing 500M tokens/month could save thousands of dollars in API fees if inference moves in-house
20B advantage: Lower hardware footprint means faster ROI for smaller teams
120B advantage: Higher accuracy per token processed means fewer retries and corrections

2. Compliance & data control

Self-hosting means sensitive data never leaves your infrastructure
Meets stricter requirements for sectors like finance, healthcare, and government without complex vendor contracts
Open-weight Apache-2.0 licensing (with OpenAI usage policy) simplifies legal review vs. closed, API-bound services

3. Customization and fine-tuning

Both models can be fine-tuned for domain-specific language, terminology, or compliance filters
Custom embeddings and retrieval-augmented generation (RAG) pipelines can be integrated without third-party API constraint.

Bottom line: For AI and agentic companies, these models lower the unit economics of running advanced LLM features, improve compliance posture, and unlock pricing flexibility, without sacrificing core capability.

Deployment and compliance checklist

If you’re planning to deploy gpt-oss-20B or gpt-oss-120B in production, treating them like any other enterprise-grade software stack will save you time.

1. License & Policy Review

Apache-2.0 license: Permissive for both commercial and non-commercial use
OpenAI usage policy: Certain applications (e.g., generating misinformation) remain prohibited even with open weights
Action: Get legal confirmation that your intended use aligns with both

2. Hardware Requirements

gpt-oss-20B: Runs on GPUs with ≥16 GB VRAM; suitable for a single workstation or small cloud instance
gpt-oss-120B: Requires an 80 GB GPU or multi-GPU setup for real-time performance
Action: Decide between local deployment, cloud GPUs, or hybrid infrastructure

3. Data Residency & Privacy

Ensure all processing happens in approved geographic regions for compliance (e.g., GDPR, HIPAA)
For sensitive data, deploy in a private VPC or on-prem hardware

4. Observability & Monitoring

Log prompt/response pairs for auditing
Track token usage, latency, and failure rates
Set alerts for unusual activity (e.g., rapid token spikes from one client)

5. Security Hardening

Isolate model servers from public networks
Use API gateways or auth layers for access control
Regularly patch hosting environment and supporting libraries

Wrapping up

OpenAI’s gpt-oss release signals a broader shift, one where high-performance models aren’t locked behind API gates but can be run, adapted, and monetized on your own terms. The move also sets a precedent: after years of partial openness, OpenAI has now shown it’s willing to bring frontier-adjacent capability into the public domain.

Looking ahead, expect three trends:

Multimodal open weights, future releases may integrate text, image, and audio processing in a single package.
Specialized domain variants, healthcare, finance, and legal-tuned versions optimized for compliance-heavy industries.
Ecosystem tools, better fine-tuning kits, quantization methods, and observability frameworks to accelerate real-world adoption.

For AI-first companies, this is a moment to test and embed these models into workflows before the next release cycle reshapes the playing field.

The first movers here will gain not just cost and control advantages, but also the credibility that comes from delivering cutting-edge AI without reliance on opaque third-party infrastructure.

The Complete Guide to ElevenLabs Plans Overages and Usage Based Pricing

Flexprice — Fri, 08 Aug 2025 12:29:38 +0000

ElevenLabs is a leading AI audio platform known for its lifelike voice generation, real-time cloning, and multilingual dubbing. Whether you're a solo creator or an enterprise team, it offers the infrastructure to generate and scale voice-based content.

In this guide, we will break down the full pricing model: plan comparisons, overage logic, voice model differences, and how to choose the right tier (or replicate this pricing system for your own SaaS).

What is ElevenLabs?

ElevenLabs is an AI audio platform offering hyper-realistic text-to-speech (TTS), voice cloning, dubbing, and transcription.

It is used by creators, developers, and enterprises looking to generate or manipulate voice content at scale.

Key capabilities include:

High-fidelity TTS across 29+ languages
Instant and professional-grade voice cloning
Multilingual dubbing and conversational AI
Developer-friendly APIs and usage-based pricing
Audio enhancement tools like Voice Isolator and Voice Changer

Who is ElevenLabs Built For?

ElevenLabs supports a wide range of users across creative and technical workflows:

Creators: Narrators, YouTubers, podcasters, and indie game devs
Developers: API-first teams building apps with voice integration
Agencies: Managing dubbing, client content, and production at scale
Enterprises: Building multilingual content and support flows
Platforms: Embedding voice features into SaaS or marketplaces

Each of these groups benefits from ElevenLabs’ flexible plans and real-time performance.

ElevenLabs Pricing Plans (Monthly Overview)

Plan	Price	Characters (TTS)	Overages	Voice Cloning	Audio Quality	Seats	Concurrency
Free	$0	10k (Multilingual) / 20k (Flash)	N/A	❌	128 kbps	1	2
Starter	$5	30k / 60k	N/A	Instant Clone	128 kbps	1	3
Creator	$11 (50% off month 1)	100k / 200k	$0.30 / 1k chars	1 Pro Clone	192 kbps	1	5
Pro	$99	500k / 1M	$0.24 / 1k chars	1 Pro Clone	192 kbps	1	10
Scale	$330	2M / 4M	$0.18 / 1k chars	1 Pro Clone	192 kbps	3	15
Business	$1,320	11M / 22M	$0.12 / 1k chars	3 PVCs	192 kbps, SLAs	15+	15
Enterprise	Custom	Custom	Negotiated	Custom	Custom	Custom	Custom

Is ElevenLabs free?

Feature	Free Plan
Characters	10k (Multilingual) or 20k (Flash)
Voice Cloning	Not available
Commercial Use	Forbidden (attribution required)
Audio Quality	128 kbps
STT Access	2.5 hours (API), 12 mins (UI)
Projects	3
Custom Voices	3
Concurrency	2 requests max

How ElevenLabs Prices Across Models and Features

ElevenLabs doesn’t just charge by output—it charges by model type and feature usage. Each product category—like Text-to-Speech or Dubbing—has its own pricing logic based on characters, minutes, or hours. And within each, there are two pricing levers:

→ Included quota (per plan)
→ Overage cost (per unit after quota)

Here’s how pricing breaks down by model and feature:

1. Text-to-Speech (TTS)

Models: Multilingual v2 and Flash
Billing unit: Characters and minutes

Speech-to-Text (STT) Interfaces:

API- used for large-scale, automated transcriptions
UI- manual uploads with waveform preview and editing Metered by: Hours Available on: All plans

Other details:

Quotas tracked separately for API and UI
UI access comes with significantly lower included volume
Optimized for dev vs creator workflows respectively

3. Conversational AI

Use case: Interactive text+voice agents
Metered by: Minutes
Additional meter: Text messages sent
Other details:

Includes concurrency limits (up to 30)
Designed for real-time voice agent applications
Available across all plans, scaling with usage

4. Voice Changer & Voice Isolator

Metered by: Minutes
Available on: All plans
Other details:

Both tools accessible via Studio & API
Intended for enhancing, isolating, or transforming audio post-generation
Concurrency limits increase with plan

5. Sound Effects

Metered by: Number of generations
Available on: All plans
Other details:

Sound FX feature is generation-based (not duration-based)
Useful for creative workflows and post-processing
Scales with concurrency and generation limits

6. Voice Cloning

Types of cloning:

Instant Clones – lightweight, accessible to all paid plans
Professional Voice Clones (PVCs) – gated to Creator+ plans Other details:
Access includes voice design slots and custom voice limits
Plan tiers increase allowed PVCs and total voice slots
Custom voices can be stored, designed, and reused across projects

7. Dubbing

Automatic Dubbing – real-time multilingual audio generation
Dubbing Studio – advanced interface for post-editing and alignment Metered by: Minutes Other details:
Audio quality scales by plan
Both models available from Starter upwards
Ideal for creative, education, and international content workflows

8. Studio Projects

Metered by: Number of projects
Other details:

Quotas range from basic project folders to enterprise-scale workflows
Enables large-scale voice asset management and production workflows
Feature-rich access in Creator+ plans and above

Read the detailed breakdown of ElevenLabs pricing and also how you can replicate it within minutes with Flexprice.

The Complete Guide to ElevenLabs Plans Overages and Usage Based Pricing

Flexprice — Fri, 08 Aug 2025 12:29:38 +0000

What is ElevenLabs?

ElevenLabs is an AI audio platform offering hyper-realistic text-to-speech (TTS), voice cloning, dubbing, and transcription.

It is used by creators, developers, and enterprises looking to generate or manipulate voice content at scale.

Key capabilities include:

High-fidelity TTS across 29+ languages
Instant and professional-grade voice cloning
Multilingual dubbing and conversational AI
Developer-friendly APIs and usage-based pricing
Audio enhancement tools like Voice Isolator and Voice Changer

Who is ElevenLabs Built For?

ElevenLabs supports a wide range of users across creative and technical workflows:

Creators: Narrators, YouTubers, podcasters, and indie game devs
Developers: API-first teams building apps with voice integration
Agencies: Managing dubbing, client content, and production at scale
Enterprises: Building multilingual content and support flows
Platforms: Embedding voice features into SaaS or marketplaces

Each of these groups benefits from ElevenLabs’ flexible plans and real-time performance.

ElevenLabs Pricing Plans (Monthly Overview)

Plan	Price	Characters (TTS)	Overages	Voice Cloning	Audio Quality	Seats	Concurrency
Free	$0	10k (Multilingual) / 20k (Flash)	N/A	❌	128 kbps	1	2
Starter	$5	30k / 60k	N/A	Instant Clone	128 kbps	1	3
Creator	$11 (50% off month 1)	100k / 200k	$0.30 / 1k chars	1 Pro Clone	192 kbps	1	5
Pro	$99	500k / 1M	$0.24 / 1k chars	1 Pro Clone	192 kbps	1	10
Scale	$330	2M / 4M	$0.18 / 1k chars	1 Pro Clone	192 kbps	3	15
Business	$1,320	11M / 22M	$0.12 / 1k chars	3 PVCs	192 kbps, SLAs	15+	15
Enterprise	Custom	Custom	Negotiated	Custom	Custom	Custom	Custom

Is ElevenLabs free?

Feature	Free Plan
Characters	10k (Multilingual) or 20k (Flash)
Voice Cloning	Not available
Commercial Use	Forbidden (attribution required)
Audio Quality	128 kbps
STT Access	2.5 hours (API), 12 mins (UI)
Projects	3
Custom Voices	3
Concurrency	2 requests max

How ElevenLabs Prices Across Models and Features

→ Included quota (per plan)
→ Overage cost (per unit after quota)

Here’s how pricing breaks down by model and feature:

1. Text-to-Speech (TTS)

Models: Multilingual v2 and Flash
Billing unit: Characters and minutes

Speech-to-Text (STT) Interfaces:

API- used for large-scale, automated transcriptions
UI- manual uploads with waveform preview and editing Metered by: Hours Available on: All plans

Other details:

Quotas tracked separately for API and UI
UI access comes with significantly lower included volume
Optimized for dev vs creator workflows respectively

3. Conversational AI

Use case: Interactive text+voice agents
Metered by: Minutes
Additional meter: Text messages sent
Other details:

Includes concurrency limits (up to 30)
Designed for real-time voice agent applications
Available across all plans, scaling with usage

4. Voice Changer & Voice Isolator

Metered by: Minutes
Available on: All plans
Other details:

Both tools accessible via Studio & API
Intended for enhancing, isolating, or transforming audio post-generation
Concurrency limits increase with plan

5. Sound Effects

Metered by: Number of generations
Available on: All plans
Other details:

Sound FX feature is generation-based (not duration-based)
Useful for creative workflows and post-processing
Scales with concurrency and generation limits

6. Voice Cloning

Types of cloning:

Instant Clones – lightweight, accessible to all paid plans
Professional Voice Clones (PVCs) – gated to Creator+ plans Other details:
Access includes voice design slots and custom voice limits
Plan tiers increase allowed PVCs and total voice slots
Custom voices can be stored, designed, and reused across projects

7. Dubbing

Automatic Dubbing – real-time multilingual audio generation
Dubbing Studio – advanced interface for post-editing and alignment Metered by: Minutes Other details:
Audio quality scales by plan
Both models available from Starter upwards
Ideal for creative, education, and international content workflows

8. Studio Projects

Metered by: Number of projects
Other details:

Quotas range from basic project folders to enterprise-scale workflows
Enables large-scale voice asset management and production workflows
Feature-rich access in Creator+ plans and above

Read the detailed breakdown of ElevenLabs pricing and also how you can replicate it within minutes with Flexprice.

We've Raised $500K to Build the Open-Source Billing Stack for AI and Agentic Companies

Flexprice — Wed, 30 Jul 2025 13:40:11 +0000

The AI world is changing fast. Generative AI and agentic platforms are shipping at an insane pace, but one thing remains painfully slow—billing.

Most teams still lose weeks (or months) patching pricing logic, debugging invoice flows, and trying to make legacy billing tools work for AI or API-first models. These tools were never built for the new era of usage-based, credit-driven, or outcome-based pricing.

We’re fixing that.

Why We’re Building Flexprice

Flexprice is an open-source billing and metering platform designed for AI and agentic companies. Whether you’re running a GPU-intensive API service, a credits-based SaaS model, or hybrid subscriptions, you shouldn’t need to reinvent billing logic every time your pricing evolves.

Our mission is simple: pricing, packaging, and billing should never be a bottleneck.

We’re building:

Real-time usage metering – Track GPU hours, API calls, or any custom metric without building a billing team.
Multiple pricing models – Pay-as-you-go, credits, seats, or tiered pricing—out of the box.
Open-source control – Self-host, fork, or customize as you want. No vendor lock-in.
Transparent analytics and invoice visibility – For both customers and internal teams.

The $500K Raise

We just raised $500,000 in a round led by TDV Partners, with support from angel investors like:

Brij Bhushan (Cofounder, Magicpin)
Sandeep Gupta (Cofounder, Innovaccer)
Harshit Dwivedi (Founder, Aftershoot)

This funding isn’t about “growth at all costs.” It’s about building the most developer-friendly, open billing stack out there—and scaling our open-source ecosystem.

“The ability to move fast with pricing and scalable billing plays a critical role for AI and agentic teams. Flexprice is built to ensure billing is never the blocker,”
— Manish Choudhary, CEO

Why Open-Source Matters in Billing

Legacy billing tools don’t scale with modern pricing models. If you’ve ever built something with Stripe, you know how fast complexity creeps in:

Want credits + usage + tiered add-ons? You’re writing custom logic.
Want to change pricing mid-quarter? You’re debugging invoices at 2 AM.
Want transparency? Good luck with the black box.

We believe billing should be owned by developers, not locked behind opaque SaaS APIs.

With Flexprice, you can self-host, extend features, or contribute to the core. It’s your stack.

What’s Next

Here’s where the next phase of Flexprice is headed:

Scaling the open-source repo – We’re doubling down on GitHub contributions, developer guides, and templates.
Advanced billing workflows – More flexibility for credits, prorations, and real-time pricing experiments.
Developer-first distribution – Hackathons, technical blogs, and open demos.

We’re already powering AI-first startups like Wizcommerce, Simplismart, ThePubLive.com, and Verniq.ai, and we’re just getting started.

If you’re building AI, agentic, or API-first products, we’d love your feedback and contributions.

Check out our GitHub
Join our community

Star the repo if you believe in open billing infrastructure.

Stripe vs. Flexprice: The Better Fit for Hybrid and Credit-Based Models

Flexprice — Fri, 25 Jul 2025 11:00:34 +0000

Stripe made subscriptions easy. It gave developers a clean way to set up recurring payments without building everything from scratch. For seat-based pricing and flat monthly plans, it’s still hard to beat.

But SaaS pricing has evolved. Credits, usage-based limits, and dynamic entitlements are now standard. What once looked like a simple “plan” has turned into a bundle of features, credits, and usage thresholds that reset, roll over, and change often.

This post explores where Stripe’s plan-based model starts to show cracks in this new world, and how Flexprice was built to handle these modern pricing structures out of the box.

Feature Entitlements

Stripe was built for seat-based pricing, simple flat subscriptions.

Modern SaaS runs on hybrid models: a base plan plus usage-based components like credits or compute time. Plans are now dynamic entitlements tied to infrastructure usage.

Stripe’s plan-centric architecture just doesn’t work here. It can’t natively model feature-level entitlements or enforce usage limits, forcing teams to patch together custom metering and billing logic.

Let’s take InVideo’s pricing as an example. Each tier doesn’t just define a price, it controls how many credits a user gets, how many video minutes they can process, and how much access they have to generative video features.

Plus Plan: 10 credits, 50 video minutes, 30 seconds of generative video.
Max Plan: 40 credits, 200 video minutes, 120 seconds of generative video.
Generative Plan: 100 credits, 300 seconds of generative video.
Team Plan: 1000 credits, 50 minutes of generative video.

This structure is already more complex than Stripe’s default pricing model can handle because every plan combines multiple entitlements credits, minutes, and feature access all with their own limits.

Now, if you had to build this with Stripe

Here’s what it would take:

Create a separate plan for each combination of credits and video minutes.
- One for Plus (10 credits, 50 mins).
- One for Max (40 credits, 200 mins).
- And so on for Generative and Team.
Add generative video as another “metered feature” per plan.
- Stripe doesn’t let you define “30 seconds vs. 120 seconds” of usage per plan without building custom logic.
- You’d have to track it manually and sync with Stripe invoices.
Experimentation becomes painful.
- If you change Max credits from 40 to 60, every cloned plan, entitlement reference must be updated across your billing and invoices.

The complexity compounds as soon as you introduce even two variables (credits + video minutes) plus a third feature (generative video). What looks simple on InVideo’s pricing page becomes 4–6 separate Stripe plans plus custom metering scripts.

How Flexprice Handles It

With Flexprice:

You define credits, video minutes, and generative video as separate entitlements.
In every plan you simply link the feature as an entitlement with specified usage limits along with the usage reset period if necessary.
Add-ons work out-of-the-box; a user can buy extra credits or minutes without touching their base plan.
Usage tracking is automatic; credits, video minutes, and generative limits are all monitored and handled without building custom infrastructure.
And if you want to experiment with pricing, you can update the entitlement once, and Flexprice updates it everywhere.

Your engineering team doesn’t waste cycles syncing pricing logic across multiple layers; it all lives in one open-source system designed for dynamic SaaS and AI workflows.

Recurring & One-Time Credits

Credit-based pricing is common for AI and SaaS platforms. Instead of charging per feature or API call directly, companies allocate credits that customers spend as they consume resources (e.g., 1 video export = 5 credits).

There are typically three types of credits in such systems:

Sign-up credits – Free credits given during account creation or trials.
Promotional credits – Bonus credits for campaigns or referrals.
Paid credits – Credits purchased directly, either as a one-time pack or recurring monthly allocation.

Where Stripe Falls Short:

Stripe supports one-time credits (via Customer Balance Transactions) and promotional credits, but there’s no native way to offer recurring credits tied to monthly or annual subscriptions.
Credit rollover is impossible. If a user doesn’t use all credits this month, Stripe doesn’t allow automatic carry-over to the next cycle.
No wallet threshold logic. You can’t set “minimum wallet balances” to automatically top up when the balance drops below a certain amount or trigger alerts.
Every aspect of credit tracking; allocation, expiry, consumption, and top-ups must be built outside Stripe, increasing complexity.

How Stripe Handles It

To simulate recurring credits or wallet thresholds, you’d have to build your own credit management layer and wire it to Stripe’s APIs:

Recurring Credits Hack:
- Use Stripe’s subscription events (e.g., invoice.payment_succeeded) as a trigger to manually allocate credits in your database each month.
- Handle rollover logic yourself (carry unused credits, enforce expiry).
Wallet Threshold Monitoring:
- Continuously track customer balances on your own system.
- When a balance falls below your threshold:
  - Create a charge to the customer’s default payment method.
  - Apply that amount as a credit via the Customer Balance Transactions API.
  - Adjust the customer’s wallet balance and reflect it in your product dashboard.
- Example flow:
  - Monitor balances via webhooks or cron jobs.
  - Create a PaymentIntent to charge the saved card when balance < X.
  - Once successful, add credits manually as a ledger adjustment.
No Native Alerts: You’d have to implement notifications for low balances using custom logic and event triggers.

How Flexprice Solves It

Native Recurring Credits:
- Allocate monthly or annual recurring credits automatically as part of a subscription or plan (e.g., 2,000 credits per month).
- Credits can roll over with configurable caps (e.g., unused credits roll over up to 5,000 max).
Built-in Credit Wallets:
- Track sign-up, promotional, and paid credits in one wallet with full transparency.
- Credits can expire automatically based on rules (e.g., promotional credits expire in 30 days).
Threshold Alerts & Auto Top-ups:
- Define minimum balance thresholds (e.g., auto top-up when wallet < 100 credits).

Custom Credits

When you introduce credits, sign-up, promotional, and paid you initially treat them as simple tokens of value. They work well to allocate usage, but soon another challenge surfaces: your underlying infra costs aren’t uniform.

Use Case 1: Creating a table uses 50 tokens but costs you almost nothing in GPU time.
Use Case 2: Enriching rows uses fewer tokens but significantly more GPU—making it expensive on your side.

Yet you charge the customer the same way. And eventually someone from your finance team highlights this issue, “We’re bleeding money on certain actions because the cost to run them is higher than what we bill for.”

And for you the obvious fix is charge per resource directly, per token, per GPU second, per premium model.

$0.01 per token.
$0.10 for <10 GPU seconds, $0.15 for 10–15s, $0.25 for >15s.

But now your pricing page reads like a data center tariff sheet too complex for anyone to understand.

But when a customer gets a $100 bill and thinks, ““I don’t understand what I’m being charged for. Tokens? GPU seconds? Why is this so complicated?”

And it results in lost trust and churn, even if the pricing is technically fair.

To simplify, you stop exposing tokens, GPU seconds, or model costs to customers. Instead, you abstract everything into credits.

1 credit = $0.05
Table creation = 50 credits.
Row enrichment = 100 credits.
Premium model call = 200 credits.

Internally, you still map credits to infra cost variables, but the user only sees:

“You used 2,000 credits this month = $100.”

This model keeps your pricing predictable for customers while protecting margins on the backend.

How Flexprice Powers This

Credits as a native abstraction layer: Tokens, GPU time, and other variables are auto-converted to credits.
Support for fiat and custom pricing: Credits can map to dollars, rupees, or non-monetary units.
Dynamic pricing updates: Adjust the credit cost of actions without touching plans or usage rules.
Cleaner invoicing: Customers see a single credit balance instead of 4–5 line items with technical metrics.

The Clean Way to Handle Pricing Complexity

Stripe will always have its place, it’s reliable, battle-tested, and perfect for simple subscriptions.

But as soon as your pricing moves beyond flat plans, Stripe demands workarounds, custom scripts, and manual syncs that drain engineering time.

Flexprice was built for this new reality, where entitlements, credits, and usage-based pricing are the norm.

It removes the complexity while giving you full control and visibility. No cloned plans, no duct tape, just a system that adapts as your pricing evolves.

If you’re tired of fighting your billing stack every time you run an experiment or roll out a new feature, it might be time to see what Flexprice can do.

⭐ Star us on GitHub to follow our progress
🤝 Join our community to share feedback and collaborate

7 Reasons Why Stripe Will Break Your Billing Logic

Flexprice — Wed, 23 Jul 2025 17:02:52 +0000

Stripe Billing was built around one core assumption: your pricing is seat-based and your revenue is predictable.

The architecture reflects that. Plans are the top-level object. Usage is optional metadata. Invoicing is tied to a fixed billing cycle.

That’s fine, until it isn’t.

The moment your pricing starts evolving frequently whether you’re changing the metric you bill on, experimenting with new pricing models, or enabling real-time credit-based pricing. Developers end up writing custom code on top of Stripe’s existing logic just to keep up.

Every new change becomes a patchwork fix, pulling engineering focus away from your core product and turning billing into a constant distraction.

It’s not just inconvenient. It’s fragile.

This post breaks down the technical constraints in Stripe’s billing model, and why teams moving to usage-based pricing eventually outgrow it.

1. Stripe Is Natively Built for Seat-Based Billing, Not Complex Pricing

Stripe works well for simple pricing like $X per user/month, but it struggles when you mix fixed subscriptions with usage-based charges or credits.

Hybrid plans like when you combine a monthly base plan with a usage based pricing model aren’t supported natively. You end up patching together separate subscriptions, usage records, and manual calculations just to make the math work.

Example:

Suppose you offer a $99/month subscription that includes 5,000 API calls. If a customer needs more, they pay $0.01 per extra call.

You have to track base credits and overages outside Stripe. Customers only see their final charges when the invoice is generated—no real-time visibility, no clarity.

Where Flexprice Helps:

Flexprice handles hybrid plans out of the box. It automatically combines base allowances with real-time usage tracking, so customers always know how much they’ve used and what’s left. No custom code or messy backend logic needed.

2. No Granular Filtering Within Usage Events

Stripe doesn’t allow you to filter or segment data within a single usage event.

Suppose you want to price GPT‑4 Turbo requests differently from o1‑mini requests, or charge based on multiple parameters like input tokens vs. output tokens.

Stripe forces you to create separate usage schema (meters) for each variant, duplicating logic in your backend just to map the correct usage stream to the correct metric.

For AI or API-first companies with dozens of models or multi-parameter billing rules, this becomes a scaling nightmare.

Where Flexprice Helps:

Flexprice supports property-based filters directly on events. You can send a single event stream (e.g., api_call) with metadata like model: "gpt-4-turbo" or model: "o1-mini", and Flexprice will apply pricing dynamically, no redundant event duplication or brittle backend mapping.

3. Pricing Iterations Are Painful in stripe

Stripe treats pricing as rigid and immutable.

If you need to frequently update pricing for your product, roll out a new feature, or change the billing metric, say from number of tokens to GPU time you’ll have to create a new Price object and migrate every customer manually.

This isn’t just slow, it’s operationally expensive and introduces unnecessary complexity into your billing logic.

Example:

An AI platform decides to switch from per-token billing to per-inference billing.

With Stripe, they need to spin up new price objects, reassign customers, and keep old and new logic running in parallel. This introduces bugs and billing mismatches.

Where Flexprice Helps:

Flexprice supports dynamic pricing updates and versioning. You can introduce new metrics or tweak pricing attributes without customer migrations.

Historical invoices remain untouched, while new billing cycles automatically reflect updated pricing logic.

4. No Native Credit Rollover System

Stripe has no built-in concept of credit rollover, meaning you have to manually handle all the logic. To make rollover work, you’d need to custom code a workflow like this:

Use Credit Grants to allocate credits to customers.
At the end of each billing cycle, check for unused credits.
If there are unused credits, create a new Credit Grant with the remaining balance to carry them forward.

This process becomes messy, especially when you want to impose rollover caps or expiration rules. Any miscalculation or missed job in this logic can lead to billing errors or disputes.

Example:

Take Clay’s Starter Plan ($149/month) with 2,000 credits/month and rollover up to 2x.

Month 1: 2,000 credits allocated, 1,000 used
Month 2: 1,000 rollover + 2,000 new = 3,000 total credits
Month 3: Max rollover cap of 4,000 credits (2x monthly allocation)

Stripe can’t natively enforce this “carry-over but capped” logic. You’d need to hack it together with custom scripts, usage tracking, and manual adjustments, an error-prone process.

Where Flexprice Helps:

Flexprice supports credit rollover out of the box with configurable caps and expiration rules. You can set conditions like:

Credits expire after 2 months (regardless of usage)
Credits remain valid only during active subscriptions (forfeited on cancellation)

This ensures accurate credit tracking without backend workarounds, while giving customers real-time visibility into their remaining credits.

5. Limited Customization in Invoicing and Reporting

Stripe invoices are rigid. Auto applying taxes from organization, customer or retroactively correcting invoices is a pain.

Invoice regeneration isn’t supported, you have to issue credits or manual adjustments.

Example:

Your customer’s invoice needs to display a breakdown of usage by feature (e.g., text vs. image generation). Stripe doesn’t support this granularity without manually injecting line items every cycle.

Where Flexprice Helps:

Flexprice offers customizable invoicing, supports granular line items, real-time invoice recalculation, and flexible credit notes, ensuring billing matches the product’s usage data.

6. No Native Entitlements (Feature Access Management)

Stripe isn’t built to handle feature-level entitlements. It only knows how to bill for quantities, not who gets access to which feature, how many times, or under what conditions.

For any kind of entitlement logic, you’re left building custom gating and tracking outside Stripe, turning billing into a Frankenstein setup of cron jobs, feature flags, and backend checks.

Take Beatoven AI. Their pricing model includes 15 minutes of music generation per month for the Creator plan and 30 minutes for higher tiers, with an option to “buy minutes” on demand.

Stripe can’t enforce such limits natively. It treats features and usage meters as disconnected, forcing engineering teams to manually track remaining minutes, block access when quotas are hit, and reconcile everything with Stripe’s invoices.

Where Flexprice Helps:

Flexprice combines billing and entitlement logic into a single, usage-aware layer. You can define plan-level limits, assign feature entitlements, and enforce gating in real time.

When a user hits a workflow limit or tries to use a feature outside their plan, Flexprice can help in preventing overages or trigger a paywall, without needing a tangle of backend hacks.

7. Flexprice Won’t Lock You Into Stripe Payments

Using Stripe Billing means you’re tied exclusively to Stripe Payments, you can’t collect payments through other processors for the invoices you issue.

This becomes a problem if you want to offer local payment methods in certain geographies that Stripe doesn’t support, or if you want leverage to negotiate lower fees by using alternative processors.

Flexprice is payment-agnostic. You can connect it to any payment processor, whether it’s Stripe, PayPal, Razorpay or a custom solution.

This gives you the freedom to switch processors, use multiple providers, or adapt your payment stack as your company grows without being locked in.

Flexprice is Built to Handle The Complex, Real-Time Billing Workflows That Stripe Can’t

Stripe has certain limitations, and it’s built for a different stage of SaaS billing. Flexprice, on the other hand, was designed from the ground up for real-time, usage-based, and hybrid pricing models.

It doesn’t force you to work around its limitations. Instead, it provides the building blocks for metering, credit management, invoicing, and pricing experiments at scale without duct tape or hacks.

Whether it’s streaming millions of usage events, updating pricing metrics mid-cycle, regenerating invoices, or offering customers a real-time view of their credit consumption, Flexprice ensures billing evolves at the same speed as your product.

1. Real-Time Usage Metering and Credit Management

Supports usage based billing every API call, token, or compute cycle can trigger immediate metering.
Tracks prepaid and postpaid credits, deducting balances live instead of relying on end-of-cycle aggregation.
Eliminates the need for custom Redis stores or cron jobs for usage reconciliation.

2. Support Event Ingestion at Scale

Can ingest usage events at very high RPS without rate-limit bottlenecks.
Built for streaming data pipelines.
Handles spikes without data loss, ensuring every event is accounted for in real time.

3. Dynamic Pricing and Plan Versioning

Allows you to roll out new pricing models instantly without creating multiple Price objects or migrating customers manually.
Supports versioning with audit logs, so you can track what pricing changes happened, when, and for whom.
Enables segmented pricing experiments (e.g., new customers in APAC vs. US) with zero additional engineering overhead.

4. Invoice Recalculation and Transparency

Regenerate invoices mid-cycle when usage changes, credits are topped up, or anomalies need correction.
Supports customized invoice line items breaking down usage by feature, event type, or product module.
Offers transparent audit trails for every event and adjustment, so finance and support teams can see exactly how the final bill was computed.

5. Developer-Centric Billing Layer

Designed with clean APIs that let engineers integrate billing directly into their product workflows.
Provides dashboard-level visibility for both customers and internal teams no need to build shadow dashboards for usage debugging.
Works as a modular layer on top of Stripe’s payments, so you don’t have to rebuild payment processing.

6. Hybrid and Complex Billing Models

Built for credit-backed pricing with real-time upgrades and top-ups.
Handles multi-dimensional pricing metrics (e.g., API call + storage + compute time) without requiring separate objects for each metric.
Supports daily or weekly pricing adjustments with no disruptions to existing billing flows.

Where we are, and what’s next

We recently launched five foundational features in five days as part of our Commit Launch. Check that out!

Each of these features reflects months of conversations with teams navigating real billing pain, engineers trying to bridge gaps with glue code and finance leaders fighting for visibility into revenue.
This momentum is just the start.

Our public roadmap is open for a reason. We want you to build with us. You can see what’s coming, suggest what should come next, and track how we prioritize across use cases.

We believe billing infra should evolve in the open, visible, extensible, and aligned with how real teams ship pricing.

If you're tired of solving billing from scratch, or maintaining a fragile Stripe wrapper that can't handle your edge cases, you don’t have to keep doing it alone.

⭐ Star us on GitHub to follow our progress
🤝 Join our community to share feedback and collaborate

Flexprice testing

Flexprice — Mon, 21 Jul 2025 11:37:05 +0000

Hello world 2

Flexprice

Flexprice — Mon, 21 Jul 2025 11:34:57 +0000

Hello world

Why is Billing An Engineering Problem?

Flexprice — Thu, 17 Jul 2025 10:21:58 +0000

Billing looks simple at the start. One product. One plan. A handful of customers. You wire up Stripe, push some configs, and move on. It works, until it doesn’t.

As your product evolves, so does your pricing. You experiment with usage tiers, roll out regional pricing, introduce AI-related credits, or move to prepaid wallets.

The marketing and product teams treat pricing as a growth lever which it is, but behind every pricing change is a billing implication that someone on the engineering team has to handle.

What starts as a clean setup becomes a patchwork of overrides, edge case conditionals, and spreadsheet-based fixes.

Billing logic doesn’t break all at once, it accumulates debt slowly, until a single customer complaint forces you to trace logic across Stripe configs, backend services, and support notes.

And suddenly, you’re debugging a “routine invoice issue” at 2 a.m. because someone on Slack said the numbers look off.

That’s the trap. You think billing is solved when the invoice goes out.

But real billing logic touches every critical system revenue, product behavior, finance workflows, and customer trust. And no one team fully owns it.

That’s what makes billing an engineering problem.

The Illusion of Simplicity

At a glance, billing feels like a solved problem.

You multiply usage by price. You send an invoice. Done.

Except, real-world billing logic is anything but simple. It doesn’t live in one place. It doesn’t follow one model. And it certainly doesn’t stay stable.

The moment your pricing strategy evolves, your systems need to know:

What qualifies as billable usage?
Do credits apply before or after usage thresholds?
Is this customer on an old grandfathered plan or the new rollout?
Do we bill on calendar cycles or based on subscription start dates?

These aren’t questions you answer once. You revisit them every time product launches a new feature, or sales experiments with a new deal structure.

And yet, billing logic, arguably the most sensitive module in your system is split across:

Stripe configs that abstract complexity behind dropdowns
Backend services with hardcoded overrides
Airtable sheets tracking credits
Notion pages for the support team
And Slack threads where bugs go to hide

By the time something breaks, it’s no longer about “who wrote this logic.” It’s “where is this logic even defined?”

Why Engineers Always End Up Owning Billing

No one sets out to make billing an engineering problem. But they inevitably do.

Here’s the reality most teams live through:

Pricing changes come more often
Overrides start as exceptions but become business-as-usual.
Each team “solves” their part in isolation, and the glue lives in engineering.

So even though the ownership is distributed, the blast radius isn’t.

When finance can’t explain a refund, product can’t version a plan, or customer support gets asked why two users were billed differently, engineering gets pulled in.

Every billing sprint feels like a root-cause investigation of something you never intended to build in the first place.

Basic Billing Tools Don’t Help

Most basic SaaS billing platforms come with a fatal assumption: You’ll mold your pricing to fit their UI.

But real pricing doesn’t look like dropdowns and toggles.

It looks like:

Hybrid models mixing usage-based and seat-based billing
Limited-time grants with conditional expiry rules
Custom invoice logic for specific enterprise deals
Multiple billing cycles coexisting in the same account

To get that working in most systems, you end up doing one of two things:

Exporting data, transforming it in code, and uploading results manually
Writing glue code that sits between your billing provider and the rest of your stack
Neither scales. Both increase fragility. And neither gives you answers when things go wrong.

Worse, there’s no way to test invoice outputs before sending them.
You’re just trusting that your conditionals and Stripe configs align perfectly.

What Infra-Grade Billing Should Look Like

If billing affects revenue, customer experience, and finance workflows, it needs to be treated like infrastructure.

That means:

Every credit rule and aggregation logic is source-controlled
You can simulate invoice outputs before pushing to production
Your business rules live in one system, not scattered across four
You have visibility into “why” an invoice was calculated the way it was

This isn’t about building your own Stripe. It’s about building the thing around Stripe that every engineering team duct tapes eventually.

How We Built Flexprice

Flexprice is our take on what a real billing engine should look like when treated as infrastructure, not as an afterthought.

It gives you:

Composable logic blocks for usage, credits, wallets, and plans
Custom aggregation strategies like count unique, latest, sum, or plug in your own
Wallet-based accounting to track balance changes in real time
Grant systems to attach credits to plans or offer one-time incentives
Invoice generation for both calendar-aligned and rolling subscriptions
Offline payment support with full balance reconciliation

And everything is:

Inspectable
Testable
Source-controlled

You get the flexibility to model your own logic, not just configure someone else’s abstraction. Because pricing will change.

And your engineering team shouldn’t have to debug broken invoices at 2:00 AM every time it does.

⭐ Star us on GitHub to follow our progress
🤝 Join our community to share feedback and collaborate.

Why Stripe Can’t Handle Your Complex Usage Based Billing

Flexprice — Wed, 16 Jul 2025 09:59:49 +0000

Every engineer who's worked on billing knows the pain. You're not fixing bugs, you're rewriting logic that already worked, just to support yet another use case, for one more customer.

If you've ever maintained a billing system, you know exactly what I'm talking about. The constant fear of touching the billing logic. The endless edge cases. The growing pile of "temporary" workarounds that become permanent fixtures.

And before you know it, the same input starts producing different outputs. It’s not your fault. You just didn’t want to rebuild billing from scratch. So you patched. And kept patching.

Even teams with solid engineering fall into this. Look at what happened with Cursor.

They went from 500 to unlimited requests. Within days, users were seeing zero usage, or huge unexpected overages. If it happens to well-resourced teams, it can happen to anyone.

So why not just use Stripe?

Stripe works well, for the basics. But it’s a closed product, deeply tied to its own ecosystem.

The moment your pricing grows more complex, hybrid models, credit-backed billing, usage metering, you start working around Stripe, not with it.

Want to bill through credits? Good luck.
Need invoices to plug into internal tooling? Wrap the API.
Want to override discounts for one customer? Write another patch.

Stripe doesn’t fail. But it locks you into workflows you can’t evolve.

So you write background jobs. You wrap the system. You stop trusting the calculations. And billing becomes a black box your team avoids touching.

We've seen this pattern repeat itself. Across startups, infra companies, even teams with solid engineering muscle.

One of them, Simplismart, put it best:

“We are an Infra company, and hence pricing changes a lot really quickly. While we were using one of the other billing tools, the initial setup was good, but as soon as we started to roll out changes, everything seemed to break from regenerating invoices, credit adjustments, partner billing, and more…

We were left with close to no support, and now that we have moved to Flexprice, the comfort of close to real-time support is just such a breather. The team is really nimble with requests and understands the space and requirements really well, with an almost spotless execution.”

— Shubhendu Shishir, Head of Engineering, Simplismart

So what’s the better alternative?

Closed source billing systems are optimized for the average case. But your edge cases are what define your product, and that’s where closed systems fail.

You try to fit your logic into someone else’s model. When it doesn’t fit, you patch it. When it breaks, you file a ticket.

And the deeper your pricing stack gets, the more boxed-in you feel.
Billing shouldn’t work like that. Not when it controls money, trust, and customer experience.

Open source changes that, it gives you:

The ability to understand how system works
The freedom to build logic that reflects your business, not a vendor’s roadmap
A way to contribute back when you solve something new, so others don’t have to reinvent it

Flexprice is open-source billing infrastructure designed for what Stripe and closed vendors can’t do:

Handle real-world pricing complexity
Let you define logic around usage, credits, plans, and grants
Keep billing inspectable and composable, like the rest of your stack
Give you the option to self-host or plug into our managed cloud
Support hybrid billing: credit wallets, usage tiers, subscriptions, and everything in between

Where we are, and what’s next

We recently launched five foundational features in five days as part of our Commit Launch. Check that out!

This momentum is just the start. Our public roadmap is open for a reason. We want you to build with us.

You can see what’s coming, suggest what should come next, and track how we prioritize across use cases.

We believe billing infra should evolve in the open, visible, extensible, and aligned with how real teams ship pricing.

⭐ Star us on GitHub to follow our progress
🤝 Join our community to share feedback and collaborate.

Flexprice Commit #5: Introducing Billing Workflows

Flexprice — Fri, 04 Jul 2025 12:42:36 +0000

You've been dumbing down your pricing to fit a tool, not your product. Instead of building the pricing model your business actually needs, you settle for what your billing system can handle.

And that’s why most SaaS companies start with simple usage billing, counting API calls, tracking storage, or measuring compute time. But as your product evolves, so does your pricing complexity.

You need to charge for daily active users instead of total events. You want session-based pricing that doesn't double-bill conversations. Enterprise customers expect calendar billing, and credit settlements become manual reconciliation struggles.

Traditional billing systems were built for straightforward sum-and-count metrics. The moment your business model demands more sophisticated usage tracking, you're forced to build custom infra.

Either hacking billing logic into your product code or managing it entirely outside your billing system.

More ways to aggregate billable usage

Most default billing systems have sum or count and that works for basic usage. But the moment you need to bill for DAUs, session-based pricing, or latest snapshot metrics, your billing logic becomes unmaintainable.

You either start hacking it in your product, or tracking it outside the system entirely.

Flexprice now supports 3 new aggregation types that let you build usage billing models the way your product actually works.

Count Unique
Count Unique lets you track the number of distinct values for a property like user ID, session ID, or chat ID, in any billing period.

Let’s say you run a support tool like Intercom. Each incoming message triggers an event, but you want to charge once per conversation, not per message.

So you pass a chat_id property in every event.
If a conversation has 50 messages, Flexprice counts only 1 for that chat_id.

Use cases:

MAU/DAU pricing (distinct user IDs per month)
Per-session billing (distinct session IDs)
Per-ticket resolution (distinct ticket IDs)
Per-project or workspace usage (distinct entity IDs)

Latest
We’ve added a Latest aggregation type to Flexprice’s usage meters.

This lets you capture the last value received for a specific event within the billing period, and use that as the billable metric. Without this, you'd need complicated internal counters or scripts to track end-of-period usage, leading to additional overhead.

Let’s say you're pricing your product like Amplitude, based on MTUs (Monthly Tracked Users).

Users log in, use the product, and generate events but you're only charging for the total number of unique users tracked at month-end.

Instead of tracking user join/leave events or keeping an internal counter, you just send:

{ event_name: "mtus",
value: 26730,
timestamp: "2025-07-31T23:59:00Z" }

At the time of invoice generation, Flexprice picks this last value for the billing window and applies your pricing logic accordingly.

Sum with Multiplier
We've added a Sum with Multiplier aggregation type to Flexprice's usage meters.

This lets you apply different cost weights to the same event type based on resource intensity or complexity.

Without this, you'd need separate event types for every pricing variation, cluttering your tracking setup and making billing logic harder to manage.

Some customers trigger heavy workloads, others use light ones. This aggregation lets you apply a multiplier per event to scale pricing accordingly.

Let's take Cursor as an example. Every customer triggers a "Generate Code" event, but the computational cost varies based on whether they use the standard model or the reasoning-intensive "Thinking" mode.

Users running the same coding task might choose different AI models:

Claude Sonnet 4 (Thinking) → 2x multiplier due to extended reasoning

Claude Sonnet 4 (Standard) → 1x multiplier for direct responses

Cursor pricing model
Apply credits directly to invoices
Let’s say you grant a customer credits when they sign an enterprise contract $1,000 worth, upfront. Now their first monthly invoice is due. You want to deduct the invoice amount from the wallet credits they already have.

But without native support, here’s what your team has to do:

Check wallet balance manually

Update the invoice as “partially paid” via admin tools

Adjust wallet credits through custom scripts

Reconcile the ledger across three systems

And if anything goes out of sync, finance and support are left untangling the mess. Now you can apply wallet credits directly to open invoices in Flexprice.

With this you can settle part or all of an invoice using a customer’s existing credit balance. without needing to process an external payment.

Flexprice automatically updates wallet balances and invoice statuses, fully eliminating manual reconciliation scripts or custom admin tool adjustments.

Align billing cycle with calendar

By default, most billing systems follow anniversary billing, the subscription renews every month based on the date it was started.

But if your customers are signing up on the 3rd, 7th, 14th, or 28th, your invoices are all over the place.

This becomes even messier in enterprise setups where customers expect to be billed on the 1st of every month, and your billing system just doesn’t support it.

And now with Flexprice you can enable calendar billing. So you can choose between calendar and anniversary billing.

Wrapping up
These new aggregation types and billing capabilities solve the most common usage tracking headaches that force teams into custom hacks.

With Count Unique, Latest, Sum with Multiplier, credit settlements, and calendar billing, you can finally build pricing models that match how your product actually works.

→ If you have any questions, talk to us

→ Check what we launched yesterday

→ Sign up for launch updates to get future drops in your inbox

That's a wrap on launch week. Thanks for following along.