Custom web software vs SaaS — when to build
Buy a SaaS product when a focused vendor solves 80 percent or more of your specific problem; build custom when the workflow is unique to your business and no vendor product fits without substantial customization. The math favors buying for most generic problems (CRM, accounting, project management, email marketing) and building for genuinely differentiated workflows that create competitive advantage. The honest test is whether your business is the buyer or the seller of the workflow in question.
The longer answer
The custom-vs-SaaS decision is the most consequential early choice in many software engagements, and the right answer depends almost entirely on whether the workflow in question is differentiated for your business or generic.
When SaaS is the right answer
Generic business workflows where the SaaS market has mature, well-priced options. CRM (Salesforce, HubSpot, Pipedrive); accounting (QuickBooks, Xero, NetSuite); project management (Asana, Linear, Jira); email marketing (Mailchimp, Customer.io, Klaviyo); customer support (Zendesk, Intercom, Help Scout); HR (BambooHR, Gusto, Rippling). The vendor has spent thousands of engineer-years on these workflows; you will not out-engineer them with a custom build. The math overwhelmingly favors buying.
Two honest tests for SaaS fit. First, does the vendor product solve your problem at 80% or higher without customization that turns the engagement into a custom-build masquerading as a configuration? Second, are you willing to adapt your workflow to the vendor's product, or are you trying to force-fit the vendor product to a workflow that is genuinely yours?
When custom is the right answer
Three scenarios. Genuinely unique workflow. The way your business does the thing is the competitive advantage; the SaaS market does not have a product because the workflow is your specific competitive moat. Build custom. Integration depth no vendor will accommodate. Your business needs the workflow tool to integrate deeply with five proprietary systems that no SaaS vendor will support. Build custom. Scale or compliance vendors cannot match. Your scale is beyond what SaaS vendors price for, or your compliance posture (HIPAA, FedRAMP, data residency) is stricter than vendors will commit to. Build custom.
The honest test
Ask: in this workflow, is my business the buyer or the seller of the workflow? If you are the buyer (you consume the workflow output, the workflow itself is operational overhead), buy SaaS. If you are the seller (you sell a service or product whose differentiation comes from this workflow), build custom. Most businesses have 20-30 workflows where they are the buyer and 1-5 where they are the seller; custom is the right answer only for the seller workflows.
The middle ground: SaaS plus custom integration
The pattern most production software actually lands on. Use SaaS products for the generic workflows; build a thin custom integration layer that orchestrates between them and surfaces the right data to the right roles. The integration layer is custom; the underlying tools are SaaS. This pattern captures 80% of the benefit of pure-custom at 20% of the cost.
Common follow-up questions
How do I know if a workflow is generic or unique?
Generic: 5+ established vendor products serve the workflow, and changing vendors is a normal business decision. Unique: no established vendor product fits without substantial customization, and you would prefer to change processes rather than adopt the closest-fit vendor. The test usually resolves clearly when asked honestly.
Can I start with SaaS and migrate to custom later?
Often the right pattern. SaaS de-risks the validation phase; if the workflow turns out to be a competitive differentiator at scale, build custom in year 2 or 3 when the data and process clarity are higher. Most "custom" builds that start in year 1 ship features the buyer regrets by year 2.
What about no-code platforms?
For prototypes and internal tools with bounded scope, useful. For production customer-facing systems, the no-code platforms become custom-build masquerading as configuration once the workflow has any real complexity. The honest assessment is whether no-code is a permanent solution or a stepping stone to a real custom build.
If this answer is useful and you have a real engagement in mind, the contact form routes directly to the principal — James Henderson is the single engineer who scopes, writes, and supports every engagement end-to-end.