What Software a Wealth Advisory Firm Should Actually Build

For: Owner or COO of an independent RIA or boutique wealth advisory firm with $500M–$2B AUM, running on a patchwork of Salesforce, Orion or Tamarac, and Excel, who is losing advisor time to manual reporting and losing prospects to firms with slicker client-facing portals

If you run an RIA between $500M and $2B AUM, the highest-ROI first build is almost never the client portal or the reporting dashboard your partners keep asking about. It is an automated household aggregation layer that reconciles your Orion or Tamarac position data with held-away assets pulled via Plaid and whatever manual custodian feeds you still babysit. Every downstream artifact — the quarterly report, the proposal, the billing invoice, the Form ADV workpaper — inherits its errors from that one broken data layer. Fix it first, and every other build gets cheaper and faster. Skip it, and you are automating garbage.

This post walks through the three operational problems that cost a firm your size real money, what to build for each, and the order to build them in. It assumes you already own Salesforce (or a Salesforce-based vertical like XLR8 or Practifi), a portfolio management system (Orion, Tamarac, Black Diamond, Addepar), and are watching advisors export to Excel for anything the vendors did not anticipate.

The three problems that actually cost you money

Before deciding what custom software for wealth management firms is worth commissioning, be honest about which problems are burning cash today. In practice, three show up at almost every firm in this AUM band.

1. Data reconciliation is manual and everything downstream is wrong

Roughly 40–45% of family offices still aggregate data by hand across PDFs, custodian portals, and fund administrators, and RIAs are not far behind. Schwab, Fidelity, and Pershing deliver data in different formats on different schedules — some API, some flat file, some overnight, some T+1. Held-away assets can be up to 40% of a client's total portfolio and none of them show up in Orion unless someone puts them there.

The result: your ops team spends the first two weeks of every quarter chasing reconciliation exceptions. Advisors spend an average of 8.4 hours per week on manual reporting — two client meetings a week lost to spreadsheet work. And one typo in an account number between the CRM and the PMS corrupts performance, billing, and compliance simultaneously.

2. Custodian billing reconciliation eats a week per quarter

Every quarter, someone in ops opens a spreadsheet and matches custodian fee debits against what Orion or Tamarac billed. The billing platforms auto-match 80–88% of accounts, leaving 12–20% for manual review because of account identifier mismatches, mid-quarter fee schedule changes, and account transfers. That is 10–14 hours per custodian per quarter of senior ops time reconciling numbers, not building anything.

3. Prospects compare your client experience to Betterment's

Your prospects, especially inherited wealth in their 30s and 40s, have logged into a Wealthfront account. They expect a portal that shows consolidated household net worth including their 401(k), their spouse's IRA at Vanguard, the vested RSUs at Schwab, and the mortgage. Your current portal shows what you custody. That gap is why you lose deals to firms you consider technically inferior.

What to build, in order

Build 1: The household data aggregation and reconciliation layer

This is not glamorous. Nobody demos it at a partner meeting. It is also the only build that makes every subsequent build cheaper.

What it is: A service that pulls position and transaction data from your PMS (Orion, Tamarac, Black Diamond), from Plaid's Investments API for held-away accounts, and from direct custodian feeds where Plaid coverage is thin (some smaller trust companies, alternative custodians, private fund administrators). It normalizes to a single household-level schema, runs reconciliation rules, and flags exceptions to a queue your ops team works through — instead of hunting for them.

What changes once it exists:

• Quarterly reporting starts with clean data, not a two-week reconciliation sprint
• Held-away assets are visible in every proposal and review, which is the actual differentiator against the robo-advisors
• Compliance workpapers pull from one source instead of three
• Every future build — portal, proposal tool, planning integration — reads from this layer instead of re-solving the same problem

What it takes: The main drivers are how many custodians you touch, whether your PMS exposes a usable API (Orion and Black Diamond do; some Tamarac deployments require workarounds), how many held-away account types you need to support beyond Plaid's default coverage, and the state of your existing account and household identifiers in Salesforce. A firm with three custodians, Orion, and reasonably clean CRM data is a very different project from a firm with seven custodians, two PMS instances from an acquisition, and duplicated households.

