Most of my projects are for myself. I decide the features, I set the timeline, I choose the stack. Then I built Regal Title and eXp Richmond — software for clients who don't know what a database is, don't care about my stack choices, and evaluate the product entirely by whether their phone rings more often after launch.
These two projects taught me more about software development than any SaaS build. Here's what changes when the end user has never opened a terminal.
Requirements Gathering Is Completely Different
When I build for myself, requirements look like: "multi-tenant data isolation with row-level security." When a title company describes what they need, it sounds like: "We get a call from a realtor, then we pull title, then the attorney reviews it, then we send the commitment, then there's a closing, then we record the deed."
That's a workflow, not a feature list. My job is to translate it into software architecture. The title company doesn't know they need a state machine for order status. They don't know they need role-based access control so attorneys see different views than processors. They don't know they need webhooks for status notifications. They know the workflow, and they expect the software to match it exactly.
The discovery process for Regal Title took three separate calls before I had enough information to write the first line of code. Each call surfaced assumptions that the client didn't think to mention because they were obvious to anyone in the title industry. The fact that a title search can come back "clear" or with "exceptions" and exceptions have sub-types that determine the next step — that's fundamental to the product, and it didn't come up until the third conversation.
The Intake Guardrails Problem
Regal Title handles sensitive financial data. Every form that collects personal information needs guardrails that don't exist in typical SaaS:
- Fraud warnings. Wire fraud is rampant in real estate. Every page that displays bank account information or wire instructions includes a fraud advisory. Not a tooltip — a prominent, unmissable warning that tells users to verify wire instructions by phone before sending money.
- Disclosure language. Title companies are regulated at the state level. Virginia has specific disclosure requirements for title insurance, settlement services, and attorney involvement. Every form that touches these areas needs the appropriate legal language, reviewed by the company's attorney, displayed in a way that meets regulatory requirements.
- Attorney routing. Title work in Virginia involves attorneys. Certain actions — reviewing exceptions, issuing commitments, approving clearance — can only be performed by licensed attorneys. The application enforces this through role-based routing. A processor can prepare a file but cannot approve it. An attorney can approve but might not need to prepare.
In a SaaS project, I would never spend a week on disclosure language. In client work for a regulated industry, it's not optional — it's the core of the product.
Regal Title vs. Old Dominion Law Firm
One of the trickiest architectural decisions was separating Regal Title (the title company) from Old Dominion Law Firm (the affiliated legal practice). They share an office, share staff, and work on the same transactions — but legally they are separate entities with separate responsibilities.
The title company handles search, insurance, and settlement services. The law firm handles legal review, opinion letters, and attorney supervision. A single transaction might touch both entities. The software needs to track which entity performed which action, generate separate invoices, maintain separate audit trails, and present the correct branding depending on which service the user is interacting with.
Getting this wrong has legal consequences. If the title company appears to be providing legal services, or if the law firm appears to be selling insurance, there are regulatory problems. The UI needed clear visual separation between the two entities even though they share a platform.
The Design Challenge
Regal Title wanted a premium look. Not a Silicon Valley SaaS look — a Virginia law firm look. That means:
- Gold accents on dark navy. Traditional, authoritative, trustworthy. Not a single gradient in sight. No playful illustrations. No emoji. The design language says "we handle million-dollar transactions" — because they do.
- Conservative typography. Serif fonts for headings, clean sans-serif for body. Nothing experimental. The target audience is realtors and homebuyers in their 30s-60s who associate modern design with frivolity.
- No SaaS tropes. No floating dashboard mockups. No "trusted by 10,000 companies" social proof bars. No chatbot bubble in the corner. The site looks like a law firm website because that's what it is.
eXp Richmond had a different challenge. It's a real estate recruitment site — it needs to be professional but energetic. The eXp Realty brand is modern and tech-forward compared to traditional brokerages. The design needed to communicate "innovative" without looking like a startup that might not exist next year.
Delivery Speed Changes Everything
Here's something I didn't expect: shipping fast fundamentally changes the client relationship. Regal Title expected a 3-month timeline based on their experience with previous developers. I delivered the first working version in 3 weeks.
That speed shift does several things:
- Trust compounds faster. Instead of months of wireframes and status updates before seeing anything real, the client sees working software in weeks. They believe you can deliver because you already delivered.
- Feedback quality improves. Clients give better feedback on working software than on mockups. "This button should say 'Request Title Search' instead of 'Submit'" is the kind of feedback that only emerges when they're clicking a real button.
- Scope discussions get easier. When adding a feature takes days instead of weeks, clients are more willing to prioritize. They stop trying to cram everything into v1 because they believe v2 will actually happen.
The CRM Integration Question
Both clients asked about CRM integration. Regal Title uses a legacy system for tracking title orders. eXp Richmond agents use a mix of Follow Up Boss, KVCore, and spreadsheets. Neither wanted to change their existing CRM — they wanted the new software to work with what they already had.
This is a common pattern in client work. You are never building a greenfield system. You are always plugging into an existing ecosystem of tools, workflows, and habits. The technical challenge is rarely the integration itself — it's figuring out which data flows in which direction and what happens when systems disagree.
Why Vercel for Non-Technical Clients
Both projects deploy on Vercel. For non-technical clients, this is the only correct choice. Here's why:
- Zero maintenance burden. The client never needs to SSH into a server, restart a process, update a certificate, or debug a deployment. Vercel handles all infrastructure. If the client calls at 2am because the site is down, I check Vercel's status page — I don't troubleshoot a VPS.
- Instant previews. Every PR generates a preview URL. When the client asks for a change, I can send them a preview link showing the change before it goes live. No staging environments to maintain. No "can you check staging and let me know" — just a link.
- Automatic HTTPS. Non-technical clients don't know what an SSL certificate is, but they need one. Vercel provisions it automatically. One less thing to explain, one less thing to break.
Scope Creep and Boundaries
Real talk: scope creep in client work is inevitable. The question is not how to prevent it — it's how to manage it without damaging the relationship or the timeline.
My approach: everything beyond the original scope gets documented in a shared list with rough effort estimates. The client can see the list growing. At natural checkpoints (end of sprint, major milestone), we review the list together and prioritize. Some items make it into the current phase. Most get deferred to the next phase. The key is making it visible — when the client can see that their "small request" is item 14 on a list of 20, they self-moderate.
The one boundary that's non-negotiable: I don't do unlimited revisions on design. Three rounds of design feedback per page, clearly defined before work starts. After that, additional revisions are billed separately. Without this boundary, a homepage can take longer than the entire backend.
What I'd Tell Other Developers
If you've only built for yourself or for technical users, client work will feel alien at first. The skills transfer — architecture, clean code, testing — but the communication layer is entirely different. You are not shipping software. You are solving a business problem that happens to require software. The faster you internalize that distinction, the better your client work will be.
Both Regal Title and eXp Richmond are live and serving real users. If you want to see the results, check the portfolio.