Choosing boring technology for forms

In March 2015, Dan McKinley - then drawing on years of infrastructure experience at Etsy - published "Choose Boring Technology", and gave a name to something many engineers had felt but struggled to defend in meetings: the pull toward proven, unexciting tools is not timidity. It is strategy.

The essay's power is that it reframes the question. The interesting comparison is never "is the new database better than the old one?" - on paper, it often is. The comparison is between what each choice will cost you over years of operation, and that cost is dominated by what you do not yet know. A decade on, the essay has become one of the most-cited pieces of engineering writing on the web, and its argument maps with almost suspicious precision onto the least glamorous corner of any product: the forms.

McKinley's central device is the innovation token. Imagine your team is issued a small number of tokens - he suggests about three - each one representing your capacity to absorb a genuinely novel technology: to learn its failure modes in production, build expertise, and pay its operational tax indefinitely. Spend a token on something core to your business and it can compound into advantage. Spend it on infrastructure that was never your problem to innovate on, and you have bought risk with no matching upside.

The device works because it makes a fuzzy intuition countable. A team cannot adopt a novel frontend framework, a novel database, a novel queue, and a novel form stack simultaneously and expect to ship a product too. Something will be starved. The token metaphor forces the question every architecture meeting avoids: which of these novelties is actually the business?

Why do proven tools win the long game? McKinley's answer is epistemic, and it is the best part of the essay. Every technology has failure modes. Boring technology's failure modes are known - documented, blogged about, answered on Stack Overflow, familiar to anyone you might hire. Exciting technology's failure modes are unknown unknowns: you discover them at 2 a.m., in production, alone.

Notice that "boring" here does not mean bad, and it explicitly does not mean old for its own sake. It means well-understood. The boring choice is the one whose entire failure surface has already been mapped by other people, at their expense, over many years. That mapping is a gift. Declining it should require a reason.

Now apply the lens to forms. The HTML <form> element appeared in browsers in the early 1990s and was standardized in HTML 2.0 in 1995. It has since survived every attempt to replace it: Java applets, Flash forms, and a parade of JavaScript widget frameworks that reimplemented form controls from scratch, each generation discovering anew that the native element already handled focus, validation, autofill, accessibility, and mobile keyboards.

A plain form posting to an endpoint - a form action and a submit button - still works in every browser ever shipped, with JavaScript disabled, on a decade-old phone. That is not a legacy compromise. That is the most battle-tested UI component in the history of software, and our static-site contact form guide shows how far it gets you unassisted.

The destination side of a form stack has an even longer pedigree. The electronic spreadsheet arrived with VisiCalc in 1979, and the core interaction - a grid of cells, formulas that recalculate, columns you can sort and filter - has remained recognizable across Lotus 1-2-3, Excel, and Google Sheets for more than four decades. It may be the single most successful interface in software history, and certainly the most widely understood.

Which is exactly why it makes such a sturdy landing place for form data. Every stakeholder already knows how to filter a column, chart a range, and share a tab. There is no schema migration, no admin panel to learn, no per-seat dashboard license. We laid out the fuller case in Google Sheets as a form database; the short version is that for lead capture at small-team scale, the boring grid beats the bespoke database on every axis that matters day to day.

The third leg is the transport. HTTP began life in 1991 as a document-fetching protocol and has since absorbed nearly every wire format designed to beat it - and a POST request carrying urlencoded fields, the exact mechanism the first form implementations used, remains the lingua franca of the web.

The practical consequence: a form stack built on plain HTTP POST is compatible with everything - every browser, every static host, every no-code builder, every curl script, every webhook-emitting platform. A form endpoint is boring in precisely McKinley's sense: its failure modes are the ones the entire industry has spent thirty years learning to handle.

Add up what this stack costs to understand: an afternoon. Add up what it costs to debug: a browser's network tab and a spreadsheet's revision history. Compare that with the fashionable alternative - a headless form service wired through an automation platform into a CRM, each hop with its own auth, its own retry semantics, its own outage page. Every hop is a place to lose a lead and a system someone must remain expert in.

Boring compounds in quieter ways too. Anyone you hire already knows this stack. Migrating away is trivial - your data is in a spreadsheet you own, not a proprietary silo. And longevity is a feature in itself: bets on forms, HTTP, and spreadsheets are bets on technologies that have already outlived most companies. Our form backends roundup is, read one way, a survey of how much ceremony different vendors stack on top of this same boring core.

The boring-technology argument has failure modes of its own, and pretending otherwise would betray the essay's spirit. Boring can curdle into stagnation - teams that never spend a token, run ten-year-old everything, and cannot attract anyone who wants to grow. McKinley himself is explicit that the point is not to forbid new technology but to ration it deliberately.

And sometimes forms genuinely need a token. Real-time collaborative editing, hundred-step conditional logic, heavy file pipelines, offline-first field data collection - these push past what a plain form posting to an endpoint comfortably does, and reaching for specialized tooling there is the correct spend. The discipline is only this: know that you are spending a token, and spend it because the requirement is real, not because the demo was cool.

Here is the strategic core, translated to a small team's reality. Your users do not care what handles your forms. They care about the thing you are actually building - the product, the content, the service that made them visit at all. That is where your innovation tokens belong. A form stack is almost the definitional example of infrastructure that should be boring: a solved problem where novelty buys you nothing but a new set of unknown unknowns.

The tell is where your debugging hours go. Every hour spent diagnosing why an automation hop dropped a lead is an hour taken from the work only your team can do. Boring infrastructure is not a compromise on quality; it is a reallocation of scarce attention toward the problems that are genuinely yours.

We will be transparent about the motivated reasoning: we built a product on this thesis, so of course we find the thesis persuasive. SheetLink Forms is deliberately the boring stack with the operational gaps filled in - your HTML form, posting over plain HTTP to a permanent endpoint, landing as rows in a spreadsheet you own, with the unglamorous parts (spam screening, retries, delivery logs) handled the way how it works describes. Even the pricing follows the philosophy: no per-submission metering, because your form volume should not be an anxiety.

But judge the argument, not the vendor. The next time a new tool courts the most boring corner of your stack, ask McKinley's question first: is this where my tokens belong? For forms, we think the answer has been settled for about thirty years - and you can watch the boring stack do its job on the live demo.

What does "boring technology" actually mean?

What are innovation tokens?

Why do HTML forms count as boring technology?

Is a spreadsheet really a serious destination for form data?

When is boring technology the wrong choice for forms?

Isn't choosing boring technology just resistance to change?

What does a boring form stack look like in practice?

How do form backend vendors differ if the core is the same?