The questions your procurement officer always asks.

No. We have not completed a SOC 2 audit of any type, and we won't imply otherwise. An audit is on our roadmap, and this answer will be updated the day an auditor is engaged. In the meantime we'll complete your security questionnaire honestly and show you how the platform actually works.

No, and we are not in process. For PHAs that require FedRAMP authorization at procurement, we are not a fit today — we'd rather tell you that in one sentence than waste your evaluation cycle.

Not currently. We would pursue StateRAMP where a committed customer's state requires it.

We do not hold a HUD ATO (Authority to Operate). Importantly, the product is designed to stay OUTSIDE HUD systems: it computes and validates within the product and never connects to, transmits to, or files with HUD — your staff submit through HUD's own portals as they do today. In our understanding that boundary generally keeps PHA use of the product out of ATO scope, but your IT security officer makes that call, and we'll complete agency security questionnaires honestly.

No. The application is deployed on Vercel (US region) with a managed PostgreSQL database (US). We do not offer government community cloud or Azure Government hosting today, and we won't claim a hosting posture we don't run.

Not yet bound, so we won't quote coverage amounts. We intend to carry cyber liability + E&O before taking PHA production data under a formal contract, and certificates of insurance will be available on request once policies are in place. Ask us and we'll tell you exactly where this stands.

No, and we don't market the platform for PHI. If your program data includes protected health information, raise it with us before any pilot so we can scope around it honestly.

Not in scope by design. We never touch cardholder data: optional invoice payments run through Stripe Checkout on Stripe's PCI-compliant infrastructure, and tenant payments to PHAs flow through the PHA's existing merchant processor.

Application hosting on Vercel (US) with a managed PostgreSQL database in the US. Data is encrypted in transit (TLS); at-rest encryption is provided by the managed database platform. We do not replicate data outside the US.

We're an early-stage company and will say so plainly: there is no support organization with standing access. The deployment operator holds the database credentials, and application-level access is captured in the server-side audit log. If that posture doesn't fit your risk profile yet, we'd rather you know now.

No statistical model is trained on your data. The categorization, audit, and anomaly engines are deterministic, and the in-app copilot answers from your own aggregated numbers through a deterministic intent router. When you correct a categorization, it becomes an explicit per-vendor rule you can inspect and delete — not a weight in a model.

Tenant isolation is enforced server-side on every request and fails closed in production (requests without a verified session are rejected, not defaulted). Transport is encrypted; at-rest encryption comes from the database platform. We do NOT currently offer field-level encryption of SSN/DOB — and the HUD tools are deliberately designed so you don't need to enter full identifiers: the rent, TTP, and screening calculators work from computation inputs, not SSNs.

You can export your books, reports, and statements yourself (CSV/Excel) at any time — no request or approval needed — and a full workspace reset deletes your documents from the application store on demand. Formal retention and purge schedules are set in the MSA.

Database backups are managed (and encrypted) by the PostgreSQL platform. You can additionally take your own export from the app at any time. We do not operate a separate long-term compliance archive today; if your records program requires one, your exports remain under your retention control.

A server-side audit log records who/what/when for application actions, with versioned backups of changed documents so individual records can be restored. Honest limits: the log is bounded (pruned to a per-key cap) rather than an unlimited 7-year archive, and tamper-evident hash chaining + SIEM export are roadmap, not shipped.

Google and Microsoft OAuth sign-in are built into the product behind a per-deployment activation flag (enabled when the OAuth credentials are configured). SAML (Okta, ADFS, Ping) is roadmap. Today's default is email + password.

MFA is not implemented yet. It is on the roadmap, and we won't claim it until the day you can switch it on. If mandatory MFA is a hard requirement for your procurement today, we are not yet a fit.

Two tiers exist today: full access, and read-only (built for your CPA / auditor / HUD field analyst), enforced server-side on the application's primary write path. Honest limits: enforcement does not yet cover every mutating endpoint, and the check is currently designed to fail open on lookup uncertainty — extending it to fail-closed, full-coverage enforcement is active hardening work. Additional role labels exist on accounts; finer-grained per-role permissions are roadmap, and we label them that way in-app rather than pretending they bind.

