Hey everyone! 👋 I've been lurking here for a while, but this topic finally pulled me out of the woodwork. I work with several small non-profits, and we recently undertook a massive project to move our grant tracking from a chaotic mess of spreadsheets and sticky notes (you know the drill) into a more structured system. We seriously considered Runway, given its data workflow and visualization strengths, but ended up going a different route. I wanted to share our thought process and some technical pitfalls we foresaw, in case it helps anyone else in the social impact space.
Our core needs for grant tracking were pretty specific:
* **Timeline & Deliverable Management:** Tracking report due dates, fund disbursement schedules, and program milestones.
* **Financial Reconciliation:** Matching grant awards to actual expenses, often needing to segment budgets by funding source.
* **Compliance & Reporting:** Generating specific outputs for different funders from the same core data.
* **Collaboration:** Allowing program staff, finance, and ED to have tailored views without stepping on each other.
Where Runway seemed to shine for us was in the potential to create beautiful, real-time dashboards for board meetings and to automate some of the data flow from our bookkeeping software. The canvas view could have been fantastic for mapping out the lifecycle of a grant. However, we hit a few conceptual roadblocks during our deep dive:
1. **Data Structure Complexity:** Grant data is relational at its heart. You have a `grants` table, a `financial_transactions` table, a `report_due_dates` table, etc. While you can model this in Runway, it started to feel like we were building a database application from scratch, using tools optimized for a different workflow.
2. **The "Snapshot" Problem:** A big part of our reporting requires "point-in-time" snapshots—what was the budget vs. actual for Q2 *as of July 15th*? Runway's strength is in the *now*, and building historical state tracking seemed like it would require a lot of manual versioning or complex workarounds.
Here's a tiny example of the kind of simple relational logic that becomes cumbersome. In a SQL world, linking expenses to grants is straightforward:
```sql
SELECT
g.grant_name,
SUM(e.amount) as total_spent
FROM grants g
JOIN expenses e ON g.id = e.grant_id
WHERE e.fiscal_year = 2024
GROUP BY g.grant_name;
```
In a tool like Runway, you'd likely be relying on filtering linked records or building multi-step transformations to get that same insight, which adds layers of maintenance.
In the end, we opted for a dedicated cloud-based SQL database (Postgres, my personal favorite ❤️) with a simple web front-end built on top. It was more initial dev work, but gave us the rigid structure and historical audit trail we desperately needed.
I'm still incredibly curious if anyone has gone the *other* way and made Runway work for this! Did you use a particular approach for historical tracking? How did you handle complex budget allocations? Would love to hear your stories and compare notes.
—B
Backup first.