How Remittance Go built a fintech without building auth or billing

• Team size: 3 people. One developer.
• Auth live: roughly one week from first commit, with the vanilla implementation closer to a day
• Billing build avoided: 4–8 weeks of full-time work, by Rhys’s own estimate
• Launched charging from day one: no free beta, no separate paywall project
• Kinde features in production: organizations, roles and permissions, billing, entitlement tracking, social login, custom domain, hosted auth pages
• Stack: Next.js, Kinde Next.js SDK, Xero OAuth2

Bookkeepers and accounts teams rarely get paid once. They get a bulk payment covering dozens of invoices, and a PDF explaining how it splits.

“The company receives a PDF that’s three pages long with 60 invoices that they now need to go into Xero and individually tick them all off,” says Scott Lynch, Remittance Go’s co-founder. Overpayments, underpayments and split payments are common on those remittances, which compounds the problem.

Remittance Go reads the PDF, matches every line against outstanding Xero invoices, and pushes a batch payment in one click. A single upload can clear 500 lines. Scott hit the problem inside a company he runs, found no software that solved it, and called his best friend Rhys Hughes to build it.

The third co-founder, Nathan Price, is a bookkeeper and joined to bring domain expertise to the founding team. Nathan leads sales and customer support, and his time with customers helps guide what gets built next.

Remittance Go has since matched over $40 million in payments across more than 20,000 remittance advices. The effect lands on its customers’ books. One organization cut its reconciliation processing time by more than 90%, saving close to $50,000 a year in wages, roughly the cost of a part-time finance role.

Rhys had built authentication himself before, on an earlier product running Laravel and its built-in auth library. The problem was not that it failed to work. It was that everything around it had to be hand-built: sending a password reset from an admin dashboard, letting a user reset their own password, handling and rotating tokens. Each one meant more custom code, and more ongoing maintenance buried in PHP files.

On Remittance Go he would be the only engineer. Building auth a second time would have consumed the time the product itself needed, so he ruled it out before any evaluation began.

“I knew I wanted to use just an off-the-shelf product,” he says.

The shortlist came down to Kinde and one other auth provider. What tipped it was a stack of small things: a Kinde engineer who got on a call and answered his questions, a pared-back dashboard that matched the way he likes to build, and the fact that Kinde is Australian. The one hard requirement was organizations, since Remittance Go sells to teams rather than individuals.

From first commit to a working authenticated user took about a week. The integration itself was not the slow part; a vanilla implementation, Rhys reckons, could be done in a day.

The rest of the week went on decisions that would matter later. Should the app read a user’s name and organization from their access token, or call the Kinde API for it? What does each choice cost as the product grows? Working that through up front was the difference between an integration that holds and one that has to be unpicked six months in.

He chose Kinde’s hosted auth pages over building custom screens. “I didn’t see much value in sort of reinventing the wheel,” he says. As long as sign-in is quick, clean and looks professional, users don’t think about it, and the hosted pages covered what Remittance Go needed.

Remittance Go could have wired Stripe in directly, and Rhys had seen where both versions of that end up. The lightly embedded approach, using Stripe’s hosted portals and webhooks, works for an MVP but leaves you maintaining a mapping between your users and an external portal. Building it properly inside the app is a bigger job again, with product and subscription IDs threaded through unrelated parts of the codebase every time a plan changes.

His estimate for doing it himself was four to eight weeks, or more.

Scott framed it as a long term roadmap question rather than a feature comparison. “There are some platforms where you might be able to handle auth, but you’re still holding the Bermuda Triangle together between yourself, auth and Stripe,” he says.

Running both on Kinde put subscriptions at the organization level rather than the individual, so access flows down to every user in a team without extra plumbing, and no Stripe webhooks are scattered through peripheral code. It also kept plans editable, which is what Rhys actually wanted, because a young company’s pricing is a series of guesses.

Remittance Go launched charging from day one, with no free beta and no paywall project three months later. Plans run $99/month for one seat and 300 remittances, $199/month for up to five seats and 1,200 remittances, and a custom enterprise tier, all behind a 14-day trial.

As a Xero App Store Verified partner, Remittance Go had to satisfy Xero on how it handles tokens and protects server-side code.

The architecture keeps two identity layers cleanly separated. Kinde authenticates users into the platform; Xero’s OAuth2 connection authorizes the accounting data underneath. That separation was what the reviewers cared about, along with evidence that server-rendered queries could not run for an unauthenticated user.

Kinde’s session handling let Rhys enforce that check directly in the server-side code paths, as an additional layer on top of the application’s existing access controls. “It makes it really easy to guard that part of your codebase,” he says.

Keeping the two layers distinct also kept the architecture clean. Every request is validated against the Kinde session before any accounting data is touched, so the systems stay cleanly scoped without extra identity plumbing running between them.

The clearest return is where the one engineer’s attention goes. “It’s freed me up to focus on the core of the product,” Rhys says, with the ability to change commercial decisions later mattering just as much.

Remittance Go is now seeing product-market fit and preparing for scale.

Scott’s advice to founding teams is to have the build-versus-buy conversation explicitly, across every part of the stack, and to start it at buy for auth and billing. Understand what the bought solution costs as it scales, then price it into your own plans as a cost of service. “That cost to buy is going to be infinitely smaller than what it is to manage that internally yourself over time,” he says.

His reasoning is that this particular problem never stays solved. It goes quiet for a quarter, then reappears in a new shape: individual accounts become teams, teams need usage throttling, then an enterprise deal arrives carrying requirements nobody planned for. The question isn’t whether a solution covers today’s requirements, but whether it scales into the ones you can’t see yet.

He also has a tell he uses on any integration partner: read the docs. Are they current, thorough, and honest about their gaps? Kinde’s, he reckons, are a good sign of a product pointed in the right direction.

For Rhys, the payoff shows up in what a three-person company is now able to take on.

“Thanks to billing and auth, there’s no reason why we can’t now support even larger volumes.”