Yes — scrypt (a memory-hard KDF from the Node.js standard library) with a per-user random salt and constant-time verification. No password is stored or logged in plaintext.

Sessions are HMAC-signed HttpOnly cookies (SameSite=Lax, Secure) with a 30-day lifetime today. Honest limit: sessions are stateless, so there is no server-side revocation list yet — sign-out clears the cookie, and shorter configurable lifetimes + server-side invalidation are roadmap.

No, and we have no subcontracting vehicle to offer in its place. If your procurement requires a GSA vehicle today, we are not a fit yet.

We are not on any cooperative contract today. A PHA can instead start with a small pilot through unrestricted operating funds under its micro-purchase threshold — see the paths below.

Yes — honestly. If a mandatory requirement (SOC 2, GSA Schedule, Section 3, FedRAMP) rules us out, we'll tell you in the first paragraph instead of padding a response. We don't require an RFP to engage; a pilot is the fastest way to evaluate us.

Our proposed standard terms: 12-month initial term, month-to-month after, 30-day termination for convenience after month 12, no early-termination penalties. These are proposals — we expect your counsel to mark them up.

Proposed: Net 30, invoiced monthly by default (quarterly or annual available), paid by ACH, wire, or check.

Same honest answer as cyber coverage: not yet bound, no quoted limits. Certificates will be available on request once policies are in place — and a contract that requires them is exactly when we'd bind them.

All of our work is remote software delivery — we don't perform on-site or construction-adjacent work at PHA facilities, so in our understanding Davis-Bacon wage determinations generally don't attach to this contract (your counsel confirms). Any on-site request would be scoped case-by-case.

As a small software vendor we do not carry Section 3 hiring commitments, and we won't invent partner arrangements we don't have. If Section 3 weighs in your evaluation, tell us early and we'll be straightforward about fit.

The app runs on Vercel's managed infrastructure, and every push deploys through CI that runs the full test suite and then verifies the live site before the deploy goes green. We propose uptime and service-credit terms in the MSA rather than quoting an unaudited number; the live activation snapshot is public at /status.

Email support, answered directly by the people who build the product. We respond quickly, but we won't claim a 24/7 staffed desk we don't have — formal response-time commitments belong in the MSA where they're enforceable.

There is no CSM organization. You work directly with the builders — which at our stage is genuinely faster than a ticket queue, and we'd rather you know exactly what you're getting.

Every fix ships through a gated pipeline: full test suite (580+ tests), typecheck, build, deploy, and live-site verification — that pipeline is real and runs on every push. We prioritize critical fixes ahead of all other work; formal patch-timeline commitments belong in the MSA where they're enforceable.

We won't quote RPO/RTO numbers we haven't tested under fire. What exists: managed-PostgreSQL platform backups, redundant hosting from Vercel, and self-serve export so you always hold a current copy of your own books.

No. There is no outsourced or offshore support operation — support is handled directly by the company.

Yes — a read-only tier built for your CPA or HUD field analyst, enforced server-side on the application's primary write path (full mutating-endpoint coverage is active hardening work — same honest limit as the RBAC answer above). Activity history and change logs are visible in-app.

No — same posture as SOC 2: no audit has been performed, and we won't dress that up with bridge letters that don't exist. Our financial logic is deterministic and documented, which your auditor can evaluate directly (below).

Yes. Audit and financial reports are deterministic: the same inputs produce the same outputs, and audit runs carry a fingerprint of the input data so a re-run can be checked against the original.

Yes. The engines (categorization, reconciliation, audit, FDS, rent/TTP) are deterministic and documented with citations to the governing regulations, and the reference values they compute from carry dated sources. The in-app methodology pages and the dated source registry are available to your CPA without an NDA.

Our proposed cutover method runs both systems side-by-side: variances above the agreed threshold pause cutover until they're root-caused (timing differences, category mapping, or inherited data errors), and the legacy system stays authoritative until you sign off.