These are the eight questions we hear first from every Transportation Director who calls. If yours isn't on the list, email [email protected] — your question will probably end up on this page next.
Yes — under 49 CFR § 390.32 (Electronic Documents and Signatures). This rule explicitly authorizes electronic signatures on any FMCSA-required document, including the DVIRs required by 49 CFR §§ 396.11 and 396.13. The FMCSA eDVIR Final Rule effective March 23, 2026 cross-references § 390.32 as the operative e-signature authority. A supervisor-assigned 4-digit PIN, applied by the driver at submission, satisfies the rule. See https://onetouchdvir.com/compliance for the full citation chain.
The PWA logs the inspection locally with a UUID and shows the driver a 'not yet confirmed' status with a Retry button. When signal returns, the driver taps Retry and the same UUID re-submits — the backend rejects duplicates, so no double-logging is possible. There is currently no automatic background retry; retry is manual. This is a known limitation in rural low-signal environments and is documented in the FAQ.
Your district. Every customer deployment writes to a Google Sheet owned by the district, not by Ram Venture Solutions. If you stop paying, the system stops writing to the sheet — but the sheet and every historical inspection it contains remains in the district's Google Workspace, in a format any auditor can read without proprietary tooling. No vendor lock-in by design.
Almost none. You don't need an IT department to roll this out. Drivers tap a link, choose Add to Home Screen, and they're done. No app store. No MDM profile. Supervisors get a Google Sheet provisioned under their district account. Mechanics get the same sheet. PINs are managed by the Transportation Supervisor in a sheet tab. The whole onboarding for a typical district fits in roughly 30 minutes of supervisor time. We do the provisioning end of it — your IT contact does not need to be on the call. Districts with a stricter IT policy occasionally want a written security write-up before they sign. We have one, and we'll send it. The short version: data lives in your district's own Google Sheet under your district's own Google account; we don't host a separate database; there is no third-party identity store.
Okanogan School District, Washington — live in production since May 2026. Transportation Supervisor Larry Scroggins, Fleet Mechanic Fausto Munez. Larry was previously paying $30 per seat per month with another vendor; he displaced that tool with One-Touch DVIR at $20 per bus per month and removed the hardware line item entirely. One prior in-house instance at the founder's own crew, archived in May 2026 after validating the architecture under daily real-world use. The Okanogan deployment is the actively developed instance and the customer reference. Larry has agreed to take phone calls from peer transportation supervisors evaluating the system. Email [email protected] if you'd like an introduction. A second case study will be published when the second commercial district lands. We don't pretend to a customer list we don't have.
The signature follows the PIN, not the phone. A driver can use any phone — their replacement phone, a sub driver's phone, a loaner from the garage — and sign in with their PIN. There is no device registration step, no this phone is paired with this account trap. If a driver's phone is lost or stolen, the driver tells the Transportation Supervisor, the Supervisor resets the driver's PIN in the Driver_PINs sheet, and the driver enters the new PIN on the next phone they pick up. The old PIN is now inert. PINs are not stored on the phone. Lost or stolen phones do not expose inspection data, because the inspection data lives in your district's Google Sheet, not on the phone. The phone is a thin client.
The driver gets a Retry button. The inspection is held locally on their phone, marked as unsubmitted, and the driver re-submits when signal returns. The same UUID is reused on retry — so re-submitting the same inspection cannot create a duplicate row in your compliance log. This idempotency is built into the backend. One honest disclosure: there is currently no automatic background retry. The driver has to tap Retry. This is documented in our internal backlog as a known gap for rural low-signal environments. In practice at Okanogan it has not been a daily problem, but if your routes go through dead zones we want you to know about it before you sign, not after. If the bus is in an Out-of-Service state, the driver sees the OOS lockout screen regardless of network condition — that screen renders from local state and does not require a fresh server roundtrip.
The switch usually takes about a week. Day 1: You email Bob with your bus count and target start date. We send a one-page agreement. Day 2–3: Agreement signed. We provision your Google Sheet, your Apps Script instance, and your Netlify-hosted app. Day 4: 30-minute call with your Transportation Supervisor to set up PINs for your drivers. Day 5–7: Drivers install the app to their home screens during their pre-trip routine. You can run the old vendor in parallel during the transition if your contract allows. Data migration: if you need to retain inspection history from your prior tool, export it from that tool (most vendors give CSV exports) and we'll attach it to your new Google Sheet as a Historical_Imports tab so your full record stays in one place. There is no charge for this.
Email [email protected] or call 509-429-9805. You'll get a response from Bob, the founder, who drives a school bus three days a week.