When Logic Square was handed the CloseWise project, the brief sounded straightforward:
"Build a platform for notaries and loan signing companies."
It wasn't straightforward.
What followed was one of the more technically interesting SaaS builds we've worked on — real-time sync across tens of thousands of users, payment automation that had to be accurate at scale, and scheduling logic that needed to handle last-minute changes across multiple time zones without breaking.
This is a breakdown of the engineering decisions we made, the problems that nearly broke us, and what the system looks like today.
The Domain Problem First
Before we get into architecture, you need to understand why this domain is technically complex.
A single loan closing involves four separate stakeholders:
- Signing agent — the notary who physically shows up
- Signing service — the company coordinating the agent
- Title/escrow company — the legal entity managing the transaction
- Borrower — the person signing the documents
Each of these parties has different permissions, different workflows, and different expectations from the system. A signing agent needs mobile-friendly order details. A title company needs a real-time dashboard. A signing service needs bulk order management and financial reporting.
Building one platform that serves all four without turning into a tangled mess of conditional logic was the first real challenge.
Architecture Decision: Go Modular Early
The most important decision we made upfront was to build CloseWise as a modular SaaS system rather than a monolithic application.
Each functional layer is independent:
┌─────────────────────────────────────────┐
│ CloseWise Core │
├───────────┬───────────┬─────────────────┤
│ Orders │ Scheduler │ Payment Engine │
│ Module │ Engine │ │
├───────────┴───────────┴─────────────────┤
│ Reporting & Analytics │
├─────────────────────────────────────────┤
│ CRM & Communication Layer │
└─────────────────────────────────────────┘
Why does this matter? Because the business requirements kept evolving. New edge cases emerged as more signing companies onboarded. Rules around scheduling changed. Payment workflows needed updates.
With a modular architecture, we could update the payment engine without touching the scheduler. We could scale the orders module independently when volume spiked. Nothing was tightly coupled to everything else.
If we had built this as a monolith, the codebase would have collapsed under the weight of its own complexity by the time we hit 50,000 users. We were eventually going to hit 140,000+.
The Hardest Engineering Problem: Real-Time Sync
This one kept us up at night.
CloseWise users — all four stakeholder types — expect the system to behave in real time. When a signing agent confirms an order, the signing service should see that update instantly. When a title company modifies closing details, the agent's app should reflect that change before they drive to the borrower's address.
At low user counts, this is easy. You poll an API every few seconds and call it done.
At 140,000+ notaries with 6,000+ active orders running simultaneously, polling is a disaster. You're hammering your database with read requests, your response times balloon, and users start seeing stale data.
Our approach:
- Event-driven updates pushed to connected clients instead of client-initiated polling
- Optimistic UI updates on the frontend so the interface feels instant even before server confirmation
- Conflict resolution logic for cases where two users modify the same order simultaneously — last-write-wins wasn't good enough here given the financial stakes
The real-time layer is genuinely one of the more complex parts of the system. Getting it right meant the difference between a platform that felt alive and one that felt laggy and unreliable.
Scheduling Logic at Scale
The scheduling engine sounds simple. Match an available notary to an open order based on location and time.
In practice:
- Notaries work across multiple time zones
- Availability windows change constantly — agents pick up and drop slots throughout the day
- Last-minute cancellations happen frequently in the signing industry
- Some orders have hard deadlines tied to closing dates — missing them has real legal and financial consequences
We built a scheduling engine that handles:
Availability management — agents set recurring availability plus one-off exceptions. The system resolves conflicts automatically.
Geographic matching — order location is matched against agent service areas, not just a radius from their home address. An agent might cover three counties but not the one between them.
Workload balancing — distributing orders evenly across available agents rather than always assigning to the closest available person. This prevents agent burnout and improves reliability.
Deadline awareness — orders with hard closing deadlines get flagged and prioritized in the assignment queue.
The tricky part was keeping this logic fast. Querying availability, checking geographic coverage, and calculating workload balance across thousands of agents for every new order is expensive if you're not careful about how you structure the data and the queries.
Payment Automation: Where Accuracy Is Non-Negotiable
Payment automation is one of those features that sounds like a nice-to-have until you realize the alternative is manual reconciliation across thousands of monthly transactions.
But payment automation is also where bugs destroy trust fastest. A signing agent who gets paid the wrong amount once will remember it forever.
Our payment layer handles:
- Invoice generation triggered automatically on order completion
- Payment tracking against each invoice
- Agent payout calculation based on completed orders and agreed rates
- Accounting reconciliation — making sure the numbers that go into reporting match the numbers that actually moved
The trickiest part here wasn't the happy path. It was the edge cases:
- What happens when an order is partially completed?
- What happens when a signing is cancelled after the agent has already traveled?
- What happens when a client disputes an invoice?
Each of these required explicit handling in the payment logic. We spent more time on edge case coverage in the payment module than in any other part of the system.
The result: billing accuracy improved significantly for companies that moved from manual invoicing to CloseWise, and the rate of payment disputes dropped.
Security Considerations
Loan documents contain sensitive personal and financial data. Security wasn't an afterthought.
A few decisions we made:
Role-based access control — every user type (agent, signing service admin, title company) has a defined permission set. Nobody sees data they shouldn't see, even within the same organization.
Document handling — documents flow through the system with appropriate access controls at each stage. A signing agent can access the documents for their assigned order. They cannot access documents for orders assigned to other agents.
Audit logging — every significant action in the system is logged with a timestamp and user ID. This matters in an industry where legal accountability is real.
What the System Looks Like Today
After all of that:
- 140,000+ notaries on the platform
- $21B+ in loan closing transactions processed
- 6,000+ active orders managed simultaneously
- Signing agencies that previously needed 5 people to manage their operations can now run with 2
The white-label layer also turned out to be more valuable than we initially expected. Larger signing companies wanted to present CloseWise as their own platform to their clients. We built that capability in, and it became a strong differentiator in the market.
Lessons Worth Keeping
A few things we'd tell ourselves at the start of this build:
Modular from day one. The temptation to move fast with a monolith is real. Don't do it if you know the domain is complex.
Real-time is a first-class requirement, not a feature. Design your data layer for it from the beginning. Retrofitting real-time behavior onto a request/response architecture is painful.
Edge cases in payment logic will take longer than the happy path. Budget for it.
Domain complexity is underestimated in initial scoping. The notary industry has more rules, exceptions, and stakeholder nuances than it looks like from the outside. This is probably true of most vertical SaaS domains.
Full Case Study
If you want to read the full product and business breakdown, the complete blog is on our website:
👉 How Logic Square Built CloseWise to Power $21B+ in Loan Closings
Built by Logic Square Technologies — a software development company building web and mobile products for startups and enterprises.
Top comments (1)
Its Good insightful about closewise