// resources / build vs buy
Build vs Buy: Custom Software vs Off-the-Shelf SaaS
The default assumption in most NYC firms is "buy SaaS first, build custom only when nothing else works." That's usually correct — and sometimes expensive. Here's the honest read on which side of the line a given piece of software should land on, without a thumb on the scale.
// side by side
Six dimensions that actually decide it
| Dimension | Off-the-shelf SaaS | Custom software |
|---|---|---|
| Upfront cost | Near-zero to low. Per-seat licensing, month-to-month or annual. Implementation fees typical: $5K–$50K for mid-market products. | High. A scoped internal tool is $150K–$350K; a client-facing product with compliance scope is $400K–$1.5M. Paid over the build. |
| Ongoing cost | Grows with users and features. Per-seat pricing means the bill scales with headcount whether or not the tool gets used more. | Roughly 15–25% of build cost per year for hosting, maintenance, and small-change work. Flat against headcount growth. |
| Time to launch | Days to weeks for a self-service SKU. 4–12 weeks for an enterprise implementation with SSO, provisioning, and data import. | 4–7 months for a scoped internal tool. 8–14 months for a full product with compliance surface. Not faster than this, honestly. |
| Flexibility and customization | Limited to what the vendor's config surface exposes. Custom fields, workflow tweaks, and API integrations — but not fundamental redesign. | Total. The workflow is the app. If the business changes, the code changes with it, on the firm's schedule and priorities. |
| Data ownership | Data lives in the vendor's tenant. Export is contractual — usually JSON/CSV, sometimes limited to recent history. Read the DPA. | Data lives in the firm's cloud account (AWS, Azure, GCP) under the firm's IAM. Backups, retention, and access are policy decisions. |
| Vendor lock-in risk | Real. Price hikes, feature removal, acquisition by a competitor, or product sunset are outside the firm's control. | Low. The codebase is owned. The dependency risk is on the open-source and cloud-vendor layer, which is broadly interchangeable. |
// when SaaS wins
When SaaS makes sense
The default should be SaaS. Four situations where that default is almost always right:
- The workflow is genuinely standard. Email, calendaring, HRIS, expense reports, general ledger, helpdesk, CRM contact management. Any workflow where thousands of firms do essentially the same thing has a mature SaaS solution that will out-execute a custom build on price, features, and reliability.
- Budget is tight and the need is immediate. A team of 15 that needs a working ticket queue by end of quarter cannot afford a six-month custom build. SaaS gets to "good enough" in a week, and the annual cost is often less than one month of a custom-build burn rate.
- No in-house engineering to maintain the alternative. A firm without a functioning engineering team cannot own a custom codebase — someone has to be on call when it breaks, patch the dependencies, and handle the change requests. Without that capability, custom becomes a slowly-decaying liability.
- The category is evolving faster than the firm. Data warehousing, LLM tooling, and observability all improved more in the last 24 months than most firms can keep up with. Buying commodity capability here lets the vendor absorb the pace-of-change cost.
// when custom wins
When custom software makes sense
The reverse — four situations where the build cost pays for itself, and the SaaS path leaves value on the table:
- The workflow is a competitive differentiator. If the way the firm handles claims, executes trades, prices tax engagements, or triages client intake is part of what clients pay for, encoding it in a vendor's config screen throws away the differentiation. Custom is what protects it.
- Compliance requirements exceed what SaaS vendors will sign. SEC 17a-4 WORM retention, NY DFS Part 500 controls, HIPAA business-associate scope on non-standard data flows, or an SOC 2 Type II audit where the vendor's sub-processor list is unacceptable. Many SaaS vendors won't accommodate these on standard contracts; custom keeps the surface inside the firm's own controls.
- Integration debt is already unmanageable. When three separate SaaS tools each hold 30% of the truth and no one can answer basic operational questions without stitching exports together, custom middleware (or a full replacement) is often cheaper over three years than adding a fourth vendor.
- The user count is small but the transaction value is high. Fifteen senior traders, forty partners at a firm, or eighty underwriters — high per-user leverage means small productivity wins translate into large dollar wins, and per-seat SaaS pricing stops looking cheap next to a one-time build that fits exactly.
// faq
Frequently asked questions
- What does the rough cost comparison look like on a real example?
- Take a 50-user internal workflow tool a mid-market NYC firm actually needs — say, a matter-intake and conflicts-checking system for a 200-lawyer firm. Off-the-shelf option (a legal-industry SaaS): $80–$140 per user per month, $48,000–$84,000/year, plus a $15,000–$40,000 implementation fee in year one. Five-year run-rate: $255,000–$460,000, with no residual asset. Custom build: $180,000–$320,000 upfront over 4–7 months, $30,000–$60,000/year in hosting, maintenance, and small-change work. Five-year run-rate: $330,000–$620,000, ending year five with a codebase the firm owns. The two options usually land within 20–30% of each other over five years — the interesting variable is fit, not headline cost.
- How do we know which one we actually need?
- Three questions in order. First: does an existing SaaS product cover 80%+ of the workflow without contorting how the team works? If yes, buy. Second: is the workflow a competitive differentiator — something clients or regulators specifically care about, or something the firm has genuine IP in? If yes, build. Third, only if the first two are ambiguous: what is the switching cost in year three? A SaaS you cannot leave without a 12-month data migration project is a hidden cost; a custom build with no maintenance team is also a hidden cost. Whichever failure mode is cheaper to survive is the safer bet.
- Is a hybrid approach viable — SaaS for parts, custom for others?
- Yes, and it's usually the correct answer for firms above $50M revenue. Common pattern: SaaS for commoditized surfaces (CRM, HRIS, general ledger, ticketing, document management), custom software for the differentiated middle layer that ties them together and encodes the firm's specific workflow. The custom layer typically calls SaaS APIs rather than replacing them. This gives the SaaS cost profile on 70% of the surface area and the ownership profile on the 30% that matters. Integration and API contracts become the risk to manage, not build-vs-buy on each individual tool.
- What's the typical timeline for a custom build?
- For a scoped internal tool with 3–8 core workflows, plan on 4–7 months to a production-usable v1. That breaks into roughly 2–4 weeks of discovery and design, 12–20 weeks of iterative build with the client seeing working software every two weeks, and 2–4 weeks of production hardening — auth, observability, backup, security review. A full client-facing product with regulatory scope (financial services, healthcare) runs 8–14 months. Anyone quoting 8 weeks for a real custom build is either doing a prototype or under-scoping the compliance work.
- Can we start on SaaS and migrate to custom later?
- Sometimes. It works cleanly when the SaaS is a genuine standard product used for standard workflows and the eventual custom build replaces it on the firm's own schedule — data export is documented, business logic is not deeply entangled with the vendor's proprietary features, and the team's habits transfer to any tool. It fails when the firm has bent its workflow around vendor-specific quirks, built extensive integrations against the vendor's custom fields, or accumulated years of historical data in a format that doesn't cleanly export. The migration path should be evaluated on day one of the SaaS purchase, not year three.
// let's build something
Start your project request
Tell us what you're building — engineering capacity, AI, QA, cloud, or a fixed-scope software engagement. Our NYC team responds within one business day.
// what to expect
- Response within 1 business day
- 30-minute discovery conversation
- Recommended engagement model & pricing
- NYC-focused — in-person available
Start Project Request
Inbound sales only. All form information is encrypted in transit.