Signing people in, sending email, taking money. Three modules you can take one of or all of, so the part that isn't the same every time is the part you write.
Free and open source, MIT licensed. Nothing to buy, no licence key, nothing phones home.
Rails 8.1 or newer, Ruby 3.2 or newer, PostgreSQL or SQLite.
SparrowKit# Gemfile — comment out what you don't want
git "https://github.com/sparrow-soft/sparrowkit.git",
tag: "v1.4.0", glob: "gems/*/*.gemspec" do
gem "sparrow_auth"
gem "sparrow_mail"
gem "sparrow_pay"
group :development do
gem "sparrow_ui"
end
end
$ bin/rails sparrowkit:install
→ then open http://localhost:3000/sparrowkit and add your keys
Each one installs on its own and does one job. Nothing here knows anything about any particular business — no industry assumptions to work around or strip out.
Passkeys first, because they are the one way in that cannot be phished. A code sent by email for anyone without one yet. Google and Apple if you want them, passwords only if you turn them on. Built on Rodauth.
People belong to teams, and a team is what a subscription belongs to. Mark a table as belonging to a team and one customer's records stop being able to surface in another's — the part of this that is genuinely hard to retrofit later.
You write mailers the ordinary Rails way. Moving from one email company to another means changing one setting and pasting in a new key. SendLayer, Postmark, SendGrid, Mailgun, SES or plain SMTP.
Deliberately thin, and thinner than you expect. It makes the team the customer, works out where a receipt should go, and holds your processor's keys. Everything else is the Pay gem, which your app talks to directly. There is no wrapper here to learn.
Where every key and setting gets entered, at /sparrowkit in your own app. It runs on your machine only and refuses anything that is not a local request, so it cannot be reached even if it accidentally ships. Keep it out of production.
PostgreSQL or SQLite, and no Redis. Settings live in your app's encrypted credentials, committed with your code. Deployment stays entirely yours.
This is the part most starter kits are vague about, so it goes near the top rather than in a footnote.
SparrowKit ships no screens. No sign-in page of ours, no invitation page, no member list, no team switcher, no billing page. Rodauth serves its own pages under /auth, and they arrive wrapped in your application's own layout. Everything your customers look at is yours.
It has no opinion about what a role may do. A role is a name you choose — owner, reviewer, whatever your product means. SparrowKit remembers who holds which and never interprets it, because only your code knows what they mean. Permission rules are ordinary Ruby in your app.
SparrowKit doesn't roll its own. sparrow_auth is configuration and wiring on top of Rodauth, so the genuinely dangerous parts — storing a password so it cannot be read back, checking a passkey, making sure a sign-in link cannot be spent twice — are handled by people whose full-time job that is.
sparrow_pay is the same idea on the Pay gem. Nothing in SparrowKit names a payment company, so the processor edge cases are Pay's problem rather than yours.
Version 1.0 is smaller than it could be. These are known gaps rather than oversights, and it seems better to say so here than to let you find out in week three.
MIT licensed. If you fix something, a pull request is welcome.