A marketplace that moves other people’s money.

The applicant never types identifying information into this app. Roost Assured creates a candidate and an invitation on Checkr, and Checkr emails the applicant a link to its own hosted portal, where consent, SSN and date of birth are collected. What comes back here is a status string.

candidate = client.post("candidates", {
  email: sitter_application.email_address,
  first_name: first_name,
  last_name: last_name,
  zipcode: sitter_application.zip_code
})

invitation = client.post("invitations", {
  candidate_id: candidate["id"],
  package: CheckrConfig::PACKAGE
})

sitter_application.update!(
  checkr_candidate_id: candidate["id"],
  checkr_invitation_id: invitation["id"],
  background_check_status: "invited"
)

1. Application submitted, fee charged

   An on-session Stripe charge for $50, restricted to card payment methods so no redirect-based method can demand a return URL mid-flow. A prior paid-but-unsaved attempt is reused rather than billed twice.

2. Candidate and invitation created

   Two calls to Checkr. Failure here is caught and logged rather than raising — the application is already saved and paid for, and losing it because a third party had a bad minute would be the worse outcome.

3. The applicant completes the check on Checkr’s portal

   Out of this system entirely. Roost Assured holds a candidate_id and an invitation_id and nothing else.

4. Checkr calls back, signed

   Every webhook is HMAC-verified before it is believed, and every event id is recorded so a redelivery can’t be processed twice.

5. Approval is gated on the result

   An admin cannot approve an applicant whose report came back consider or suspended without an explicit override — and the override is written to the record.

digest = OpenSSL::HMAC.hexdigest(
  "SHA256", CheckrConfig.webhook_key, payload
)
return nil unless ActiveSupport::SecurityUtils
  .secure_compare(digest, signature)

def approvable?(override: false)
  background_check_cleared? || override
end

The disclosure is a page, not a checkbox

Consent to a background check is a legal act with its own requirements, so it gets a real page explaining who performs the screening, what it covers, and what the applicant can do about a result they dispute.

It is linked from the footer of every page and from the application flow itself, so the terms an applicant is agreeing to are reachable before they agree rather than buried in an acceptance checkbox.

1. Reserve, under the lock

   Re-check the guards and write a pending payment row carrying a freshly generated idempotency key. Local writes only — nothing external is touched.

2. Commit

   The transaction closes here. From this moment the reservation is durable, so the already-paid guard is backed by a committed row before a single cent moves.

3. Charge, outside any transaction

   One PaymentIntent, confirmed off-session, with a destination transfer and an application fee. Nothing can roll it away, because there is nothing to roll back into.

4. Promote the bid

   Only now does the bid become accepted and the competing bids get rejected. The bid is never in a state the money doesn’t back.

The ordering is the whole design. A payment provider has no way of knowing that a database transaction rolled back, so the reservation is committed before any money moves — which means the guard against charging an owner twice is backed by a durable row rather than one that could disappear from underneath it.

@bid.with_lock do
  rejection = guard_reasons_for(@bid)
  payment = BidPaymentService.new.reserve!(@bid) if rejection.nil?
end
# ── committed ─────────────────────────────────────────────

BidPaymentService.new.charge!(payment)

@bid.with_lock do
  other_bids.update_all(status: "rejected")
  @bid.update!(status: "accepted")
  @bid.seed_job_tasks!
end

intent = ::Stripe::PaymentIntent.create(
  {
    amount: (payment.amount * 100).round,
    currency: "usd",
    customer: owner.stripe_customer_id,
    payment_method: owner.default_payment_method_id,
    confirm: true,
    off_session: true,
    application_fee_amount: (payment.application_fee_amount * 100).round,
    transfer_data: { destination: sitter.stripe_account_id },
    # lets the webhook find this row even if the response never lands
    metadata: { payment_id: payment.id, bid_id: bid.id }
  },
  # collapses a retry into the original charge instead of billing twice
  idempotency_key: "payment-#{payment.idempotency_key}"
)

