Trust is infrastructure: Crafting Flowglad with taste and rigor

Preface

In a category as sensitive as payments and billing, trust isn’t earned through flashy features - it’s earned through solid infrastructure. At Flowglad, quality isn’t decorative; it’s structural. From our earliest architecture decisions to our latest customer pair-programming sessions, we treat every layer of the product - interface, backend systems, testing, onboarding, even messaging - as part of the trust surface.

Flowglad isn’t just a billing toolkit; it’s financial infrastructure that businesses rely on to move money and keep their operations running. That responsibility demands rigor, clarity, and precision at every level. In practice, this means trust isn’t an afterthought or a feature - it’s woven into how we design, build, and deliver from day one.

A call to craft

The inflection point came when my co-founder, Agree, asked me, “Where’s that RISD-level craft?” It wasn’t a comment about the site’s colors or aesthetic. It was a challenge to elevate everything - the UI, APIs, messaging, onboarding flow, architecture, reliability... everything.

In our minds, design wasn’t just ornamentation; it was clarity. Architecture wasn’t about speed; it was resilience. Messaging wasn’t about branding; it was providing the right context. That question reframed how we build: every element now had to feel intentional, coherent, and trustworthy.

Inspired by the physical

To achieve that level of craft, we looked beyond software for inspiration. We study enduring quality in the physical world - Hermès leather goods, modernist furniture, even museum curation - to calibrate our instincts. For instance, at Hermès, even the underside of a belt (the part no one sees) is finished with the same precision as the top. We apply that ethos to Flowglad: details like code comments, loading spinners, and admin screens receive as much thought as the customer-facing features. To us, everything is a customer-facing detail.

I learned the value of this design intuition early. Growing up in New York City, my mom took me to a different museum, gallery, or design exhibition almost every Friday after school. Over the years, this routine filled my brain with a rich “training dataset” of quality and creativity. I absorbed Monet’s meticulous layering, Donald Judd’s clean minimalism, Picasso’s bold compositions, Dieter Rams’s purposeful simplicity, Isamu Noguchi’s harmony of form and function, and the Eameses’ playful precision. Continuous exposure to such diverse excellence sharpened my intuitive grasp of form and function - it became a built-in heuristic for making quicker, better design decisions.

That cultivated taste isn’t about personal preference; it’s more like a product-sense API in our heads, returning better results as we fed it more quality input. Having a refined intuition for what “great” looks like helps us shorten the cycles of trial-and-error. We can zero in on stronger solutions earlier, without endless iteration or second-guessing. It also means that when we do seek customer feedback or pore over data, we’re starting from a higher baseline. We can ask deeper, more insightful questions from the outset, instead of discovering fundamental issues too late.

Too often, I’ve seen teams seek feedback on a product that isn’t even ready for meaningful critique - essentially hoping others will do their taste-work for them. We were determined to avoid that trap by raising our own bar first. Armed with this sharpened intuition and commitment to craft, we went back to Flowglad’s foundations to make sure the product truly lived up to the trust we aimed to earn.

Re-architecting for real-world trust

We didn’t just apply a fresh coat of paint; we rebuilt Flowglad’s mental model from the ground up to be more robust and predictable. As we overhauled the system, we:

• Eliminated webhooks from our default integration path

• Created SDKs that would allow our users to send data door to door - all the way from our servers to their backends and frontends

• Developed schemas to describe entire pricing models in a single payload

• Built a double entry ledger that tracks usage, available for realtime reads

• Wrote over 1,000 test cases to test every aspect of our payments and billing system, as well as various aspects of our UI

These changes made Flowglad’s behavior more dependable for anyone integrating with it. We didn’t stop at the obvious improvements. Behind the scenes, we built in additional safeguards to handle the messy realities of payments and billing so that nothing falls through the cracks. We also encoded sensible defaults to gracefully handle real-world edge cases - things like payment confirmations, mid-cycle plan changes that need proration, or re-aligning billing dates when a customer upgrades late.

None of these were cosmetic patches; they were foundational reliability features engineered deep into Flowglad. Trust isn’t just promised in our slide decks - it’s built into the architecture.

Built by using It ourselves

One way we ensure Flowglad stays trustworthy is by using it ourselves, every single day. We pair-program with customers as they integrate Flowglad, seeing exactly where they struggle or succeed in real time.

Real usage reveals what theory misses. We meticulously document every piece of feedback, even when we don’t build exactly what’s requested. For us, it’s not just about making users feel heard - it’s about making them feel like they’re building the product alongside us. Often, the true insight isn’t in the specific feature a user requests, but in what’s between the lines. Those nuanced lessons guide us to improve Flowglad in ways that a spec sheet or roadmap might not capture.

Quality you can read in the code

Our commitment to quality and transparency is also evident in our codebase and documentation. You should be able to see the trustworthiness of Flowglad in how it’s built. For example, we maintain:

• Clear conventions: A consistent coding style and structure, so anyone browsing the repository can follow along easily

• Thorough testing: Extensive test coverage, which catches issues early and proves that each part of the system works as intended

• Detailed docs: Our documentation doesn’t just explain what Flowglad does; it also explains why it works the way it does, so engineers understand the reasoning behind our decisions. You can see this in our Principles page.

None of this is for show. This level of rigor in code and docs is how we earn the trust of the engineers who depend on Flowglad.

Why this matters

On the surface, billing might look simple - just forms and invoices. But under the hood, it’s a tangle of distributed systems, state management, and financial calculations, with very real consequences if something goes wrong. In other words, we’re not just building a pretty interface; we’re building the confidence that every charge and transaction is handled correctly.

For us, trust isn’t an outcome or a marketing claim - it’s an input to the entire development process. That’s why we write tests before we even finalize a UI, instrument detailed logs before adding polish, and implement failure-handling mechanisms even before new features.

We’re not trying to impress anyone with flashy features. We want Flowglad to fade into the background by simply always working as expected. If we do our job right, our customers can spend their energy on their own product and users - not on troubleshooting payments or double-checking invoices. That kind of quiet reliability is what our craft is all about now. And it’s what we hope every engineer senses when they run pnpm install @flowglad/nextjs and hit deploy.