When to Build Custom Software vs Configure SaaS

Early-stage startups and small businesses waste runway on two opposite extremes.

On one side are teams that try to build everything from scratch. They spend three months engineering custom authentication libraries, bespoke billing systems, and proprietary notification engines before onboarding a single customer. They burn through their initial capital building commodity features that could have been configured in an afternoon.

On the other side are teams that string together sixteen SaaS subscriptions with fragile webhook automations. When customer volume arrives, webhooks drop payloads silently, third-party API rate limits break workflows, and the company pays thousands of dollars monthly for disconnected tools that cannot talk to each other.

To make sustainable stack decisions, engineering teams need a clear evaluation rule: the Core versus Context boundary.

---

The Core versus Context decision framework

In his classic business technology formulation, Geoffrey Moore divided enterprise work into two buckets: Core and Context.

• Core is the specific workflow that creates your competitive advantage and defines your customer value. It directly drives your margins and sets you apart from alternatives.
• Context is necessary operational overhead. It includes payroll, password resets, basic transactional email delivery, and accounting compliance. Customers expect it to work, but no one buys your product because you built a custom password reset form.

flowchart TD
    Start["New Feature or Workflow Requirement"] --> Q1{"Is it Core to your competitive advantage?"}
    
    Q1 -- "Yes (Unique Workflow)" --> Q2{"Does an off-the-shelf tool support 80% without hacks?"}
    Q1 -- "No (Commodity Overhead)" --> Q3{"Do you have an existing tool handling this?"}
    
    Q2 -- "No (Forced Workarounds)" --> Build["BUILD: Write custom software in your core application"]
    Q2 -- "Yes (Standard Pattern)" --> Config["CONFIGURE: Use off-the-shelf SaaS or self-hosted tool"]
    
    Q3 -- "Yes (Adequate)" --> Keep["KEEP: Retain current tool, avoid migration churn"]
    Q3 -- "No / Overpriced" --> Replace["REPLACE: Switch to open-source or lightweight alternative"]

Every software decision in your business maps to one of four actions: Keep, Configure, Replace, or Build.

Call	Decision Rule	Best Example	Worst Example
Keep	Retain existing software when adoption and integrations justify the price	Slack for internal team collaboration with 20+ integrations	Keeping an unused $800/mo enterprise CRM package
Configure	Use an established third-party tool for commodity operational requirements	Stripe Checkout for payment gateway processing	Custom building an entire credit card billing gateway
Replace	Swap an overpriced SaaS subscription for a focused self-hosted or open-source tool	Replacing high-seat analytics with self-hosted PostHog	Swapping active production billing for an unmaintained repo
Build	Write custom application code when the workflow defines your unique business value	The core dispatch algorithm or custom multi-tenant ledger	Writing custom auth tokens instead of session cookies

---

When to Build: The three indicators

Writing custom software is an investment that incurs permanent maintenance responsibility. You should write custom code only when three conditions are met:

1. The workflow touches your unit economics

If software directly improves your gross margins or accelerates customer throughput, building it yourself gives you long-term operating leverage.

In Retainix, we built custom counter sync logic because waiting for slow third-party loyalty API requests at a petrol counter backed up physical vehicle lines. Owning that interaction directly protected the client’s retail transaction velocity.

2. Commercial tools require awkward workarounds

When you spend weeks hacking custom API connectors, writing duplicate webhooks, and paying for multiple middleware tiers just to force an off-the-shelf tool to support your workflow, you are already building custom software. You are simply doing it on top of a fragile, closed platform that you do not control.

3. Your differentiation is the data relationship

If your product succeeds because it connects two distinct data sources in a way competitors cannot match, that relational schema belongs in your own PostgreSQL database, not trapped inside isolated third-party SaaS silos.

---

When to Configure or Replace: Protecting engineering focus

Every line of custom code you write must be updated, patched, and monitored.

Here are the operational areas where writing custom software is almost always a mistake for early teams:

1. Payment gateway orchestration

Processing credit cards, handling failed billing retries, generating customer tax invoices, and supporting regional compliance mandates (such as European SCA or Indian e-mandates) requires dedicated compliance teams. Use Stripe, Lemon Squeezy, or Paddle. The transaction fee is vastly cheaper than the engineering salary needed to maintain custom payment pipelines.

2. Transactional email deliverability

Setting up your own SMTP server on a virtual private server almost guarantees your verification emails land in spam folders. Email deliverability depends on domain reputation, IP warmup, and feedback loops with major inbox providers. Use Postmark or Resend.

3. Basic analytics and user telemetry

Do not write custom database tables to record page views or button clicks. Your primary database should store state mutations, not high-volume clickstream logs. Use lightweight analytics like Plausible for web traffic, or PostHog for product session tracking.

---

The compounding cost of SaaS sprawl

While custom code brings maintenance debt, indiscriminate SaaS adoption brings vendor lock-in and margin erosion.

Many companies sign up for a dozen tools during their first six months. By year two:

• Software seats scale automatically, turning a $50 monthly bill into a $1,200 monthly drain.
• Customer data is fragmented across HubSpot, Zendesk, Stripe, and Airtable, with no single trusted source of truth.
• When an upstream SaaS vendor changes pricing or deprecates an API endpoint, internal operations grind to a halt.

In our Reframe audits, we routinely help businesses eliminate $500 to $2,500 in monthly recurring tool spend by replacing bloated SaaS tiers with clean open-source alternatives or consolidating scattered spreadsheets into a single focused application.

---

Finding the balance

Great engineering teams do not take pride in the total lines of code they write. They take pride in shipping reliable products that solve customer problems with the minimum necessary complexity.

Build your core workflow with precision. Configure your commodity context tools with restraint. When you protect your engineering focus for what truly differentiates your product, your runway lasts longer and your software stays resilient.

If your team is evaluating an overgrown software stack or deciding whether to build a custom internal tool, review our Reframe evaluation methodology or request a Stack Review with our studio.