Beyond General Lock-In
Our guide on software ownership and vendor lock-in already covers the general mechanics of lock-in — cloud infrastructure, SaaS tooling, no-code platforms — and how to think about switching costs generally. Our guide on production-grade software and technical debt covers what technical debt is and what it costs broadly. Neither answers the specific, recurring question every product actually faces: for a given capability — authentication, payments, search, email, analytics — should you build it yourself or integrate someone else's? This guide answers that question directly, category by category, with real cost data and a framework for the decision itself.
Should a startup build its own authentication, payments, and search infrastructure?
Almost never, for at least three of the five categories this guide covers. Authentication and payments in particular are commodity infrastructure with serious security and compliance stakes that specialized vendors have already solved at a level a small team is unlikely to match. The real decision isn't whether to use a third party for these — it's which one, and how to avoid becoming dangerously dependent on it.
The Core-vs-Context Framework
What is a real framework for deciding whether to build or buy a product capability?
Business strategist Geoffrey A. Moore's Core-vs-Context framework, from his books “Living on the Fault Line” and “Dealing with Darwin,” distinguishes Core activities — the ones that create sustainable competitive advantage and are hard for competitors to replicate — from Context activities, which are necessary but don't differentiate your product. Moore's own prescription for Context work is direct: it should be “centralized, standardized, modularized, optimized, instrumented…and outsourced.”
Moore's framework, developed across his books Living on the Fault Line and Dealing with Darwin: How Great Companies Innovate at Every Phase of Their Evolution (Portfolio, 2005), gives a genuinely useful test to apply to any specific engineering decision: does building this capability yourself create something a competitor can't easily replicate, or does it simply replicate something every other product in your category also needs, the same way? Authentication is the clearest possible example of Context — your users don't choose your product because your login flow is uniquely well-engineered, and a security failure in a home-grown auth system is a pure downside risk with no corresponding upside. Your actual product logic — the specific workflow, algorithm, or user experience that makes your product worth using over the alternatives — is almost always Core, and building that yourself is exactly where your engineering time should go.
The practical value of this framework is that it reframes a build-vs-buy decision away from “can we build this” (usually yes, for almost anything, given enough time) toward “does building this create any competitive advantage at all” — a much sharper and more honest question. For most of the categories this guide covers, the honest answer is no, and the engineering time spent building a commodity capability from scratch is time not spent on the Core work that actually determines whether your product succeeds.
Authentication: Build or Buy?
What are the real risks of building your own authentication system?
OWASP's own Top 10 project identifies “Identification and Authentication Failures” as a major category of web application risk, specifically citing weak or plaintext password storage, missing protection against credential stuffing, and missing or ineffective multi-factor authentication as common, serious failures — exactly the mistakes a team building auth for the first time is most likely to make.
OWASP's Top 10:2021 project states plainly: “Confirmation of the user's identity, authentication, and session management is critical to protect against authentication-related attacks,” and specifically lists risks including systems that “permit automated attacks such as credential stuffing” and that “use plain text, encrypted, or weakly hashed passwords” ( OWASP, “A07:2021 – Identification and Authentication Failures”). This is precisely the category of mistake a specialized authentication provider has already solved, tested, and hardened across a huge volume of real-world usage — while a team building its own auth system for the first time is solving the same problem from scratch, under time pressure, without the benefit of that accumulated hardening.
On real cost: Clerk's own published pricing, confirmed directly at clerk.com/pricing, offers a free tier covering 50,000 monthly active users, with a Pro tier at $25/month (or $20/month billed annually) also including 50,000 monthly active users before usage-based pricing applies. For almost any product below meaningful scale, this means authentication is available essentially free or at negligible cost — a cost structure that makes the “build vs. buy” question, for most early-stage products, closer to “pay a small amount for hardened, tested security, or spend real engineering time building something less secure for free.” That framing alone should settle the decision for the overwhelming majority of products, since the cost of a security failure in home-grown auth — a credential-stuffing breach, a password-storage mistake — is precisely the kind of catastrophic, low-probability-but-high-severity risk that's worth paying to avoid entirely rather than accepting.
Session management and the parts of auth people forget about
The build-vs-buy conversation around authentication tends to focus on the login screen itself — password fields, a sign-up form — which understates how much of the real complexity lives in what happens after login. Session management (keeping a user securely logged in across requests, handling token expiration and refresh correctly), password reset flows (which have their own well-documented security failure modes, like reset tokens that don't expire or that leak a user's existence to an attacker), and multi-factor authentication (which OWASP explicitly flags as commonly missing or ineffective when implemented ad hoc) are all part of what “authentication” actually means in production, not just the initial sign-up screen a founder might sketch out in an afternoon. A specialized provider has solved each of these secondary problems as thoroughly as the primary one, which is precisely the accumulated hardening a first-time build can't replicate quickly — and precisely why the real cost comparison isn't “how long does it take to build a login form” but “how long does it take to build and maintain everything a login form implies.”
Social login and identity providers add a second layer of complexity
Many products also want to offer “sign in with Google” or similar social login options, which introduces an entirely separate integration surface — OAuth flows with each identity provider, each with its own quirks, rate limits, and periodic breaking changes to its own API. A dedicated authentication provider typically maintains these integrations as a standard, always-updated feature, absorbing the maintenance burden of keeping pace with every identity provider's own changes. Building this yourself means your team, not a specialized vendor, is responsible for noticing and reacting when Google, Microsoft, or another identity provider changes its own OAuth implementation — a maintenance burden that compounds with every additional social login option a product supports, for a feature that, again, creates no competitive differentiation whatsoever.
Payments: Why Building Your Own Is Rarely Right
Why shouldn't a startup build its own payment processing?
Any business that stores, processes, or transmits cardholder data falls under PCI-DSS, the payment card industry's own security standard, which imposes real, ongoing compliance obligations. Using a processor like Stripe that handles cardholder data directly removes almost all of that compliance burden from your own infrastructure, since the sensitive data never touches your own servers in the first place.
The PCI Security Standards Council's own published scope is direct about who this applies to: PCI-DSS covers “entities that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD),” including “merchants, processors, acquirers, issuers, and service providers,” and establishes “a baseline of technical and operational requirements designed to protect payment account data” ( PCI Security Standards Council, PCI DSS). Building a payment system that directly handles raw card numbers means your own infrastructure falls squarely within this scope, with the real, ongoing compliance and audit burden that requires. Using a processor like Stripe, whose hosted checkout or client-side tokenization keeps raw card data off your own servers entirely, dramatically narrows how much of PCI-DSS actually applies to you — often down to a simplified self-assessment questionnaire rather than a full compliance program.
Stripe's own published pricing structure charges a percentage plus a fixed fee per successful transaction (a structure consistently reported at roughly 2.9% plus 30 cents for a standard US online card transaction, though exact current rates should always be confirmed directly against Stripe's own pricing page since processors periodically adjust rates). That per-transaction cost is the price of not having to build, secure, and maintain PCI-DSS-scoped infrastructure yourself — and for virtually every startup, that trade is a clear win. There is no credible scenario in which a pre-product-market-fit startup should be building its own payment rails from scratch; this is the single clearest “always buy” category covered in this guide.
Subscription billing is its own layer of complexity beyond raw processing
Beyond the core PCI-DSS argument, payments carries a second, often underestimated layer of complexity for any product selling a recurring subscription rather than a single transaction: proration when a customer upgrades or downgrades mid-cycle, handling failed recurring charges and retry logic, managing tax calculation across jurisdictions, and reconciling what a customer was actually charged against what your own records say they owe. Each of these is a genuinely hard problem with real edge cases that a mature billing platform has already encountered and solved across thousands of customers — a founder building subscription logic from scratch on top of raw payment processing is effectively signing up to rediscover each of these edge cases independently, usually the hard way, when a real customer hits one in production. This is a second, independent reason payments belongs firmly on the buy side of the decision even beyond the compliance argument: the domain complexity of subscription billing itself is a second Context capability stacked on top of the first.
Search: The Real Cost Comparison
When does it make sense to build custom search infrastructure instead of using a search API?
Rarely, below meaningful scale. Algolia's own published pricing offers a free tier covering 10,000 search requests and 50,000 records per month, with paid tiers starting around $0.50 per 1,000 additional requests — a cost structure that's negligible for most products, while building and operating a comparable self-hosted search infrastructure (indexing, relevance tuning, scaling, uptime) requires real, ongoing engineering time few early-stage teams can justify diverting toward a non-differentiating capability.
Algolia's own pricing page, confirmed directly, shows a free plan covering 10,000 search requests and 50,000 records monthly, a pay-as-you-go Grow plan at $0.50 per 1,000 additional requests above its included allotment, and an Elevate tier (annual contract, custom pricing) that includes a published 99.99% availability commitment (Algolia, Pricing). Search is a genuinely useful case for testing the Core-vs-Context framework directly: unless your product's actual competitive advantage is a uniquely engineered search or relevance algorithm — which is true for a narrow set of products, like a specialized research or discovery tool, but not for the average SaaS product that simply needs users to find their own records — search infrastructure is Context, not Core, and belongs on the buy side of the decision.
Email and Notifications
Why do dedicated email services outperform self-hosted mail servers for deliverability?
Dedicated transactional email providers maintain IP reputation, sender warm-up processes, and direct feedback-loop relationships with major mailbox providers (Gmail, Outlook, Yahoo) that a small self-hosted mail server has no realistic way to replicate. This guide could not verify a specific, exact deliverability percentage difference from a fully primary-sourced study, but the underlying infrastructure and reputation advantage is well-established and not seriously disputed in the industry.
It's worth being transparent here about the limits of what this guide could verify to the standard it holds itself to. Validity, a well-established, named email-deliverability data company (formerly Return Path), publishes an annual Email Deliverability Benchmark Report, and its 2025 edition confirms that global inbox placement rates declined in 2024 — but the specific percentage figures are gated inside the downloadable report rather than visible on the public page, and this guide could not extract and independently confirm an exact number to cite (Validity, 2025 Email Deliverability Benchmark Report). Rather than citing an unverified specific percentage that circulates in secondary content without a confirmed source, this guide states the underlying mechanism plainly instead: major mailbox providers increasingly use sender reputation — a history built over time, tied to consistent sending practices and infrastructure — as a primary signal for whether to deliver a message to an inbox or a spam folder, and a new, small, self-hosted mail server starts with none of that accumulated reputation, while an established provider like SendGrid, Postmark, or Resend brings shared infrastructure reputation a new sender benefits from immediately.
The practical cost comparison here is less about the service's own pricing (most transactional email providers offer usable free or low-cost tiers for early-stage volume) and more about the hidden cost of getting it wrong: a self-hosted mail server with poor deliverability doesn't fail loudly — it fails silently, with password-reset emails, receipts, and critical account notifications quietly landing in spam folders or never arriving at all, undermining product trust in a way that's hard to detect until a customer complains. That asymmetry — a small, easily avoidable ongoing cost versus a silent, hard-to-detect failure mode — is exactly the kind of trade-off the Core-vs-Context framework is built to resolve in favor of buying.
Analytics: A Different Kind of Trade-Off
Is analytics a build-or-buy decision like authentication and payments?
Less clearly so. PostHog's own published pricing offers a free tier covering 1,000,000 events per month, which the company states covers 97% of companies using the platform — making buying the practical default for most products. But unlike auth or payments, custom event tracking is a much lower-risk, lower-compliance-burden capability to build partially in-house, making analytics a genuinely closer call than the other categories in this guide.
PostHog's own pricing page confirms a free tier of 1,000,000 events per month, which PostHog states “covers 97% of companies” using the platform, with pay-as-you-go, per-product billing beyond that threshold (PostHog, Pricing). Analytics differs from authentication, payments, and search in one important respect: the downside of getting it slightly wrong is far lower. A minor gap in your own custom event-tracking pipeline produces incomplete data, which is a real cost but not the catastrophic, security-grade failure mode that a home-grown authentication or payment system risks. This makes analytics a legitimate candidate for a hybrid approach — using a vendor for the dashboarding, querying, and visualization layer most products genuinely don't need to build themselves, while still owning the actual event instrumentation and data model, since that data model is often closely tied to what your specific product needs to measure to improve — arguably closer to Core than the pure infrastructure categories covered above.
| Category | Default Recommendation | Why |
|---|---|---|
| Authentication | Buy | Pure Context; real security stakes; near-zero cost at small scale (Clerk, free to $25/mo) |
| Payments | Buy | PCI-DSS compliance burden falls mostly on the processor, not you |
| Search | Buy, unless search IS your product | Context for most products; negligible cost at small scale (Algolia, free tier) |
| Email/notifications | Buy | Sender reputation and deliverability infrastructure take years to build independently |
| Analytics | Buy the tooling, own the data model | Lower downside risk than the above; instrumentation is closer to Core than the dashboarding layer |
When Vendor Dependency Becomes a Real Risk
What happens when a company becomes too dependent on a third-party API that changes or shuts down?
Facebook's 2016 announcement that it would shut down the Parse mobile backend platform — used by roughly 600,000 apps at its peak — gave developers exactly one year to migrate before the service closed on January 28, 2017. Twitter's 2023 API pricing overhaul similarly priced out many long-running tools built on its previously free tier with very short notice. Both are real, documented cases of exactly the risk this guide's “buy” recommendations need to be weighed against.
The Parse shutdown is a particularly instructive, well-documented case. Facebook, which had acquired Parse in 2013, announced on January 28, 2016 that it would discontinue the mobile backend-as-a-service platform exactly one year later, on January 28, 2017 (TechCrunch, “Facebook Shutters Its Parse Developer Platform,” January 28, 2016). At its peak, roughly 600,000 apps relied on Parse for exactly the kind of backend infrastructure this guide covers — authentication, data storage, push notifications — and every one of them had a hard, one-year deadline to migrate to a different backend or shut down. Facebook did open-source the Parse Server and SDK, giving developers a path to self-host a replacement rather than losing everything outright, which is a meaningfully better outcome than a vendor simply disappearing — but it still required real, unplanned migration work for every affected developer, on a timeline they didn't choose.
Twitter's 2023 API changes are a second, more recent, well-documented case, though it involves a different category (a social platform API rather than core product infrastructure) than the auth/payments/search examples above — still directly relevant to the general dependency-risk point. Twitter ended free API access with very short notice in February 2023, replacing it with tiers including a heavily restricted free level, a Basic tier at $100 a month, and an Enterprise tier reportedly around $42,000 a month (TechCrunch, “Twitter announces new API with only free, basic and enterprise levels,” March 29, 2023). Reporting at the time documented real casualties: academic researchers, nonprofits, and independent developers who had built tools — including disaster-response bots and accessibility tools — on the free tier lost access essentially overnight, with several long-running tools shutting down as a direct result.
“Parse will be fully retired after a year-long period, ending on January 28, 2017.”
— Kevin Lacker, Parse co-founder, announcing the platform's shutdown, January 2016 (as reported by TechCrunch)
These cases don't undermine this guide's core recommendation to buy rather than build for commodity categories — they sharpen it. The right response to dependency risk isn't avoiding third-party services altogether, which would mean rebuilding commodity infrastructure at real cost to hedge against a risk that's usually smaller than the cost of building it yourself. The right response is choosing vendors deliberately, understanding what a migration would actually require before you need one, and avoiding the kind of deep, hard-to-unwind coupling to a single vendor's proprietary data model or API surface that turned Parse's shutdown from an inconvenience into a genuine crisis for some of its 600,000 dependent apps.
Reducing Lock-In Without Avoiding Vendors Entirely
Can you reduce vendor lock-in risk without giving up the benefits of buying instead of building?
Yes, primarily through a thin abstraction layer: writing your own product code against a simple internal interface you control, with the actual third-party vendor called only from behind that interface. This doesn't eliminate the vendor dependency, but it substantially reduces the cost of ever needing to switch, since only the implementation behind the interface needs to change, not every place in your product that touches authentication, payments, or search.
The practical pattern is straightforward and doesn't require exotic engineering: rather than calling a vendor's SDK directly from dozens of places throughout a codebase, a product wraps that vendor behind its own small, internal interface — a “sendEmail” function, an “authenticateUser” function — that the rest of the product calls instead. If the underlying vendor ever needs to change, whether by choice or because of a scenario like Parse's shutdown, the change is contained to that one interface's implementation, not scattered across every part of the product that happened to call the vendor's API directly. This pattern costs a small amount of upfront engineering discipline — and it's worth being honest that it's not free, since designing a good abstraction takes real thought and can occasionally hide a vendor's more advanced features behind a simplified interface — but it converts a potentially product-wide migration into a contained, single-file change, which is exactly the kind of insurance worth buying for a Context capability you don't want deep, structural dependency on.
It's worth being clear about where this pattern is and isn't worth the investment. For a capability squarely in the “buy” category — authentication, payments, email — a lightweight abstraction is usually worth the modest upfront cost, since it's cheap relative to the real cost of an unplanned, product-wide migration under the kind of deadline pressure the Parse and Twitter API cases both illustrate. For a capability closer to the Core end of Moore's spectrum, where you're building custom logic on top of a vendor rather than simply calling a commodity function, the abstraction question is less about swapping vendors and more about the normal software engineering discipline of keeping your own business logic separate from any specific third party's API shape — a good practice regardless of vendor risk specifically.
What to Check Before You Depend on an API
Stripe's own engineering blog offers a useful, concrete example of what a genuinely transparent vendor looks like on this front. Stripe's public status page, built in 2012 and credited to Stripe engineer Amber Feng, publishes rolling 90-day uptime history broken out by individual service — its main site, its API, and Stripe.js separately — rather than a single, vague, current-status-only indicator (stripe.dev, “A short history of the Stripe status page”). This kind of historical, service-level transparency is exactly what's worth checking for before your product comes to depend on any third-party API, and its absence is itself informative: a vendor with only a current-status indicator and no historical uptime data is asking you to trust a track record you can't actually see.
- 1
Check for a real, historical status page — not just a current-status indicator
A status page showing 90 days of uptime history by individual service, the way Stripe's does, tells you far more than a single "all systems operational" banner that resets on every page load.
- 2
Look for a documented SLA with actual remedies, not just a percentage
An uptime percentage without a stated remedy (service credits, defined escalation) is a marketing claim, not a real commitment you can hold the vendor to.
- 3
Confirm published rate limits and what happens when you exceed them
Undocumented or unclear rate limits are a common source of production incidents that only surface at scale, well after a vendor integration already feels safe.
- 4
Ask what a real migration off this vendor would require, before you need to answer under pressure
The Parse and Twitter API cases both show migrations happen on the vendor's timeline, not yours — knowing your actual exit cost in advance is cheap; discovering it during a forced migration is not.
How this decision shifts as a product scales
It's worth being direct that the Core-vs-Context classification for a given capability isn't permanently fixed — it can genuinely shift as a company grows, and revisiting the decision periodically is different from treating a build-vs-buy call as a one-time, unrevisitable choice made at launch. A company at meaningful scale, sending millions of transactional emails a month, may find that a vendor's per-message pricing has become a real, material cost line item worth negotiating directly or reconsidering — not because email suddenly became Core, but because the economics of the buy decision changed with volume, the same way any vendor relationship's value proposition can shift as usage grows. Similarly, a search product that started as a straightforward integration might discover, after years of accumulating a very specific, differentiated ranking and relevance approach, that its search experience actually has become part of its competitive moat — at which point revisiting the original buy decision is a legitimate, considered choice, not a reversal born of impatience. The discipline worth keeping is applying the same honest Core-vs-Context test each time the question resurfaces, rather than assuming the original answer is permanent or that revisiting it automatically means the original decision was wrong.
The specific trap of “just this one feature” creep
A subtler version of the build-vs-buy mistake shows up not as a single, deliberate decision to build a whole capability from scratch, but as a slow accumulation of small custom additions layered on top of an otherwise sound vendor integration. A team using a vendor for authentication starts by adding one small custom piece of logic the vendor doesn't natively support, then another, then another — each individually reasonable, but collectively producing a system that's neither a clean vendor integration nor a fully custom build, carrying real maintenance costs of both without the clear benefits of either. This pattern is worth watching for specifically because no single decision in the sequence looks like the mistake described above — each one looks like a small, low-risk addition — and the cumulative effect only becomes visible in hindsight, once the vendor's original value proposition (letting you not think about this capability) has quietly eroded into a bespoke system that demands exactly the ongoing attention buying was meant to avoid.
Common Build-vs-Buy Mistakes
Applying the Core-vs-Context framework directly surfaces the two mistakes that recur most often in this decision, on opposite ends of the same spectrum. The first is building genuinely commodity infrastructure — authentication chief among them — from scratch, out of either a not-invented-here instinct or an underestimate of how much real engineering time a seemingly simple capability actually requires to build securely and maintain indefinitely. This mistake is expensive in a specific, quiet way: the engineering time spent isn't just the initial build, it's the ongoing maintenance, security patching, and edge-case handling a specialized vendor has already absorbed as part of their own product, forever, for every customer at once.
The second, opposite mistake is integrating a vendor for a capability that's actually Core to your product's differentiation, without a plan for what happens if that vendor's pricing changes dramatically or the vendor is acquired and shut down — precisely the Parse and Twitter API scenarios covered above. This mistake is harder to see coming, because a vendor integration for a differentiating capability often looks identical, day to day, to a vendor integration for a commodity one — it's only when a real transition point (a funding round, a pricing change, a shutdown announcement) arrives that the difference between “acceptable dependency” and “dangerous dependency” actually becomes visible. Applying the Core-vs-Context test explicitly, at the time of the original integration decision rather than after, is the specific habit that prevents this second mistake from becoming a costly surprise later.
Is this capability Core or Context?
Apply Moore's test directly: does building this create competitive advantage a rival can't easily replicate, or does it just replicate what every product in your category needs the same way?
Weigh real vendor cost against real build cost
For most commodity categories, a vendor's free or low-cost tier is negligible next to the ongoing engineering time a comparable in-house build actually requires.
Check the vendor's real track record before integrating
A historical status page, a documented SLA, and clear rate limits are the concrete things to check — not just current pricing and feature lists.
Know your exit cost before you need it
The Parse and Twitter API cases both show migrations happen on the vendor's timeline — understanding what a real migration would require, in advance, turns a forced deadline into a manageable project.
Taken together, the five categories in this guide share a common shape worth naming directly: each one looks, at first glance, like a reasonable candidate for a quick custom build, and each one turns out, on closer inspection, to carry far more accumulated complexity, security stakes, or maintenance burden than its surface simplicity suggests. That gap between how simple a capability looks and how much real engineering effort a production-grade version actually requires is precisely what specialized vendors have already absorbed, and precisely what a founder is buying when they choose a vendor over a build — not just the feature itself, but years of accumulated hardening against exactly the edge cases a first-time build hasn't yet discovered.
Frequently Asked Questions
What is the Core-vs-Context framework for build-vs-buy decisions?
A framework from Geoffrey A. Moore's books "Living on the Fault Line" and "Dealing with Darwin," distinguishing Core activities (create sustainable competitive advantage) from Context activities (necessary but non-differentiating). Moore's own prescription for Context work is that it should be standardized and outsourced, while Core work is where a company should invest its own engineering effort.
Should a startup ever build its own authentication system?
Almost never. OWASP's own Top 10 identifies authentication failures — weak password storage, missing multi-factor authentication, no protection against credential stuffing — as a major, common web application risk. Specialized providers like Clerk offer authentication free or near-free at small scale (50,000 monthly active users on Clerk's free tier), making the trade heavily favor buying.
Why is building your own payment processing risky?
Any business that stores, processes, or transmits cardholder data falls under PCI-DSS, the payment industry's security standard, per the PCI Security Standards Council's own published scope. Using a processor like Stripe that handles cardholder data directly removes most of that compliance burden from your own infrastructure, since sensitive data never touches your servers.
When does it make sense to build custom search instead of using a search API?
Only when search relevance or algorithm quality is genuinely your product's core differentiator — true for a narrow set of specialized discovery or research tools, but not for the average SaaS product where users simply need to find their own records. Algolia's own pricing offers a free tier (10,000 requests, 50,000 records monthly) that's negligible for most products relative to the engineering cost of building comparable infrastructure.
Why do dedicated email services deliver better than self-hosted mail servers?
Established providers maintain sender IP reputation, warm-up processes, and direct feedback-loop relationships with major mailbox providers that a new, small, self-hosted server has no realistic way to replicate immediately. This guide could not verify one specific, primary-sourced deliverability percentage difference, but the underlying reputation-infrastructure mechanism is well-established.
Is analytics a build-or-buy decision the same way authentication and payments are?
Not quite. PostHog's own pricing shows a free tier (1,000,000 events monthly) covering 97% of its companies, making buying the practical default — but the downside of a minor gap in custom analytics is far lower than a security failure in home-grown auth, making a hybrid approach (buy the dashboarding layer, own the event instrumentation) more reasonable here than for the other categories.
What happened when Facebook shut down the Parse backend platform?
Facebook announced on January 28, 2016 that it would shut down Parse, a mobile backend-as-a-service platform used by roughly 600,000 apps at its peak, giving developers exactly one year — until January 28, 2017 — to migrate. Facebook open-sourced the Parse Server and SDK so developers could self-host a replacement, but every affected app still faced a real, unplanned migration on a deadline it didn't choose.
What happened to Twitter's API pricing in 2023?
Twitter ended free API access with very short notice in February 2023, introducing tiers including a heavily restricted free level, a $100/month Basic tier, and an Enterprise tier reportedly around $42,000/month. Reporting at the time documented real casualties — researchers, nonprofits, and independent developers whose tools, including disaster-response bots, lost access and in some cases shut down.
What should you check before your product depends on a third-party API?
A real historical status page (not just a current-status indicator) showing uptime by individual service, a documented SLA with actual remedies rather than just a percentage claim, clearly published rate limits, and — critically — an honest understanding of what a real migration off that vendor would require, worked out before you're forced to find out under deadline pressure.
What are the two most common build-vs-buy mistakes?
Building genuinely commodity infrastructure — authentication especially — from scratch, underestimating the ongoing maintenance burden a specialized vendor has already absorbed. And the opposite: integrating a vendor for a capability that's actually Core to your differentiation without a migration plan, leaving you exposed the way Parse and Twitter API users were when those platforms changed dramatically with short notice.
What is often overlooked in the cost of building your own authentication?
Session management, password reset flows, and multi-factor authentication — the parts of auth that happen after the initial login screen. OWASP explicitly flags multi-factor authentication as commonly missing or ineffective when implemented ad hoc. A specialized provider has hardened all of these secondary flows as thoroughly as the login screen itself, which a first-time build can't replicate quickly.
Is payment processing complexity only about PCI-DSS compliance?
No. Subscription billing adds a second, independent layer: proration on plan changes, failed-charge retry logic, multi-jurisdiction tax calculation, and reconciliation. A mature billing platform has already solved these edge cases across thousands of customers — building them from scratch means rediscovering each one independently, typically when a real customer hits it in production.
How can you reduce vendor lock-in risk without avoiding vendors entirely?
Wrap the vendor behind a thin internal abstraction — your own interface (like a sendEmail or authenticateUser function) that the rest of your product calls, rather than calling the vendor's SDK directly throughout the codebase. If the vendor ever needs to change, the change stays contained to one implementation instead of scattering across the entire product.
Can a capability that started as "buy" later become worth building in-house?
Yes. The Core-vs-Context classification can shift with scale — a vendor's per-unit pricing can become a material cost line at high volume, or a capability like search can accumulate enough product-specific differentiation over years to genuinely become part of a competitive moat. The discipline is applying the same honest Core-vs-Context test each time the question resurfaces, rather than treating the original decision as permanent or assuming revisiting it means the original call was wrong.
What is the "just this one feature" trap in vendor integrations?
A slow accumulation of small custom additions layered onto an otherwise sound vendor integration, where each individual addition looks reasonable but the cumulative effect produces a system that's neither a clean integration nor a fully custom build — carrying the maintenance costs of both without the clear benefit of either. It's worth watching for specifically because no single step in the sequence looks like the mistake.
None of the categories in this guide require a difficult decision once the Core-vs-Context test is applied honestly: authentication, payments, search, and email are Context for the overwhelming majority of products, and the real engineering cost of building them from scratch rarely earns its keep against what a specialized vendor already offers at negligible cost for an early-stage product. Analytics sits closer to the line, worth a genuine hybrid approach rather than a clean answer either way. What this guide adds beyond a simple “always buy” recommendation is the other half of the decision — vetting a vendor's real track record before depending on it, and understanding your actual exit cost in advance — since the Parse and Twitter API cases both show that buying the right thing still requires the same due diligence building it yourself would have demanded, just applied to a different, and usually much cheaper, set of risks.