How I Built a Grant Management System on Airtable, Softr & Make.com
A grant-giving organisation ran applications across spreadsheets and email and kept losing track of reviews and payments. I rebuilt it as one automated system on Airtable, Softr and Make.com. Here's exactly how it works — the data model, the portals, and the automations.
To replace a tangle of spreadsheets and email, I built a grant management system on Airtable (the database), Softr (the applicant and reviewer portals) and Make.com (the automation glue). The result: one source of truth where every grant is tracked from application to payment, with reviewer assignment and status emails running automatically. This is a first-hand teardown of how it was built.
The problem: spreadsheets that couldn't keep up
The organisation gave out grants, but everything lived in disconnected places. Applications arrived by form and email, reviews happened in shared spreadsheets, and payment status was tracked in someone's head. As volume grew, three things kept breaking: applications slipped through unreviewed, two reviewers would unknowingly score the same application, and nobody could answer a simple question — what stage is this grant at right now?
The real cost of a spreadsheet system isn't the spreadsheet — it's the hours spent chasing status and the applications that quietly fall through the cracks.
Step 1: A relational data model in Airtable
The foundation was a properly normalised Airtable base — the single biggest factor in whether a no-code system stays fast and sane. Instead of one giant sheet, I split the data into linked tables so each fact lives in exactly one place:
- Applicants — organisation and contact details, linked to their applications
- Applications — the request itself, its amount, stage and linked reviewers
- Reviewers — the review panel, linked to the applications assigned to them
- Reviews — individual scores and comments, one record per reviewer per application
- Disbursements — approved payments, linked back to their application
Because the tables are linked, an applicant rolls up to all their applications, and an application rolls up to every review and payment against it. That relational structure — not a formula trick — is what makes Airtable behave like real software. I explain the wider principle in my guide on what Airtable is and when to hire a developer.
Step 2: Portals with Softr, not raw Airtable
Applicants and reviewers should never see the database itself. I built two separate Softr portals on top of the Airtable data, each with its own login and permissions:
The applicant portal
Applicants submit their request, upload documents, and — crucially — track their own status without emailing anyone to ask. That single feature removed a large chunk of the back-and-forth the team used to handle manually.
The reviewer portal
Reviewers see only the applications assigned to them, score them against a consistent rubric, and submit comments. Because assignment is enforced by the data model, two reviewers can no longer collide on the same application.
Step 3: Automations with Make.com
The glue that turned a database into a system was Make.com. Each scenario watches Airtable for a change and reacts — no human trigger needed:
- New application submitted → send the applicant a confirmation, notify the admin, set stage to Received
- Application marked ready for review → auto-assign reviewers and email them their queue
- All reviews in → roll up the scores and move the application to Decision
- Grant approved → create a disbursement record and email the applicant the good news
- Stage changes → keep the applicant's portal status in sync automatically
I deliberately offloaded the heavier logic to Make.com rather than overloading Airtable's built-in automations — a reliability choice I make on most builds, and one I cover in my comparison of n8n vs Make.com.
Design principle: let Airtable hold the truth, and let a dedicated automation platform do the work. Overloading a no-code database with heavy automation is how these systems get slow and fragile.
The results
- Fragile spreadsheets replaced with one source of truth for every grant
- Reviewer assignment and status emails fully automated — no manual chasing
- Complete visibility: every grant's stage, from application to payment, at a glance
- Applicants self-serve their status, cutting inbound email to the team
You can see the summary on the Grant Management System project page.
What I'd tell anyone building this
Get the data model right first. Almost every painful no-code system I've been asked to rescue failed at the same point: a flat, denormalised structure that couldn't grow. Spend the time on linked tables up front and the portals and automations fall into place naturally.
Want a system like this?
If your team is drowning in spreadsheets and email for a process that should run itself, this is exactly what I build. See my Airtable development & consulting service or tell me about your workflow — I'll tell you honestly whether a no-code system is the right fit.