Aimone Advisory Book a call
← All work
Custom app · mortgage broker

Fundrail: one screen instead of opening every loan file

An app built around how one mortgage broker works. Calls, texts, emails and voice memos file themselves on the right client.

"I used to open every loan file each morning to see where things stood. Now one screen tells me who needs a call and what documents are missing."

Independent mortgage broker
Fundrail's Today screen on a laptop and a phone

What changed

The situation

The broker works three licensed roles at once. His mornings started in the loan system, opening each file one by one. Follow-ups slipped, and documents arrived in pieces across email and text.

Off-the-shelf CRMs wanted him to type everything in. His work happens on the phone.

What I built

One list from first call to closing

Every client sits on a single list with the next step, open tasks and quiet days in view.

Touches file themselves

A recorded call, a text, an email or a voice memo lands on the right client automatically, with a plain-English summary.

Promises become tasks

"I'll send the pay stubs Friday" turns into a dated task, owned by the right person, without duplicates.

An off-track list ranked by what's at stake

Clients who've gone quiet too long for their stage rise to the top, sorted by how much is at risk. An optional Monday digest can land before the week starts.

Compliance reminders, not roadblocks

The app warns on files that need attention under the rules he works under. It never blocks him.

The rule that makes it trustworthy

AI suggests; the broker decides. The system never moves a client between stages on its own. It flags a suggestion and waits for a yes. Every number traces back to the call or message it came from.

Why custom, and why now

When the tool fits the day, he uses it, and the morning file-by-file review goes away. Because the whole stack is one template, the same system can be stood up for a second broker in its own account in an afternoon.

How it fits together

The app, a small intake function, a queue and a worker that handles transcription, AI and filing, all in one AWS account built for this client.

Fundrail architecture on AWSCLIENT AWS ACCOUNT · ONE PER CLIENT · US REGIONS ONLYGUARDRAILS · SAME ACCOUNTOUTSIDE12345678910Brokerweb app,any deviceTwiliobusiness line:calls + textsGoogleGmail +CalendarCloudFrontserves the app froma private S3 bucketCognitopersonal sign-insHook functionLambda URL:auth, sync, intakeS3 recordsclients, touches,call audio · versionedSQS queue+ dead-letter queueParameter Storeencrypted secretsEventBridgeschedules + job eventsWorker functionLambda: one itemat a timeTranscribecall audio to textBedrockClaude: summary,tasks, meetingsSESoptional digestCloudWatchalarms + dashboardSNSalerts, businesschannels onlyBudgetsmonthly capCloudTrailaudit log

Colors follow AWS service categories; grey is outside the account; dashed lines are background paths. Swipe the diagram sideways.

Step by step
  1. The broker opens the app on any device. CloudFront serves it over HTTPS from a private bucket; Cognito handles his sign-in.
  2. The app syncs records, uploads voice memos and asks the system to send texts or emails, all through one hook function.
  3. His business line (Twilio) posts call recordings and inbound texts to the same hook.
  4. The hook reads and writes the client record store in S3, with a lock so two changes can’t overwrite each other.
  5. Slow work goes onto an SQS queue, so the phone and the app always get an instant answer.
  6. The worker takes one item at a time, so filing is always in order.
  7. Audio goes to Transcribe. When the transcript is ready, EventBridge puts it back on the queue.
  8. Bedrock (Claude) reads the transcript and pulls out the summary, promises, meetings and any stage suggestion.
  9. Deterministic rules match the client, file the touch, turn promises into tasks and save the record.
  10. Emails go out as the broker through Gmail, meetings go to his calendar, and the optional Monday digest goes out through SES.

Technical details

For your IT person: components, trade-offs and security. Open any section.

Components
LayerServiceWhat it does here
EdgeCloudFront, S3, ACMServes the single-page app from a private bucket over TLS 1.2+ on a custom domain. DNS stays in Cloudflare, set to DNS only.
IdentityCognitoPersonal sign-ins for the broker and for me as admin. There are no shared passwords.
IntakeLambda (function URL)One hook handles app sync, memo and transcript uploads, and Twilio call and text webhooks. It authenticates each caller, stores media, queues work and returns at once.
QueueSQS + dead-letter queueSeparates intake from processing. Anything that fails repeatedly moves to the dead-letter queue and raises an alarm instead of vanishing.
ProcessingLambda workerSends each item to the right step by type: audio, text, email poll, calendar, digest. Concurrency is capped at one, so filing happens in order.
SpeechAmazon TranscribeAsynchronous transcription of recorded calls and voice memos. Its completion event comes back through EventBridge.
AIAmazon Bedrock (Claude)Structured extraction: summary, promises with owner and due date, meetings, risk flags and a suggested stage. The prompt is version-controlled with the code.
RecordsS3 (versioned)Clients, touches, tasks and meetings in one document with an optimistic lock. Every prior version can be recovered.
SchedulesEventBridgeA Gmail poll every five minutes, the optional Monday digest, and Transcribe job events.
OutboundTwilio, Gmail API, Calendar API, SESTexts from the business number, email sent as the broker, calendar events, and the weekly digest.
SecretsSystems Manager Parameter StoreEncrypted API keys and tokens, read when a function starts. Nothing secret lives in the code.
OperationsCloudWatch, SNS, Budgets, CloudTrailAlarms on errors and on the dead-letter queue, a dashboard, a monthly spending cap and a full audit trail.
DeliveryCloudFormation (SAM)One template builds the whole stack. Sandbox and production run as separate stacks, and an offline test harness drives every route with stubbed services.
Design decisions and trade-offs
One record document, not a database (yet)At one broker’s scale, a single versioned JSON document in S3 is faster to reason about, trivial to export and impossible to drift out of sync with the app. DynamoDB comes in when the second broker does, not before.
Function URLs instead of API GatewayA plain HTTPS endpoint on the function is free at this scale and removes a moving part. The trade-off is no built-in throttling, which one broker doesn’t need.
Rules first, AI secondMatching a touch to a client is deterministic: phone, then second phone, then email, then name. AI only reads and suggests. That keeps results repeatable and explainable.
Check before actingThe broker can change anything at any time, so every automated update re-reads the current state before it writes. Nothing is applied from a stale copy.
US regions onlyAn organization policy pins the account to US regions. AI inference is allowed only across US regions, where the current models require it.
Stack per clientEvery resource is scoped to its stack. A new broker gets a clone in a separate account, with nothing shared except the code.
Security and privacy
  • The client's data lives in an AWS account that is his alone, not in a shared multi-customer database.
  • Buckets are private. Only CloudFront can read the app files, and only the functions can touch records.
  • Each function has a role scoped to exactly what it needs.
  • Recorded calls play an announcement first, and each record notes that it did.
  • Alerts go to business channels only, never to a personal inbox.
  • CloudTrail keeps an audit log of every change to the account.
The public demo

The live demo runs the real app code in your browser. The storage, queue and AI steps are replaced with in-browser stand-ins, and the data is a fictional brokerage. Nothing you type leaves your browser. The build fails if any real client detail slips in.

What's next
  • Native lead capture, so the third-party lead tool can be retired.
  • Tighter sync with the loan system.
  • A records database for multi-broker use.

Want something like this?

Tell me how the work moves today. I'll tell you what I'd build and what it would cost.

More write-ups