Skip to main content
Patronage logo

Custom web applications on the same stack as your site.

Internal tools, dashboards, and member-facing apps, built by the same team that builds your website. Staff sign in with the accounts they already use, and your team tries each feature before it goes live.

Internal tool: intake queueExample
Event request · OaklandNeeds review
Event request · FresnoApproved
Room booking · March 4Synced to CRM
Volunteer shift · SaturdaySynced to CRM

Staff sign in with Google or Microsoft. Every change records who made it.

What we build

Software for the work your website can't do.

Most of these start as a spreadsheet, a shared inbox, or a process someone runs by hand every Monday. The app replaces the part that keeps breaking.

Staff

Internal tools

Intake queues, approval steps, and lookups that replace the spreadsheet everyone edits, with a record of who changed what.

Reporting

Dashboards

Numbers from your CRM, analytics, and ad accounts in one place, each defined once so every report agrees.

Members

Member-facing apps

Portals, sign-up flows, and lookup tools for the people you serve, connected to the systems that hold their records.

Data

Integrations

Scheduled jobs that move data between your tools, with retries and logs instead of a silent failure nobody notices for a month.

The stack

Cloudflare underneath, boring on purpose.

Apps run on Cloudflare, like the sites we build, so there is one platform to secure and one bill to read. It's also the platform we run our own product, Patronage Loop, on.

About Patronage LoopConnect your AI toolsOur open-source starting point
  • Cloudflare Workers run the app close to every user, with no servers to patch
  • A database sized to the job: Cloudflare D1 for small apps, PlanetScale when the data grows
  • Staff sign-in through Cloudflare Access with Google or Microsoft and two-factor
  • Logs and error tracking from the first deploy, so problems show up before users report them
How it ships

Small releases you can try.

We build the smallest version that does the job, put it in front of the people who will use it, and keep going from what they tell us.

  1. 01

    Describe the workflow

    Walk us through the work as it happens today, including the workarounds.

  2. 02

    Try it on a preview

    We build the first useful version and put it on a preview link.

  3. 03

    Ship it

    Once your team signs off, it merges into your repository and goes live.

  4. 04

    Keep going

    The next feature is a new pull request, not a new project.

FAQ

Frequently asked questions

Do we need a new website to get an app?
Usually not. Most apps start small and live beside the site, on the same hosting, so one team looks after both.
Who can sign in?
Your staff sign in with the Google or Microsoft account they already use, with two-factor, through Cloudflare Access. Member-facing apps can use their own sign-in.
Can it connect to our CRM?
Yes. Most apps exist to connect something: a CRM, an email platform, a spreadsheet, or an ad account. Keys are stored as secrets with the least access that works.
Who maintains it after launch?
We do, on the same maintenance plan as your site, with retainer hours for the features you think of after launch.

Bring us the spreadsheet everyone is afraid to edit.

Tell us which process breaks most often, or which number takes longest to find. We'll sketch the smallest app that fixes it.

Website redesignPayload and headless WordPress