When I started Flash, I thought the core problem was straightforward: Bitcoin payments for businesses were still too limited, too fragmented, and too operationally complex compared to the fiat world. Even when solutions existed, the experience felt like something only a Bitcoin-native business could realistically adopt. My belief was that if we could make Bitcoin payments feel closer to how businesses already get paid - familiar, simple, and sane - we could bring more demand into the space over time.
That thesis felt even more compelling when I discovered Nostr Wallet Connect (NWC). For the first time in the Bitcoin ecosystem, it became possible to build something resembling “direct debit” primitives - and more importantly, subscription-like payment flows in full self-custody. It felt like a missing building block. So our early positioning was clear: Flash is the easiest way for businesses to accept Bitcoin payments.
Over the last few months, that framing stopped holding up.
We ran a survey with our users, and two signals stood out immediately: over 80% told us they want a solution that converts part of their fiat revenue into Bitcoin automatically, and over 90% told us they would switch to a provider that unifies fiat payments, Bitcoin, and stablecoins in one place. That’s not a payments request. That’s a treasury request.
And it led us to a thesis that now feels unavoidable:
Treasury is the product. Payments are the rails.
The Bitcoin payments market matured, and the bottleneck moved
Bitcoin payments products did important work over the last few years. They built the rails and made acceptance possible. But as the market matured, the bottleneck moved. For most real businesses, the hard part is no longer “Can I accept Bitcoin?” The hard part is everything that happens after revenue lands: visibility, settlement, reporting, and treasury decisions.
At scale, businesses already have revenue collection solved. They have a PSP, invoicing workflows, accounting routines, and settlement expectations. Switching any of that is expensive. Even Bitcoin-aligned operators rarely want to overhaul their stack just to add a payment method. So the value has to be sticky enough to justify adoption. Payments alone often isn’t. Treasury is.
The disconnect: businesses wanted Bitcoin, but payments weren’t getting them there
This is what took us time to see clearly: businesses didn’t want Bitcoin payments because they wanted a new payment method. They wanted Bitcoin because they wanted to accumulate it over time as part of their treasury strategy.
But Bitcoin payments alone weren’t achieving that outcome. In practice, what was happening was the opposite: businesses were taking on more tooling and complexity ( wallet selection, Lightning decisions, extra reporting) and receiving almost no Bitcoin.
A concrete example makes the gap obvious. A typical business might do $30k per month in invoices and want to allocate 10% of that into Bitcoin. In their head, that’s $3k/month of accumulation. In reality, they might receive $50 of Bitcoin payments in a month. So they either give up, or they start manually buying Bitcoin, tracking it, reporting it, and stitching together separate tools just to reach the outcome they wanted in the first place.
That’s the gap Flash is built to fill.
The real problems were treasury problems
Once we stopped framing Flash as a payments product, the recurring pain points became clearer. The consistent themes were not about accepting Bitcoin, they were about operational clarity and treasury execution:
- Confusion about wallet selection and custody
- Uncertainty about what to do once Bitcoin is received
- Taxes and reporting complexity
- Lack of visibility into what’s settling, what’s in transit, and what’s actually arrived
- Tool sprawl: separate dashboards, separate reporting, separate workflows
And one theme kept coming up implicitly: businesses don’t want to become payment power users. They want treasury outcomes with minimal operational overhead.
Treasury-first: what it means
Treasury-first means that a business can manage cash flow and Bitcoin holdings in one place, and that treasury decisions are powered by real revenue flows. Payments still matter - we still operate payment rails, in fact we’re integrating new ones - but the product is no longer “accept Bitcoin.” The product is visibility, decision-making, and eventually automation.
The difference is that we’re built directly on top of revenue flows. That changes what becomes possible.
Why this matters for startups and SMEs
This matters for every business, and arguably even more as you go upmarket. But startups and SMEs are where we’re starting. The reason is simple: most don’t have treasury teams, and many don’t even have a dedicated CFO. Finance often sits with a founder, a head of ops, or an interim CFO role that is already overloaded.
In that context, every extra tool is friction. Every separate dashboard creates more work. A treasury-first product should do the opposite: consolidate reporting, reduce tool sprawl, and empower operators with clarity and guardrails.
What Flash looks like in Phase 1 (and what it’s not)
We’re launching in phases, and Phase 1 is intentionally minimal. It is not “full automation,” and it is not a payments novelty pitch. Phase 1 is about visibility and operational clarity.
The entry point is invoicing, but the value is treasury-first:
- Invoicing as the revenue flow
- Fiat + Bitcoin payments supported
- Settlement lifecycle visibility
- A treasury-focused dashboard
- Unified reporting that links revenue and holdings
The goal is simple: give operators a clean view of where their money is, what is settling, and what treasury decisions they can make as revenue arrives.
Manual Bitcoin buying, conversion controls, allocation rules, and automation come in later phases. We are deliberately sequencing this. Automation without visibility is a trap, and in treasury, trust is everything.
So the order matters: visibility first, control second, automation last.
Where this is going
Flash is becoming treasury infrastructure powered by business revenue flows. We’re building it carefully, with real operators, and sequencing it deliberately: visibility first, control second, automation last.
We’re rolling this out through a phased design partner cohort.
The first five US-based businesses are already committed and will be onboarded into Phase 1, focused on invoicing and treasury visibility. Once we add manual allocation controls, we’ll onboard the next 5. Automation unlocks the final 10.
We’re intentionally starting in the US to keep regulatory and operational scope tight while we build depth. Expansion will follow once the system is stable.
If you’re building in the US and thinking seriously about treasury, reach out. The first phase is underway, and we’re lining up the next.