Power Apps / Dataverse developer - check-in, service queues and booking system for a drop-in center

ABOUT US

Liberation Programs is a nonprofit in Fairfield County, Connecticut. We are opening Rest Here, a drop-in center in Bridgeport for people who use drugs and people experiencing homelessness. People come in for showers, laundry, wound care, meals, haircuts, benefits navigation, and a place to sit that isn't the street.

WHAT WE NEED BUILT

A simple, welcoming system that records who comes in, helps people get to the services available that day, and reports what was actually provided. It runs on a reception computer, a mounted iPad at the front desk, staff phones and tablets, and a TV in the waiting area.

Two things come together in one shared member record: member check-in with meal tracking, and service booking.

CORE FUNCTIONALITY

Check in once. Find a member by ID card, name, nickname, chosen name or date of birth. Every visit and service links to one permanent internal member ID. Staff-assisted registration for new visitors. The kiosk clears itself after every transaction and never shows a list of other members.

Four ways to join a service. A queue (join the shower list), an appointment (pick a time), a capacity booking with standby (30 places for dinner), or drop-in (just show up).

Physical resources. Two showers share one queue, two laundry units share another. Each unit has states: available, occupied, cleaning, finishing soon, out of service. The system assigns the next person to a unit that is genuinely ready.

Practitioner workflow. Ready, start, then an outcome: completed, not completed with a reason, or did not attend. A short private note can be attached to an encounter.

Public display. A TV in the waiting area shows today's activities and discreet calls to service. No birthdays, no clinical detail, no private notes.

Staff-managed schedule. Staff add an activity and its rules in one short form, including recurrence like third Tuesday of each month. Changing or cancelling one occurrence must not break the series or lose past attendance. The app holds the authoritative schedule and publishes a read-only copy to a shared Outlook calendar.

Meal service. 30 meals, 5 held back for people volunteering that day. A kitchen volunteer sees today's checked-in members, searches, and taps meal served once. Duplicate taps must be prevented. Authorized corrections are kept with their history.

Reporting. A daily Excel workbook and matching CSVs generated automatically and emailed to two named managers. Restricted notes go in a separate authorized report, not the routine one.

Permissions. Reception volunteers, practitioners, managers and public screens each see only what they need. Enforced on the data and the exports, not by hiding buttons.

TECHNICAL DIRECTION

Our organization runs on Microsoft 365. Our working assumption is Power Apps for staff operations, Dataverse for the records and restricted notes, and Power Automate for the Outlook publication and the daily reports. We are open to being told we are wrong, but you will need to make the case.

Two things we specifically need you to resolve rather than assume.

1. The walk-up kiosk. A Power Apps canvas app does not give anonymous walk-up access for free. Entra guest access, Power Pages, or another approved front end all have licensing and design consequences. We need a confirmed, costed answer, not a shared staff login and a shrug.

2. The membership card. We are producing magnetic stripe cards on a Magicard printer with a USB keyboard-emulation reader at the desk. The card carries a number only, no clinical data. You will need to demonstrate the actual reader working on the actual reception device.

RELIABILITY WE ARE NOT FLEXIBLE ON

Two devices trying to take the last dinner place at the same moment: exactly one succeeds, validated server side.

Background retries must never create duplicate bookings or promote a standby person twice.

The display updates within about 10 seconds on our network.

Connection loss is visible. An unsaved action is never shown as successful.

Separate test and live data, backups, and an exportable handover.

HOW WE WANT TO RUN THIS

Fixed price, with payments tied to working demonstrations rather than hours logged. We want to start with a short, fixed-price discovery and working prototype before committing to the full build.

Stage 1, discovery. Confirm service rules, our Microsoft access, kiosk and display licensing, note permissions and report recipients. Deliver a short architecture document, a monthly running cost breakdown, and a firm quote for the build.

Stage 2, working prototype. Show the approved design on a real iPad and a real computer. One check-in, one booking, one person called on the display, one outcome recorded, one sample export.

Stages 3 to 5. Core build, supervised pilot, then launch and handover.

We will award stage 1 as its own contract. Doing well there is how you get the rest.

WHAT WE WILL GIVE YOU

A written specification with the full data model, screen direction, acceptance checks and open decisions. An approved visual design direction. A named project lead who can make operating decisions, an IT administrator for accounts and devices, and a clinical lead for the notes questions.

WHAT WE NEED IN YOUR PROPOSAL

Your fixed price for stage 1, and roughly what you would expect the full build to cost. A range is fine at this point.

One system you have built that is comparable, with what it did, what went wrong, and what went right.

Your answers to the screening questions. Please answer them properly, they are how we shortlist.

You can work on US Eastern Time.

Please do not send a generic proposal. We will read the ones that engage with the two unresolved questions above and ignore the rest.