Stacware turns Flowglad into their financial database

Why billing sits at the center of Stacware's work

How a Nuxt/Vue agency stopped rebuilding billing from scratch and started treating Flowglad as the source of truth for every subscription, credit, and entitlement.

Stacware is a professional small business tech partner, the external tech team that gives growing companies CTO level guidance without the overhead. They build and run custom software for businesses that see technology as a real competitive advantage, not just a website, but to offer:

• Custom web applications and internal tools

• System integrations and APIs

• Ongoing support, maintenance, and feature development

• Workflow automation and digital transformation

Under the hood, a lot of that work now touches money. Stacware ships invoicing systems, subscription products, credit based experiences, and admin tools where non technical operators need to understand who is paying for what. O'Brien McQuade, one of the founders behind Stacware, does that work on a Nuxt/Vue and Node stack with Supabase.

That combination created a familiar problem: every time a new product needed subscriptions, credits, or discounts, he had to decide whether to bolt on another custom billing layer or bite the bullet and invest in a proper financial system.

The inflection point: billing as a real system, not glue code

When O'Brien first picked up Flowglad, he wired it into his Nuxt/Vue, Node, and Supabase stack like any other core dependency. Very quickly, it stopped feeling like “just” a payments API and started to look like the place his apps should go for everything finance.

“Flowglad has become my financial db for everything finance. Phew, I can delete some tables from my DB lol”

His job shifted from wrestling with billing logic to integrating a dedicated finance system.

“So how I’ve shared before is a way for your app to collect payment and be the single source of truth for payments and subscriptions. If that doesn’t do it, I’ll let them know they don’t have to save any payment/subscription info in their DB and they usually get intrigued by that”

“For me, the single source of truth statement really drives home that there is no need to store customer payment info in their DB. It’s the big sell. What sets you guys apart. The no webhooks is great, but I think, for me atleast, not having to build a subscription management in my DB is worth whatever price you guys ask”

For Stacware, that is the bar: Flowglad is the system of record for billing, so they do not have to be.

Architecture in practice; Stacware building atop Flowglad

On a typical Stacware project, the stack looks like:

• Nuxt/Vue for the front end

• Node for server side logic

• Supabase for auth and core application data

• Flowglad as the financial database that tracks products, pricing, subscriptions, features, usage, discounts, and billing portals

O'Brien leans on Flowglad’s HTTP API and Node package. The React SDK does not fit his stack, so he talks directly to the endpoints.

Pricing models and features as entitlements

Stacware models plans through Flowglad pricing models:

• A default pricing model is configured for the app, available via /pricing-models/default

• Each product has features attached

• Those features drive both what shows up in the public pricing table and what the app checks for entitlements

When the API did not return features with pricing models, he surfaced it. The team shipped a fix that returned features on both pricing models and products, and he updated his calls:

“I appreciate the hard work! Features is working beautifully after I made some small changes to my API calls.”

From that point on, a single call to the pricing model gave him prices plus the features he uses to drive access control.

Default free plan and upgrades

Stacware wants everyone to be on at least one plan at all times. For that, they use Flowglad’s default plan behavior and single subscription constraint:

• allowMultipleSubscriptionsPerCustomer is set to false

• Each new customer automatically gets a default free subscription attached

• Upgrades happen through Flowglad hosted checkout

The upgrade flow looks like:

• Stacware creates a checkout session with checkout.create, passing:

  • type: "product"

  • customerExternalId from their own database

  • successUrl and cancelUrl in their Nuxt app

  • The priceId of the target paid plan

• Flowglad returns a hosted checkout URL

• The person completes payment there, and Flowglad updates their subscription

At one point, default plan customers were immediately redirected from checkout back to the success URL because the system saw they already had a subscription. Flowglad's founding engineer, Brooks, tracked that down and shipped a change so default plan customers can go through checkout normally.

Inside the Nuxt app, Stacware does not store subscription state in its own tables. Instead, O'Brien calls Flowglad when he needs a definitive view:

“Yessir, once I understood how Flowglad works, I just use get billing for my source of truth”

“I just want to reiterate how much I love getCustomerBilling endpoint and not having to handle any sub stuff in the DB. LIKE LOVE IT. Everything else at this point is just extra credit.”

Subscription changes and proration

For moves between paid tiers, Stacware uses Flowglad’s subscription adjust endpoint. Brooks shared patterns for:

