Executive Summary: For engineering leaders at alternative lenders, the build-vs-buy SOS verification cost question rarely gets a complete answer. The sticker price of a vendor API is visible, but the true cost of building Secretary of State verification in-house, across 50 states plus D.C., stays hidden until the maintenance bills arrive. This analysis breaks down both sides of the ledger so a CTO can run the math with full numbers, not just the line items that are easy to see.
What Does "Build vs Buy" Actually Mean for SOS Verification?
Every alternative lender that underwrites businesses needs to confirm one thing before funding: is this entity real, active, and in good standing with the state where it registered. That confirmation lives inside 51 separate government systems, one for each state plus the District of Columbia, and no two of them work the same way.
The build-vs-buy decision is really a question about who owns the complexity of those 51 systems.
• Build means an engineering team writes and maintains the code that queries each state's Secretary of State portal, parses the results, normalizes the status fields, and keeps the whole thing running as the underlying sites change.
• Buy means a vendor owns that work and exposes it through a single API, so the lender's engineers integrate once and consume a consistent response.
The trap is treating this as a one-time engineering project. Building SOS verification is not a project with an end date; it is a permanent operational commitment. As one CTO at the lending platform 1West put it, "Integrating with all 50 states is obviously really complicated," and the harder part is "the maintenance of all of that." The first half of that quote describes the build. The second half describes the cost that never stops.
What Does It Really Cost to Build SOS Verification In-House?
A production-grade in-house build covering all 50 states plus D.C. typically starts at $80,000 to $150,000 in initial engineering labor, and the ongoing maintenance that follows usually costs several times that figure every year. Here is how that breaks down.
Start with the upfront build, because that is the number most internal estimates anchor on, and it is almost always too low.
A production-grade integration is not a weekend script. It needs error handling, logging, retry logic, monitoring, and a parser for each jurisdiction's quirks. Industry analyses of comparable data-extraction systems put a production build at roughly 8 to 12 weeks of senior developer time, with initial development alone running $80,000 to $150,000 or more.¹⁷ One cost study documented a team that received a $10,000 internal estimate and had spent $85,000 six months later, still fighting failures.² These benchmarks come from comparable government-portal and data-extraction work rather than SOS-specific studies, but the analogy holds tightly: a Secretary of State build is exactly this kind of system, dozens of unstable public websites queried and parsed on a schedule, so the same cost drivers apply.
The labor math explains why. The median annual wage for software developers in the United States was $133,080 as of May 2024, and the highest 10 percent earned more than $211,450.³ Salary is not the full cost of an engineer. Benefits, including employer-paid health insurance, retirement contributions, payroll taxes, and paid leave, account for roughly 30 percent of total compensation according to federal employer-cost data.⁴ A senior engineer who looks like a $200,000 line item is closer to $260,000 fully loaded.
Now apply that to a 50-state build:
• Discovery and architecture: mapping 51 portals, each with its own search interface, rate limits, and data format.
• Per-state parsers: writing extraction logic for systems that range from clean APIs to portals that require navigating multiple pages and solving access challenges.
• Status normalization: reconciling the fact that "Active," "Good Standing," "Current-Active," and dozens of other state-specific labels need to map to one consistent field your underwriting logic can read.
• Resilience: retry logic and graceful failure handling for states that respond slowly or go offline entirely.
A two-engineer team spending three months on the initial build represents well over $100,000 in fully loaded labor before the system processes a single production application. That is the part CTOs usually budget for. It is also the smaller half of the bill.
Why Is Maintenance the Hidden Tax on a Build?
Here is the number that breaks most in-house business cases: in the traditional data-extraction model, roughly 20 percent of engineering time goes to building and 80 percent goes to maintaining.⁵⁸ The build is the cheap part.
State portals are not static targets. They redesign their sites, change page structures, adjust rate limits, and shift authentication requirements without notice or release notes. Industry data shows 10 to 15 percent of extraction systems in some sectors require fixes every single week because of these shifts,⁹ and that after launch an engineer can spend 40 percent of their time keeping integrations alive rather than building anything new.⁶ The worst failures are the silent ones: a parser that quietly returns incomplete or wrong data without throwing an error, which for a lender means an underwriting decision made on bad information.
For a VP of Risk, that silent failure is not an engineering ticket; it is a funded deal on a dissolved entity, an audit finding waiting to surface, or an opening for stacking operators who learn that a lender's verification lags reality. When a state marks a business inactive on Tuesday and a stale parser still reports it active on Wednesday, the cost lands as a default and a compliance gap, not as a line in an engineering log. That is why the maintenance question belongs on the risk team's desk as much as the engineering team's.
This is exactly the pain that pushed Bectran, a trade credit platform, to look for an outside provider. They described their prior approach as producing "very outdated and most of the time just straight up wrong data," and noted that "reports from our customers looked very bad on us." When verification data is wrong, the cost is not just engineering time; it is reputation and credit losses.
For a CTO, the maintenance tax shows up as a permanent drag on the roadmap. Every sprint, some fraction of the team is pulled off product work to repair a state parser that broke overnight. That recurring diversion is the true recurring cost of a build, and it compounds for as long as the lender stays in business.
Running the build-vs-buy math for your own volume? Cobalt Intelligence covers all 50 states plus D.C. through one API, with status normalization and timestamped screenshots built in. Book a technical walkthrough to see the integration and pressure-test the numbers against your underwriting workflow.
What Is the Opportunity Cost of Building Non-Core Infrastructure?
The labor and maintenance lines are direct costs. The opportunity cost is larger and harder to see: every engineer maintaining state parsers is an engineer not building the product that differentiates the lender.
Altscore.ai, a lending infrastructure platform, reached this conclusion directly. Their CTO framed SOS data as something to source rather than own because "the data itself, it's not our core business." The CTO at FileJet weighed the same tradeoff, concluding that "maybe a service might be better than us throwing engineers on the verification aspect of it."
The pattern repeats across the alternative lending space:
• Practiom, after adopting a verification API, reported that the vendor "saved lots of time developing and managing my own APIs across many areas," with data quality the team described as excellent.
• EntityScanAI needed "entity status checks for US corporations and LLCs across the US states via an API" and chose to buy rather than rebuild what already existed.
For a CTO measured on shipping velocity and product differentiation, the opportunity cost question is the decisive one. A verification stack does not win deals or reduce defaults on its own; it is table stakes. Spending senior engineering capacity to rebuild table stakes, while competitors point that same capacity at risk models and customer experience, is a strategic cost that rarely appears in a build estimate.
How Do You Calculate the True Cost of Buying?
The buy side has costs too, and an honest analysis names them. A vendor API carries a per-call or subscription cost, an integration effort, and a dependency on the provider's reliability. The difference is that these costs are predictable and bounded, while build costs are open-ended.
A well-built verification API collapses the 50-state problem into a single integration:
• One integration, not 51: engineers write to one consistent interface instead of maintaining parsers for every jurisdiction. Idea Financial's team described their Cobalt integration as "one of the faster integrations" they had done.
• Normalized data out of the box: status fields arrive standardized across all states, so underwriting logic reads one consistent schema rather than a patchwork of state-specific labels. (See how this works in normalized SOS status across 50 states.)
• Audit-ready evidence: timestamped screenshots from the official state source accompany each result, which supports compliance documentation without extra engineering.
• Confidence scoring: a 0.0 to 1.0 score on each match lets teams set thresholds for automatic acceptance versus human review, instead of building that matching logic themselves.
• Reliability handled upstream: retry logic and callback patterns for slow or offline states are the vendor's problem to solve, not the lender's. (More on this in how a provider handles state portal outages.)
Cobalt Intelligence built its platform around exactly this model: real-time data pulled directly from primary state sources, integration that typically takes three to five days rather than months, and the 50-state maintenance burden carried by the vendor. Middesk offers a comparable buy-side option in the business verification category, and a thorough evaluation should compare providers on coverage, data freshness, and match evidence rather than headline price alone. On those three axes, Cobalt's position is concrete:
• Coverage: all 50 states plus D.C. through a single integration, not a subset of high-population states.
• Data freshness: pulled in real time from the primary state source on each request, not served from a cached or secondary database that can lag the state record by days or weeks.
• Match evidence: every result carries a 0.0 to 1.0 confidence score plus a timestamped screenshot from the official state record, so a match is auditable rather than asserted.
It is also worth knowing that several aggregators in this category build on top of primary-source data providers rather than maintaining 50-state coverage themselves. A buyer evaluating one of those aggregators is often a step removed from the underlying state data that Cobalt delivers directly. For a side-by-side view, see the Cobalt vs Middesk vs D&B comparison.
The buy-side cost is real, but it is a known monthly number that scales with volume. The build-side cost is an unknown number that scales with how often 51 government websites decide to change.
When Does Building SOS Verification Still Make Sense?
A credible cost analysis does not pretend buy always wins. Building in-house can be the right call in specific situations:
• Single-state or low-jurisdiction need: a lender operating in one or two states avoids most of the 50-state complexity, and a narrow build may be maintainable.
• A genuine data moat: if verification logic is itself the differentiating product, owning it end to end can be worth the cost.
• Extreme volume with unusual requirements: at very high scale with needs no vendor meets, the economics can tilt toward a custom build, though usually as a supplement to a vendor rather than a replacement.
The honest filter is this: if SOS verification is core to what the company sells, building can be justified. If it is infrastructure the company needs but does not sell, the maintenance tax and opportunity cost almost always favor buying. Most alternative lenders fall firmly in the second group.
How Should a CTO Run the Build-vs-Buy Math?
Pulling the analysis together, here is the framework for a defensible decision:
• Count fully loaded labor, not salary: apply the roughly 30 percent benefits load to every engineer in the estimate.⁴
• Budget maintenance at 4x the build: if the build is 20 percent of lifecycle effort and maintenance is 80 percent, the ongoing cost dwarfs the upfront cost.⁵
• Price the opportunity cost: estimate the product work those engineers would ship if they were not maintaining parsers, and put a revenue value on it.
• Model breakage risk: assume some percentage of states break each month and that some failures will be silent, then price the cost of a wrong underwriting decision made on bad data.
• Compare against bounded vendor cost: weigh the open-ended build total against a predictable per-call or subscription cost that scales with volume.¹⁰
When the math runs with all five factors, the build estimate that looked like a one-time six-figure project usually reveals itself as a permanent seven-figure commitment over a few years. The vendor cost, by contrast, stays a line item that grows only with the business. For the broader return picture, the ROI of automated business verification lays out the volume-based numbers.
Conclusion
The build-vs-buy SOS verification cost decision is not close for most alternative lenders once the full ledger is on the table. The visible cost of a vendor API is predictable and scales with volume. The hidden cost of an in-house build, fully loaded labor, a maintenance burden four times the size of the initial build, the opportunity cost of diverted engineers, and the credit risk of silent data failures, is open-ended and grows with the unpredictability of 51 government systems. Run over three years, a two-engineer in-house build commits roughly $400,000 or more in fully loaded labor alone, before counting the deals lost or the defaults funded while a parser sat silently broken.
For a CTO, the strategic question is simple: is rebuilding 50-state verification the best use of senior engineering capacity, or is that capacity better spent on the risk models and customer experience that actually win deals. For most teams, buying the infrastructure and building the differentiation is the answer the numbers support.
To pressure-test these numbers against your own application volume and underwriting workflow, book a technical walkthrough with Cobalt Intelligence.
.jpg){kind=small}
.png)