Planning Out Pediment
A couple of weeks ago I wrote about a pattern I noticed in the MuseumPros subreddit: small museums are stuck with expensive, overcomplicated software that doesn’t fit how they actually work. I spent the next month validating whether there was a real market gap worth building for.
I read through years of discussions and talked to a friend who volunteered at a small museum. The same problems kept coming up: too expensive, too complicated, stuck with workarounds because nothing fits their budget. That confirmed the gap, so I decided to build something.
The big names like Tessitura and Altru start at $20,000 a year. They’re built for large institutions with dedicated IT staff. That leaves small museums running on spreadsheets and sticky notes because nothing between free and enterprise exists.
Who I’m Building For
The Users
| Persona | Role | What they need |
|---|---|---|
| Mike | Front desk volunteer | Check in members and sell tickets fast without retraining every shift |
| Sarah | Museum director | See how the day is going, find member records instantly, stop digging through spreadsheets |
| Judy | Membership coordinator (part-time) | Track renewals, know who’s lapsed, generate reports for grant season |
| Tom | Treasurer (board volunteer) | Get attendance and revenue numbers emailed as a PDF without calling Sarah |
Their Stories and Flows
Now that we know our users, we write their user stories: short descriptions of things someone needs to do and why. I’ll write them for every feature before I build anything. The format is simple: “As [person], I want [something], so that [reason].” This forces me to think about who benefits and what problem I’m actually solving, not just what I feel like coding.
Examples
| User Story | User Flow |
|---|---|
| As Mike (front desk), I want to sell a general admission ticket to a walk-up visitor in under 15 seconds, so that I don't hold up the line during busy hours. | Mike selects ticket quantities, the total updates in real time, a donation prompt appears, he picks a payment method (cash, check, or comp), asks for an email for the receipt, and the sale is complete. The visit is recorded, and if the visitor is new, a contact record is created automatically. |
| As Sarah (director), I want to see today's transactions sorted by payment method, so that I can quickly reconcile cash and check at the end of the day. | Sarah opens the app and sees a summary of cash, check, and comp transactions. She can drill into an itemized list if something looks off. |
| As Judy (membership), I want to create a new membership record at the front desk or from my desk, so that the member gets their card and starts receiving benefits immediately. | Judy enters their name, email, and address, picks a membership level, takes payment, and the system sends a welcome email automatically. If the visitor already exists as a contact, it attaches the membership to their existing record. |
| As Tom (treasurer), I want attendance and revenue numbers emailed to me as a PDF each month, so that I don't have to bother Sarah for updates. | Tom opens his email. That's it. The system generates and sends it monthly without anyone lifting a finger. |
Feature Set
Based on the user stories and flows, I prioritized the following features. The core ticketing and check-in flows come first since they’re the highest-frequency pain point for every museum, every day. I’ll build the ticketing flow with automated tests around every payment path since a bug there means a real museum can’t sell tickets. Reporting and email come after since they depend on having actual data flowing through the system first.
| Feature | Component | Why it’s critical |
|---|---|---|
| Front-desk ticketing | Cart UI | So Mike can sell tickets fast and Sarah gets an accurate count at the end of the day |
| Front-desk ticketing | Cash/card/check/comp flows | So Mike can handle whatever payment a visitor walks in with |
| Member check-in | Member lookup by name or email | So Mike finds members in seconds at the front desk without asking for a card |
| Membership tracking | Levels | So Judy can offer the right options and track who’s at what tier |
| Membership tracking | Expiration tracking | So Judy never misses a lapsed member who’s up for renewal |
| Membership tracking | Renewals | So Judy can send renewals at the right time without tracking every date manually |
| Donor tracking | Basic entry | So Judy can issue tax receipts and Tom has records for audit |
| Donor tracking | Reports | So Sarah can see giving patterns and target fundraising without digging through old records |
| Invoicing | Basic entry | So Tom can bill schools and groups without building invoices from scratch |
| Invoicing | Payment tracking | So Tom knows who’s paid and who’s still outstanding at a glance |
| Basic reporting | Dashboard and reports | So Sarah can see attendance and revenue trends without digging through spreadsheets |
| Email integration | Google OAuth setup | So visitors get receipts from the museum’s address, not a random no-reply |
| Email integration | Welcome and receipt emails | So members get their welcome instantly without Judy sending each one by hand |
| Email integration | Outlook OAuth setup | So museums on Microsoft don’t have to switch email providers to use the app |
The features below are on the roadmap but deferred past the initial build since they either depend on core flows being live or serve narrower use cases.
| Feature | Component | Why it’s post-MVP |
|---|---|---|
| Online ticketing | Public listing, checkout, email confirmation | Mike handles walk-ins at the front desk for now. Online sales add payment gateway and auth complexity before the in-person flow is proven |
| Mixed payments | Split tender, partial payment tracking | Tom reconciles single payments just fine. Split tender adds edge-case complexity for a rare scenario |
| QR code check-in | QR generation, scanner, member portal | Mike can look up members by name in seconds. QR is a speed boost for something that already works |
| Grants management | Records, status tracking, reporting | Judy’s core job is membership and renewals. Grants support a subset of museums and can wait |
| W9 collection | Upload portal, secure storage, status tracking | Tom handles contractor paperwork seasonally. Not a daily operations need |
| Contracts module | Templates, e-signature, document storage | Sarah hires contractors occasionally. Contracts can live outside the app for now |
| Audit log | Event capture, log viewer, search | Sarah and Tom would use it, but the museum runs fine without launch-level audit trails |
| Email template editor | UI, variable insertion, preview | Judy can use the default templates. Customization is polish, not necessity |
For the MVP, I’m focusing on front-desk ticketing and member check-in. Donor tracking, invoicing, and reporting come next once those core flows are solid and I’ve tested them with real use.
The biggest risk is that small museums won’t pay for software when they’ve been getting by with spreadsheets. I’ll test that assumption by putting the MVP in front of actual museum staff before building anything more. If the pricing or the product doesn’t stick, I’d rather find out early.
Next up: I’ll build the core ticketing flow with unit tests for the pricing logic, integration tests for the database queries, and end-to-end tests that walk through a complete sale from a real browser. I’ll share what I learn deploying it.
Continue reading
Two Months of Building Pediment
Two months in, Pediment has evolved from sketches to something real. Here's where we are.
I'm Building The Pediment App For Museums
After stumbling onto Reddit complaints about museum software, I decided to build an alternative.
I Built a Body Clock for ADHD Brains
I built an app because I keep forgetting to drink water. It turns out thousands of other people have the same problem.