No-code developer to build internal staffing app (Airtable + Softr/Glide + Make)
Build an internal staffing app using Airtable, Softr/Glide, and Make
Build a no-code internal staffing tool to coordinate performers and gigs, replacing WhatsApp polls and spreadsheets. The app will include role-based logins, master gig list, bid flow, lock/unlock, drop-out requests, and integrations with Google Calendar, email, SMS, and iCal feeds. Delivered in three milestones: core app, integrations, and polish/handover with two weeks of post-launch support.
Why This Role?
Clear scope with prototype and build brief provided upfront
Key Responsibilities
- Build the core staffing app with schema, logins, master gig list, staffing controls, bid flow, lock/unlock, and drop-out tracking
- Implement integrations including Google Calendar import, email and SMS notifications, iCal feeds, and Add-to-calendar .ics generation
- Deliver polish and handover including mobile responsiveness, admin runbook, credential transfer, and two weeks of post-launch bug-fix suppor
- Structure work around three defined milestones with clear acceptance criteria for each phase
- Propose alternative no-code stacks with justification if they ensure maintainability by non-developers
Requirements
- Experience building comparable no-code apps using Airtable, Softr or Glide, and Make
- Ability to justify and implement alternative no-code stacks that remain maintainable by non-developers
- Experience with role-based logins, data modeling, and workflow automation in no-code platforms
- Familiarity with integrating Google Calendar, Twilio or equivalent for SMS, and iCal feed generation
- Experience delivering fixed-price projects with clear milestones and acceptance criteria
Required Skills
Keywords
View Original Description from Contra
Original description from Contra
We're a Scottish entertainment agency looking for an experienced no-code developer to build an internal staffing tool - a small web app that lets us coordinate which performers play which gigs, replacing a mess of WhatsApp polls, spreadsheets and a third-party reminder app. Scope is well defined. We have: • A clickable prototype demonstrating the key screens and interaction which we've built using Claude. • A written build brief covering data model, flows, integrations, edge cases and milestones. We will share both with the right candidate. Project snapshot • approx. 20 performers, approx. 150 gigs/year • Two user roles (Admin, Performer) with role-based logins (i.e. log in for each of the 20 performers). • Master gig list, slot-based line-up with soft instrument rules, bid flow ("I'm in / Decline"), team lock-in, drop-out request flow. • Integrations: Google Calendar (read, via existing Studio Ninja (our current CRM) iCal feed), email + SMS notifications (Twilio or equivalent), per-performer iCal subscription feed, per-gig "Add to calendar" .ics, day-of SMS reminder. • No payment processing; no client-facing features; financial tracking stays in our existing Google Sheet ledger so no need for integration. Preferred stack (but happy to take suggestions): Airtable (data) + Softr or Glide (interface/logins) + Make (automations). Open to alternative no-code stacks with strong justification, provided the result is maintainable by a non-developer (we are musicians, not software developers!) Deliverables, three milestones: Core staffing app - schema, logins, master list, gig detail with staffing controls, bid flow, lock/unlock, drop-outs, response tracker (approx. 50% of cost) Integrations - Google Calendar import, email + SMS, iCal feed, Add-to-calendar, day-of reminder (approx. 35%) Polish & handover - roster management, mobile responsiveness, admin runbook, credential transfer, two weeks of post-launch bug-fix support (approx. 15%) We own all accounts and credentials at handover. In your proposal, please include: Relevant experience with this stack - links to two or three comparable builds you've delivered. Estimated cost (fixed-price preferred) and timeline. How you'd structure milestones and what counts as acceptance for each. Any questions or pushback on the brief - we'd rather hear it now than during the build. Prototype link: