What It Looks Like on Both Sides
Two screens from the running demo: the one a student uses standing at an event, and the one your program coordinator opens the next morning.
Greater Angels Software builds student-facing software for public universities, and we work with campus departments directly: the offices that run programs and then have to prove the programs worked. Nothing on this page is a mockup. Every claim points at software you can open right now, or at a document you can read without asking us for it.
The system shown throughout this page is the SHS Digital Wellness Passport, built for CSU Bakersfield Student Health Services at the Cal Poly Digital Transformation Hub’s 2026 AI Summer Camp, a program powered by AWS that sources real problems from across the CSU system. The demo runs on synthetic data; no student data is used. It is a camp prototype, and production hardening for a fall campus deployment is in active discussion with campus stakeholders. We will not describe it as anything else.
A multi-week wellness challenge is not hard because the idea is hard. It is hard because attendance arrives as paper, the numbers get assembled by hand weeks later, and nobody can fully defend them when a dean asks.
Students check in by scanning the event QR on their own phone, at the event, in about a second. Attendance is captured where it happens instead of tallied afterward, and the dashboard splits scanned check-ins from staff-verified ones, so you always know which number came from where.
Per-week completion funnel, attendance by capture method, content and guide engagement, learning outcomes rolled up by the tag your staff attached when they wrote the question, and a prize-eligible CSV export. All queryable the moment an event ends rather than three weeks after the challenge closes.
A duplicate scan is rejected by a uniqueness constraint in the database, not by a person noticing. A poster left up from last semester cannot credit this semester’s task, because the signed code carries the event it was minted for. When somebody asks how you got the number, there is an answer.
Two screens from the running demo: the one a student uses standing at an event, and the one your program coordinator opens the next morning.
Three reviews decide whether a promising campus pilot ever reaches students. Most prototypes meet them for the first time after somebody has already promised a launch date. We arrive with the paperwork finished and published.
A product-level Accessibility Conformance Report in VPAT form, covering all 50 WCAG 2.1 Level A and AA success criteria, one row each, with the evidence cited per row. Automated axe-core sweeps gate every CI run; the full student journey was additionally driven keyboard-only at a phone viewport.
Writing it found three real defects, which were fixed before the report shipped. It also records what we could not do: no NVDA, JAWS, or VoiceOver session was available, so screen-reader behavior is inferred from the browser accessibility tree and logged as a residual rather than claimed as heard. Read the ACR.
A completed HECVAT Lite, structured the way your security analyst expects. Every row that states a configuration fact, cookie flags, token algorithm and lifetime, rate limits, response headers, states the live value and cites the file and line it is read from.
A test in the build reads those same values out of the running code and compares them against the document. If the code changes and the answer sheet does not, the build fails. The security questionnaire cannot quietly go stale between your review and your renewal. Read the HECVAT Lite.
SAML single sign-on sits behind a provider seam, with an issuer-to-campus registry, so onboarding a second campus is a configuration entry rather than a fork of the codebase. Sign-in stores an opaque SSO subject and the affiliation your IdP asserts, nothing more.
A mock identity provider ships alongside it, which is why the demo above is open to you right now. Your team can evaluate the whole product before ITS provisions a single thing.
The first question a student health office asks about any digital wellness tool is what it holds about students. The answer here is structural: the columns that would worry you do not exist in the database.
| Column | What it holds |
|---|---|
campus_id |
Which campus the sign-in came from |
sso_subject |
The subject identifier your identity provider asserts, exactly as it hands it to us |
affiliation |
Student or staff, as asserted by your IdP |
created_at |
When the record was first created |
Innovation programs are excellent at proving what is possible. The step after — the one where a real cohort of students hits it on event night and a named person is responsible when it breaks — is where most campus prototypes quietly stop. That step is our business. Here is what a hardening engagement actually contains.
Every item above already exists for the Wellness Passport, which is why we can list them rather than propose them. You can read the requirement, the scenarios that verify it, and the architecture diagrams that document it, all of it, at docs.greaterangelssoftware.com.
You should not need a systemwide solicitation to try something on one campus, in one department, for one semester.
Every engagement starts as a fixed-scope, fixed-price package with success criteria written into the statement of work. Tell us the threshold your department can approve without a formal solicitation and we will size the first package to fit under it, rather than proposing something that needs a budget cycle and a committee.
We are a California DGS Certified Small Business (Cert #2052888), SAM.gov registered, and headquartered in Los Angeles County. The registrations and codes your purchasing office will ask for are on our Government page.
If the work belongs inside a larger campus engagement, we take the specialist scope as a subcontractor under your prime: identity and SSO integration, accessibility conformance, AI governance and human-in-the-loop controls, and the acceptance artifacts a campus review will ask for.
And if a piece of scope is not ours to claim, we will say so before you write us into anything. We would rather lose a line item than hand a campus a surprise.
The ones that come up in the first meeting, answered without hedging.
No, and the reason is structural rather than procedural. The student record has four columns: campus, the SSO subject your identity provider asserts, affiliation, and a creation timestamp. There is no name, no 9-digit ID, no password, and no clinical field anywhere in the schema. The product records program engagement, that a student attended an event and how they scored on a knowledge check, not care. If your campus wants that conclusion reviewed rather than asserted, the schema and the tests that pin it are published for you to check.
The difference between a demo and a system somebody owns. A prototype proves the idea; it usually has no migrations, no secrets management, no monitoring, no rate limiting, no load validation, no accessibility report, and no runbook, and it has never met your ITS security review. That list is exactly the hardening scope above. We are not proposing to rebuild what a camp team already proved. We are proposing to make it survivable.
For the Wellness Passport, yes: a product-level Accessibility Conformance Report in VPAT form, covering all 50 WCAG 2.1 A/AA criteria with per-row evidence, published at docs.greaterangelssoftware.com. It is scoped to that product, and it says plainly which criteria are fully supported, which are partially supported with an alternate-access note and a remediation date, and where the evaluation itself has gaps. Company-wide conformance documentation is in process and marked that way on our certification roadmap.
We cannot promise you an outcome your own security office controls, and any vendor who does is telling you something they cannot know. What we can do is hand your analyst a completed HECVAT Lite on day one, with every configuration answer citing the file and line it comes from, so the review is a verification exercise instead of a discovery exercise. Where a control is met by an equivalent mitigation rather than the exact mechanism asked about, the row says so.
Yes, and it was built that way from the first story rather than retrofitted. Identity resolves through an issuer-to-campus registry, and student records are unique per campus, so a second campus is a configuration entry and its own data, not a fork. That said: it has been proven against one campus’s identity provider so far. A second campus is a small, real integration, and we will scope it as one instead of pretending it is free.
You keep it, in open formats, and we will hand over an export as a deliverable rather than as a negotiation. Reports already export to CSV. The system runs in containers on standard infrastructure, so there is nothing proprietary holding your program hostage if you decide to run it yourselves or move on.
A team of early-career engineers working under a Senior Principal Software Engineer’s direct supervision, the teaching-hospital model: leadership reviews and signs off on every line, and nothing ships without passing a test-driven pipeline. It is how we deliver production-grade software at new-grad wage rates rather than national-vendor billable rates, and it is the subject of our peer-reviewed engineering-education research. Several of our engineers are recent CSU graduates, which is not incidental to why we care about this work.
If your department has a prototype that proved its point and then ran out of runway, that is the conversation we most want to have. We respond within one business day, or book a 30-minute intro call directly.