Illustrative example (not a quote): A firm with Orion, three custodians (Schwab, Fidelity, Pershing), Plaid for held-away, and roughly 1,200 households with reasonably clean identifiers would be a bounded first build — one integration each for the PMS and the three custodian feeds, a Plaid integration, a reconciliation rules engine, and an exceptions UI for ops. The variables that would turn this into a real scope: how many custom account types your ops team currently tracks in spreadsheets, whether you need historical backfill or just go-forward, and how much of the exception logic already lives in someone's head versus a documented process.

Build 2: Automated custodian billing reconciliation

Once the data layer exists, this is a small extension, not a separate project. You already have clean position data, custodian fee debits, and household-level fee schedules. The reconciliation engine just needs the last mile: match debits to billed fees, flag mismatches above a threshold, route exceptions.

What changes: The 10–14 hours per custodian per quarter drops to under two, and you catch fee leakage you were previously eating. Firms in this AUM band routinely find $40K–$150K a year in either under-billed accounts or over-debited custodian fees that reconciliation exposes.

What it takes: Mostly a function of how many fee schedule variations you have. If every household is on a straightforward tiered schedule, this is a small build. If you have grandfathered legacy schedules, householded discounts, and one-off arrangements the founding partners made in 2008, the rules engine gets more complex — and that complexity lives in institutional knowledge, not documentation, which is the actual project cost.

Build 3: The client portal — but only now

Now build the client portal for financial advisors your prospects keep comparing you to. Because it reads from the household aggregation layer, it can show what Wealthfront cannot: the full household picture, the held-away accounts, the planning overlay, the advisor's actual view of the client.

What it is: A web and mobile portal with consolidated household net worth, performance, document vault, secure messaging, and — the piece most vendor portals do badly — a client-facing view of the financial plan that stays in sync with whatever planning tool your advisors use (eMoney, RightCapital, MoneyGuidePro).

What changes: Prospects stop asking why your portal looks like it was built in 2014. Advisors get the 22–31% increase in client-facing hours that comes with automated report delivery and follow-up. And you own the client experience instead of renting it from a vendor whose roadmap does not care about your firm.

Honest tradeoff: This is the most expensive build of the three and the one with the least operational ROI. The reason to do it is competitive positioning and client retention, not efficiency. If your prospect-to-close ratio is fine and your retention is 97%+, skip this and put the money into planning or tax integrations instead.

What NOT to build (yet)

A few things get pitched constantly at this AUM band that are almost never worth a custom build in the first eighteen months:

• A custom CRM. Salesforce with a wealth vertical (XLR8, Practifi, Salentica) is fine. The custom RIA CRM projects that succeed are almost always at $5B+ where the workflow economics change. Below that, you are rebuilding what Salesforce already does.
• A custom performance calculation engine. Orion, Black Diamond, and Addepar do this well enough. The problem is not the calc — it is the data feeding the calc.
• An AI meeting-notes tool. Jump, Zocks, and Zeplyn already exist and integrate with Salesforce. Buy, do not build.
• A proposal generator. Wait until the data layer exists. Then it is a two-week build on top, not a six-month project.

The RIA technology stack build vs buy test

The question is never "build or buy" in the abstract. It is: does the vendor force you to change your investment process, householding logic, or fee structure to fit their software? For performance calculation, the answer is usually no — Orion is flexible enough. For reporting and client experience, the answer at your AUM is usually yes, and that is where custom pays off.

A useful test: for any capability you are considering building, ask whether three years from now you would rather own the code or keep paying the vendor. If you would rather own it, and the vendor's roadmap does not match yours, build. If you would happily pay the vendor forever and their roadmap is fine, do not build.

Firms that get this wrong build custom versions of commodity capabilities (CRM, performance calc) and buy vendor solutions for their actual differentiators (client experience, planning integration). Then they wonder why they look like every other RIA.

