Build vs Buy: The Hidden Cost of a DIY Email Signature Tool

TL;DR: After seeing a vendor’s quote for email signature management, “can’t we just build this ourselves?” is a reasonable question — a mail flow rule script or a small internal Office Add-in genuinely can work, at first. The build is consistently the cheap part of the decision. What gets underestimated is the multi-year maintenance burden, the bus-factor risk of one engineer owning something nobody else understands, and what happens when Microsoft changes the underlying platform out from under it. There’s one legitimate exception — an actively maintained, community-supported open-source project — but that’s a different thing from an unsupported internal build, and it’s worth being precise about the difference before committing engineering time.

The question that comes right after the vendor quote

It tends to happen in a specific order. Someone requests pricing from an email signature management vendor, the number comes back, and someone in the room — often an engineer, sometimes a finance lead — asks the obvious question: why are we paying a monthly per-seat fee for something that’s fundamentally a mail flow rule and a template? Couldn’t one of our engineers build this in a sprint?

The honest answer is: probably yes, they could build a working version in a sprint. That’s exactly what makes the decision harder than it looks — the build genuinely is achievable, so the appeal is real, not naive. The problem is that the sprint to build it isn’t the cost that matters. The cost that matters is everything that happens afterward.

Why the appeal is real

It’s worth taking the case for building seriously before picking it apart, because the underlying reasoning isn’t wrong:

No per-seat subscription. A managed tool at even the low end of the market runs $0.81–$3.50 per user per month indefinitely (see Email Signature Software Pricing for the full comparison). For a 150-person organisation, that’s a real, recurring line item — one that a one-off engineering project appears to avoid entirely.

Full control. An internal build does exactly what you tell it to, with no vendor roadmap, no feature you don’t need bundled into a tier you do, and no risk of a vendor being acquired or discontinuing a product you depend on.

No vendor lock-in. You own the code, the data stays entirely in your own infrastructure, and there’s no migration project if you ever want to change approach.

All of that is genuinely true. None of it is the part that gets underestimated.

To make “the build is achievable” concrete rather than abstract: we built a minimal proof-of-concept version of exactly this ourselves — disclosure: it’s ours, published specifically to make this argument tangible, not a neutral find. It’s a real, working Office Add-in that injects a signature automatically, hosted for free on Cloudflare Pages, and it took well under a day. It’s also missing every safeguard this article is about to argue for: no update tracking, no directory sync, no fallback if Microsoft changes the add-in framework underneath it, and exactly one person (whoever forks it) who understands how it works. That gap between “a working weekend build” and “something that survives three years of new starters, leavers, and platform changes” is the entire subject of this article.

The hidden costs

The build is the cheap part. Writing a mail flow rule or a basic Office Add-in that inserts a signature is a matter of days, not months. Making it survive contact with an entire organisation over several years — new starters, leavers, role changes, a rebrand, a platform change, an edge case with shared mailboxes — is a standing commitment, not a one-time project. The total cost of a build is dominated by year two through year five, not by the initial sprint, and that’s precisely the part that doesn’t show up in the “let’s just build it” conversation.

Bus-factor risk. An internal tool is usually built and understood by one engineer, sometimes two. When that person moves teams or leaves the company, the tool doesn’t stop working immediately — it stops being maintainable. The next person who touches it is debugging undocumented code they didn’t write, under time pressure, the first time something breaks. A vendor’s product is maintained by a team whose job is specifically to keep it working; an internal build’s continuity depends on one person’s calendar.

Platform breakage you don’t control the timing of. This is the risk that’s easiest to dismiss until it happens. Microsoft’s own guidance on maintaining Office Add-ins is explicit that breaking changes do happen — API deprecations, manifest requirements that change, and updates that require admin re-consent before an add-in keeps working — and that add-in owners are responsible for tracking and responding to them. The concrete, recent example of this exact risk is the shift to new Outlook for Windows: COM-based (VSTO) add-ins, the architecture many homegrown and older commercial signature tools relied on, simply do not work in new Outlook at all (see New Outlook for Windows and Email Signatures for the full breakdown). An internal build on that architecture doesn’t degrade gracefully — it stops working the day the organisation migrates, with whoever’s left holding the tool responsible for an emergency rewrite on a timeline Microsoft set, not one your team chose.

No SLA, no escalation path. When a commercial tool breaks, there’s a support ticket, a status page, and usually a contractual response time. When an internal build breaks, there’s whoever’s on call, if anyone is. This asymmetry doesn’t matter much for a low-stakes failure. It matters a great deal when the tool breaks the morning of a product launch, a funding announcement, or any other email where the CEO is the sender and the signature is wrong or missing — and the honest answer to “when will this be fixed” is “whenever the one person who understands this code sees the alert.”