• Immediate upgrades with proration of the current billing period

• Downgrades that take effect at the end of the billing period

OBrien’s target behavior was clear:

• Free to paid: create a checkout session, collect payment, start the paid plan

• Paid to more expensive: adjust immediately with proration

• Paid to less expensive: change at period end, no credits needed

The adjust route is still evolving, especially around how line items and headers stay in sync and how proration is represented. O'Brien has been a design partner here, trying real upgrade and downgrade flows and feeding back where the API behavior surprises him.

Usage meters and credit packs

In another product, Stacware sells credits. Someone might buy 100 credits, perform actions that consume one credit per request, and expect that balance to be reliable.

O'Brien uses Flowglad usage meters and templates to track that usage inside the financial database rather than maintaining a separate credits table of his own. He also asked about rollover credits, where unused balance carries into the next period. Flowglad does not support rollover yet and has logged it as a future expansion on usage credit grant features. In the meantime, the platform still acts as the ledger for how many credits have been consumed.

Discounts and future referral rewards

To support promotions and future referral rewards, Stacware pipes Flowglad discounts into their own admin dashboards:

• Their client can define discounts through Stacware’s UI

• The server posts that payload to Flowglad’s /discounts endpoint with name, code, amount, amount type, duration, and number of payments

An early call to /discounts failed with an internal error about missing user context for a non API key transaction. Brooks traced and fixed the issue and confirmed it as resolved.

Later, OBrien started exploring how to reward referrals such as “Three months off for bringing in new customers.” Today, Flowglad applies discounts only at subscription creation. That constraint is shaping how he designs the referral program and how Flowglad thinks about discounts that attach to existing subscriptions.

Multi org life and billing portal

As an agency, Stacware lives inside multiple Flowglad organizations:

• Their own Stacware workspace

• Client orgs where they set up pricing and plans

• Test environments

Initially there was no visible org switcher in the app. After he asked about it, Brooks shipped an org switcher component so people can move between orgs from the header. O'Brien’s summary was simple:

“Works great. Thanks dude.”

On the customer side, Stacware links people directly into Flowglad’s billing portal from their applications, so they can update payment details and see subscriptions without Stacware building everything from scratch. A brief issue with a blank page turned out to be a cache and auth state problem on his machine. Incognito and a cache clear resolved it and the billing portal worked as intended.

Impact showed up as architecture decisions more than numbers

• Flowglad is now the financial database for their apps, not a sidecar. O'Brien literally removed tables from his own schema once he trusted Flowglad to hold subscription and payment data.

• Entitlements come from Flowglad. Pricing models and features let him reason about “what this person can do” without inventing a new entitlement system for each project.

• Subscription state lives in one place. Instead of juggling local billing tables, webhooks, and partial copies of Stripe like data, he leans on endpoints like getCustomerBilling to answer billing questions.

• They can reuse the same billing patterns across projects. The combination of default plans, checkout sessions, adjust endpoints, usage meters, discounts, and the billing portal now form a toolkit that Stacware can bring into the next Nuxt or SaaS project.

It also changes how he talks about Flowglad internally and with new customers. When he wears his technical PM hat on government and public sector SaaS, he already knows what he wants to plug in:

“Since I'm this technical PM/Lead Dev on this side of the house, I will 100000% be introducing Flowglad into these apps, so be on the look out boys.”

There is still work in flight together. Rollover credits, discounts on existing subscriptions, and fully polished upgrade and downgrade semantics are active conversations. But the core shift has already happened: for Stacware, billing is no longer a pile of ad hoc tables and webhook handlers. It is a first class system, and Flowglad is that system.

Lessons for teams building with Flowglad

• Treat billing as its own system, not an afterthought. Stacware’s real progress started when they let Flowglad be the financial database, instead of mirroring subscription state in their own tables.

• Use pricing models and features to drive entitlements. Plan configuration in Flowglad is not just for billing, it can also be the source of truth for what people see in your app.

• Design flows around defaults and upgrades. A default free plan plus hosted checkout for upgrades gives you a clean baseline, and you can layer more complex adjustments on top as you go.

• Let real integrations steer the roadmap. Many of the product improvements in this story came directly from one team shipping a real Nuxt/Vue app and surfacing what broke. That feedback loop benefits everyone.