How CodeNicely can help

We build the aggregation and reconciliation layer, the custodian billing engine, and the client-facing portal as separate, sequenced projects — with full IP transfer, no vendor lock-in, and integration into whatever CRM and PMS you already run.

The engagement most relevant to this work is GimBooks, a YC-backed fintech accounting platform where the core problem was the same shape as yours: multiple upstream data sources with inconsistent schemas, reconciliation logic that had to survive edge cases nobody documented, and a user base that would abandon the product the first time the numbers looked wrong. The reconciliation-first architecture we built there is directly transferable to RIA household aggregation. For the client-facing portal work, Cashpo is a closer parallel — a consumer-facing financial product where the UI had to earn trust in the first thirty seconds or the user closed the tab.

If you want to talk through which of the three builds makes sense to start with, or whether your current stack is closer to build-ready than you think, get in touch. The two or three specifics that would turn any of this into a real scope: how many custodians and PMS instances you touch today, the state of your household identifiers in Salesforce, and whether you have already committed to a client portal vendor.

How to sequence it

The order matters more than the individual scoping decisions:

1. Data aggregation and reconciliation layer first. Everything else inherits its correctness from this.
2. Billing reconciliation second. Small extension of the first build, immediate operational ROI, funds part of the next stage.
3. Client portal third. Only after the data underneath it is trustworthy. A slick portal on bad data is worse than an ugly portal on good data.
4. Everything else fourth. Proposal tools, planning integrations, prospect nurture automation, advisor productivity dashboards. All of these are two-to-four-week builds on top of the data layer, versus multi-quarter projects if you try to do them first.

RIA technology spending averages 3.8% of firm revenue. At $1B AUM and typical fee structure, that is real money — enough to fund one meaningful custom build a year without cutting into partner comp. The firms that pull ahead over the next five years will spend that budget on the data layer and the client experience, and keep buying the commodity pieces. The firms that fall behind will do the opposite.

Frequently Asked Questions

Should we replace Orion or Tamarac with a custom system?

Almost certainly not. Orion and Tamarac do performance calculation, billing, and standard reporting well, and rebuilding that from scratch is a multi-year project with no differentiation payoff. Build around them: the aggregation layer that feeds them cleaner data, the reconciliation logic that catches what they miss, and the client-facing experience that sits on top.

Can Plaid alone solve our held-away asset problem?

For most household accounts at major US institutions, Plaid's Investments API covers what you need. Where it falls short: certain trust companies, alternative custodians, private fund administrators, and international accounts. A production aggregation layer uses Plaid for the 80% it handles well and falls back to direct feeds or structured manual entry for the rest. Do not architect around Plaid being the only source.

How much should an RIA our size budget for custom software?

The 3.8% of revenue benchmark is a reasonable ceiling for total technology spend including vendors. What you allocate to custom builds within that depends on how differentiated you want your client experience to be and how much manual work your ops team is doing today. The variables that turn this into a real number: which of the three builds you start with, whether you have existing internal engineering, and what your integration surface actually looks like. That is a scoping conversation, not a rate card question.

How long before we see ROI on the data aggregation layer?

The operational ROI — hours returned to advisors and ops — starts landing the quarter after the reconciliation engine goes live, because it eliminates the two-week manual reconciliation sprint. The strategic ROI — better proposals, more held-away assets captured, higher close rates — takes two to four quarters because it depends on advisors changing how they run reviews. Firms that instrument both from day one see the operational number first and use it to justify the client portal build.

Do we need in-house engineers to maintain what we build?

Eventually, yes, but not on day one. A well-built aggregation layer needs maybe 0.25–0.5 FTE of ongoing engineering attention once it is stable — mostly for custodian feed format changes and new integration requests. Most RIAs at this AUM band start with a build partner who handles the initial build and first year of maintenance, then hire one senior engineer in year two as the surface area grows. Building an internal team before you have anything for them to own is the more common mistake.