rescue ::Stripe::CardError => e
  # Definitive: no charge was created. Release the reservation so the
  # owner can try a different card.
  payment&.update!(status: "failed")
  render json: { errors: [ e.message ] }, status: :unprocessable_entity

rescue ::Stripe::StripeError => e
  # Ambiguous — a timeout, a reset. The charge may well have landed.
  # Leave it pending: the guard stays armed so a retry can't bill twice,
  # and the webhook settles it either way.
  render json: { errors: [ "We couldn't confirm that payment." ] },
         status: :bad_gateway

The webhook is what closes the loop — and it has its own race. Stripe frequently delivers payment_intent.succeeded before the API response carrying the intent id has been written down. Looking the row up by that id alone loses; and because the event was already recorded as processed, the retry is dropped too, stranding the payment in pending forever.

def find_payment(intent)
  by_metadata = intent.metadata&.[]("payment_id")
  (by_metadata && Payment.find_by(id: by_metadata)) ||
    Payment.find_by(stripe_payment_intent_id: intent.id)
end

databases:
  - name: roost-assured-db
    plan: basic-256mb

services:
  - type: web
    name: roost-assured-web
    runtime: docker
    healthCheckPath: /up
    disk:                          # uploads survive a deploy
      mountPath: /var/data
      sizeGB: 1

  - type: worker
    name: roost-assured-worker
    runtime: docker                # same image as the web service
    dockerCommand: bin/rails solid_queue:start

Mail that renders anywhere

Five mailers carry the transactional traffic: the waitlist welcome, password resets, the new-request receipt, the nearby-sitter alert, and the sitter-is-on-the-way notice. Delivery goes through Resend’s SMTP relay rather than an API client, which keeps it ordinary Action Mailer — the provider is four lines of configuration and nothing in the app knows its name.

config.action_mailer.delivery_method = :smtp
config.action_mailer.smtp_settings = {
  address: "smtp.resend.com",
  port: 587,
  user_name: "resend",
  password: resend_api_key,
  authentication: :plain,
  enable_starttls_auto: true
}
# fail loudly rather than dropping mail silently
config.action_mailer.raise_delivery_errors = true

app/views/sitting_request_mailer/
  receipt.html.erb
  receipt.text.erb
  new_request_alert.html.erb
  new_request_alert.text.erb

app/views/application_mailer/
  _button.html.erb   # table-based CTA

Notable dependencies

Sixteen runtime gems, most of them Rails’ own. The ones worth explaining:

stripe

The official SDK, pinned to v13. Connect Express accounts for sitters, destination charges with an application fee, and a pinned API version so a Stripe-side upgrade can never change behaviour without a deliberate bump.

faraday

Checkr publishes no official Ruby gem, so its client is about twenty lines of Faraday with basic auth and JSON middleware. A thin wrapper beats an unmaintained third-party SDK for two endpoints.

bcrypt

Authentication is Rails’ own — has_secure_password, signed cookies, and a Session model with inactivity and absolute timeouts. Devise would have been more code to configure than to write.

solid_queue
solid_cache
solid_cable

Jobs, cache and websockets on Postgres. No Redis, which at this size is a service to provision, monitor and pay for in exchange for nothing.

rack-attack

Edge throttling by IP for login, signup, password reset, the admin surface and the webhook endpoints — before a request reaches anything expensive.

vite_rails

React 19 built by Vite and served by Rails from one origin. Replaces the Sprockets/Webpacker split with one build that the Docker image runs at precompile time.

image_processing

Active Storage variants for sitter profile photos and the job-completion photos, backed by libvips in the image rather than the heavier ImageMagick.

thruster

Sits in front of Puma for HTTP caching, compression and X-Sendfile, so the app can serve its own static assets without a separate proxy tier.

brakeman
bundler-audit

Static analysis and a dependency CVE check, both gating CI alongside RuboCop, ESLint and the test suite. Five gates, all green.