The quiet reversion to individually-managed signatures. When an internal build finally becomes too much trouble to maintain — the original engineer has left, or the platform-breakage fix keeps getting deprioritised — it doesn’t usually get replaced immediately. It gets quietly abandoned, and the organisation drifts back to individuals managing their own signatures in Outlook, which is exactly the uncontrolled state The Case Against Inconsistent Email Signatures in B2B puts a number on. An internal build that eventually fails hasn’t just cost the engineering time already spent — it’s cost the organisation a return trip to the problem it was built to solve.

The opportunity cost that never gets costed. The sprint to build the initial version has a real cost in engineering time, and every subsequent bug fix, new-starter edge case, and platform-compatibility fix has one too. That time is rarely weighed against the vendor’s per-seat price in the same spreadsheet, because it’s absorbed into “things the team was going to do anyway.” An honest build-vs-buy comparison prices engineering hours at their actual loaded cost and compares that total — not just the initial build — against what a managed tool would have cost for the same period. That comparison usually looks a lot worse for the internal build than the initial “we can do this in a sprint” conversation suggested.

The legitimate exception

None of this is an argument against open source generally — it’s specifically an argument against the unsupported, single-owner internal build. An actively maintained, community-supported open-source project is a different thing entirely, because the maintenance burden and the bus-factor risk are shared across a community rather than resting on one internal engineer. Set-OutlookSignatures is the clearest example in this category: it’s free, self-hosted, and has an active maintainer and a real user base tracking Microsoft’s platform changes on the project’s own timeline rather than yours. Choosing an actively maintained open-source tool is a legitimate, considered alternative to a commercial subscription. Writing your own from scratch and having it maintained by whoever’s free that sprint is not the same decision, even though both start from “we don’t want to pay a vendor.”

A simple framework for the real cost

Before committing engineering time to an internal build, total these five things honestly, over a 3-year horizon, not just for the initial build:

Initial build time, at loaded engineering cost, not just calendar time.
Expected annual maintenance time — new starters, leavers, role changes, minor fixes — estimated honestly rather than assumed to be zero.
Platform-change risk, priced as the cost of an emergency rewrite if Microsoft changes the underlying add-in framework or deprecates the approach you built on, multiplied by a realistic probability over 3 years (not low — this has already happened once with new Outlook).
Bus-factor cost — what it costs, in time or in outside help, to onboard a replacement engineer if the original owner leaves.
The support gap — what a broken signature costs the business on the worst plausible day it breaks, multiplied by how much longer that takes to fix without a vendor SLA.

Compare that total to the vendor quote, for the same 3-year period and the same headcount. For most organisations past a certain size, the vendor number stops looking expensive once the build is priced honestly — which is exactly why the vendors who survive in this category price per seat rather than per feature: the alternative most buyers are actually comparing against was never really free.

Frequently asked questions

Is it ever a good idea to build your own email signature tool?

Rarely, for a genuinely unsupported internal build — the maintenance burden and platform-breakage risk are usually underpriced relative to a managed tool’s per-seat cost. The exception is choosing an actively maintained, community-supported open-source project like Set-OutlookSignatures, where the maintenance burden is shared rather than resting on one internal engineer.

What’s the biggest hidden cost of building your own signature tool?

The multi-year maintenance burden, not the initial build. Writing a basic version is fast; keeping it working through new starters, leavers, role changes, and platform updates over several years is a standing commitment that’s rarely costed honestly at the point the build decision is made.

Why did new Outlook break so many homegrown signature tools?

New Outlook for Windows uses an entirely different add-in framework from classic Outlook. COM-based (VSTO) add-ins — the architecture many older commercial and homegrown signature tools relied on — don’t work in new Outlook at all, so any internal build on that architecture stops working the moment an organisation migrates. See New Outlook for Windows and Email Signatures for the technical detail.

How do I compare the true cost of building vs. buying?

Total the loaded cost of the initial build, realistic annual maintenance time, the risk-weighted cost of a platform-driven emergency rewrite, the cost of onboarding a replacement engineer if the original owner leaves, and the business cost of a broken signature on the worst plausible day — over a 3-year horizon — then compare that to the vendor’s per-seat price for the same period and headcount.

Does using open source count as “building your own”?

Not in the way this article means it. Choosing an actively maintained open-source project is closer to “buying” in terms of who carries the maintenance burden — a wider community, not one internal engineer. The risk this article is about is specifically the unsupported, single-owner internal build, not open source as a category.

SigHQ is an add-in-first email signature tool for Microsoft 365 organisations of 50–250 employees, built and maintained so IT teams don’t have to be — the maintenance burden this article describes is the exact problem the product exists to remove. Join the waitlist to follow progress.