The company behind the Centurion Club and the Black Card, best known for a concierge service and charge cards without limits, and for turning the card in your wallet into a lifestyle choice, that company started out without a product or almost any capital to speak of.
\nIt started, instead, with an idea.
\nIt was the 1840’s, the railroad was shrinking the travel time between cities from days to hours, and suddenly it was possible to send stuff from one place to another, fast. That is, if you had time to take the train yourself and hand-deliver the parcel, or enough trust to hand it to a stranger on the platform heading to the same destination.
\nTherein was an idea: A fast shipping service to carry parcels between cities on behalf of others. An express service, with little startup costs beyond one man’s time to ride the train with a bundle of packages. Someone had the idea, others copied it, and like any emerging industry with no barriers to entry, suddenly expressmen were everywhere. Three of them banded together in 1850 (among them, one guy named Wells, another Fargo—a story for another day), called their partnership American Express, and for a while the quickest way to send something along the eastern seaboard was with what we’d come to shorten as AMEX.
\nPeople shipped everything, back then: Documents, letters, parcels—and gold, coins, and cash. In the days before PayPal and Venmo and bank transfers, the best way to send money between cities was putting it in an envelope and trusting the American Express man to deliver it safely.
\nThere was another idea: Sending money securely without shipping actual cash. The postal service was selling money orders, checks redeemable for cash by recipients. American Express entered the fray, competing by lowering the price, simplifying the form, and adding security features to broaden money orders’ audience and not lose their shirt in the process.
\nPeople sent money orders everywhere, started using them in lieu of cash and sending them overseas. It wasn’t a huge leap to start selling traveler’s cheques—British spelling and all—with a few American Express tweaks like a fixed exchange rate (implausible today, possible then) and a guarantee that lost checks could be recovered.
\nTraveler’s cheques were a hit, enough that a newspaper later remarked that the American Express office was “the first stopping place for every American upon his arrival in Paris.” The demand was enough to prompt expansion, adding enough space for tourists to hang out, orient themselves in a new city, book travel with American Express agents, cash their checks, and perhaps ship some packages home.
\nAnd from there it’s not hard to squint and see how a firm founded to ferry parcels on trains would one day be best known for airport lounges as a perk for using their financial instruments—checks then, cards today, moving money for people all the same.
\nWhat’s impossible to imagine is three guys, in 1850, dreaming up a credit card and airport lounge empire, fifty-three years before the first powered human flight and a century before the first credit card. Reading through American Express’ unofficial history, it struck me that every new service they offered came only through launching the previous product, seeing how customers used it, and letting curiosity and customer behavior drive the company’s next ventures.
\nThe only way to find out what you’re going to be is to start, then see what’s possible along the way.
\nImage Credits: Traveler's Cheques photo via Wikipedia
","images":[{"url":"https://blog.reproof.app/media/pages/blog/amex-history/672c3f0cfd-1778143741/amex_travelers_cheque.jpg"}]},{"num":20260321,"slug":"ai-as-fuzzy-search","title":"AI as fuzzy search","subheading":"A modern interview stack","author":"Matthew Guay","tags":["writing","AI"],"color":"","date":"March 21, 2026","cover":{"extension":"jpg","filename":"niklas-hamann-r0rya09bex8-unsplash.jpg","height":1420,"id":"blog/ai-as-fuzzy-search/niklas-hamann-r0rya09bex8-unsplash.jpg","mime":"image/jpeg","niceSize":"1.13 MB","template":"image","type":"image","url":"https://blog.reproof.app/media/pages/blog/ai-as-fuzzy-search/fb3e9e06a0-1774069356/niklas-hamann-r0rya09bex8-unsplash.jpg","width":1500},"text":"The idea started with Benjamín Labatut’s The MANIAC, a fictional oral history-style narrative about mathematician John von Neumann. What starts as a near-reality narrative about Neumann’s work and genius descends into near-madness as one technological development after another snowballs into machines that can think, each step presented in the imagined quoted voice of a contemporary. One step after another, you cease to understand the world, and with Labatut, begin questioning what happens when machines outthink humans.
\nFound history, oral narratives, quotes melded into a patchwork, now this person telling their perspective, now this person building on it, now another contrasting it, until a fuller picture of the idea emerges than would be possible in a traditional narrative.
\nAnd so I set out to write one.
\nThe idea was to interview a dozen people about their workflows, and turn it into a series of articles about what goes into turning a budding idea for a blog or newsletter into a successful publication from scratch. And, perhaps, the quote-heavy format could impart more life to what could otherwise easily be a dry, prescriptive documentation.
\nSimple enough at face value, far harder when you have eight hours of call recordings and pages of notes and only a fuzzy recollection of what each person said. Scrubbing works when you know the desired quote is at 07:39 in the recording; search excels when you know they mentioned a specific keyword then and then only. But if you recall only that the interviewee said something about not hitting a deadline and it was in the latter half of the call but you can’t remember the exact phrasing, you’d better have a half hour free to find that needle in the proverbial haystack. Rinse, repeat for every other idea you need to resurface from the hours of recordings.
\nOr you could use AI to lighten the load. Maybe.
\nI’d be remiss to ignore the elephant in the room, that AI-hallucinated quotes from a workflow not all that dissimilar from the one I’m recommending below is what recently tripped up an Ars Technica writer, leading them to publish a piece with quotes the AI made up but that they believed had come directly from their source material. The risk is real. Yet I believe that it’s a manageable risk—that the benefit of the tool merits use with guardrails, just as a bandsaw isn’t worth dismissing for woodwork but is worth using with healthy caution and failsafe guardrails—and you need a workflow that marries the best of AI and human-directed research.
\nI’d written, six months before ChatGPT launched, that AI was here to save you from busywork. “Robots aren’t ready to write your blog posts,” I wrote, optimistic for team human.
\nThat aged poorly.
\nYet I’d still argue, at least today in early 2026, that it’s fairly easy to sniff out AI-written content. AI has overused my beloved em dash to the point that they’re seen as de facto proof of AI writing (I present to the jury my decade of em dash use prior to the great AI-fication as evidence that humans, too, can use the best dash, and rest my case). They’re fond of “it’s not this, it’s that” comparisons, one-sentence paragraphs, and rhetorical questions followed by an answer. I now purposefully avoid all in my writing, along with other AI tropes. Beyond those, there’s still a feeling, a certain je ne sais quoi, if you will, to AI written text. You know it when you read it. Or, at least, this cheerleader for team human hopes. To ignore it, though, to fully discount AI as slop, risks myopia veering on ludditeness, akin to obstinately rejecting spellcheck in 1997.
\nYou shouldn’t have AI write for you, not when writing is thinking and half the job of writing is to process your ideas about a thing. But you should have it do the tasks it’s best at.
\nAI is a very good proofreader, adept at catching spelling mistakes (including inconsistent name spelling), miswritten words, tense changes, clichés, and repetitive phrasings, much better than a traditional spellcheck is at any of those. You should definitely have AI run through your draft writing and tell you what to change and why (don’t have it wholesale make the changes for you, unless you want a smoothed-out simulacrum of your original writing).
\nAI is great as a fuzzy search. When you want a quote that’s about something in general but you don’t remember the exact wording, Google’s likely to fail where AI is far more likely to succeed. You have to carefully double-check and ask for citations; quotes are where hallucinations are most likely to surface. But it’s reasonably good at finding needles in the internet’s haystack (but that comes with the additional job of verification; you should never take a quote from AI at face value, instead treating it as a possible clue in a wider research project that you need to verify before ever considering using it in your work).
\nCombine the two ideas—AI’s good at focused tasks around existing text, and good at more abstract extraction but more fallible when searching against the corpus of human knowledge—and you find another use case: Fuzzy search inside your existing text. All you need is a large enough context window. That, tempered with guardrails of only using AI as a first-level search, then searching for that quote and copying directly from the original source material.
\nAnd so I switched to Kiro, Amazon’s take on an AI coding app (Cursor, Visual Studio Code, and Claude Code running in Terminal should, generally, work just as well, as theoretically could directly chat in ChatGPT or Claude but with more limited context windows).
\nThe basic setup is simple:
\nI took each interview in Zoom, recording the conversation with both Zoom’s transcripts and with Granola for a quick summary and outlines. I saved each interview, individually, in a plain text file titled with the interviewee’s name, saved in a folder for this project.
\nThen came the code editor. I opened the folder in Kiro, then opened the chat and asked for quotes about specific topics. “Find a quote from PersonX about a time that they ScenarioY”-type prompts, or broader ones like “Find all of the quotes about ScenarioZ.” In my experience, AI in a coding app focused on local documents is far less likely to be inaccurate, and yet it’s still not perfect. Citations were tricky; I could ask for line items from better-formatted interviews, but that only narrows the scope in longer conversations with run-on paragraphs.
\nAnd if anything, that’s good: You should always copy the quotes from your raw source material, and never directly from the AI chat. AI results require eternal vigilance, because as writers have already found, AI tools can still hallucinate quotes, no matter how fine-tuned they are. Using AI as a search tool, then actually copying the quotes from your original notes is the only insurance against hallucinated quotes that were never actually said by a human.
\n90% of the time or better, the AI returned exact quotes. AI inside coding environments are built to execute on the files you currently have open, and that process is generally the same no matter what type of text the files contain. It’s less likely to delete critical code from text and less likely to make up quotes that don’t exist in the source material. It only went off the rails when I asked for quotes that weren’t there—and even still, it tended to respond with less-relevant quotes rather than fully hallucinated quotes. And it was less accurate when I stored the article draft and my notes files in the same folder; it works best when it only has access to interviews.
\nSo I would ask AI chat for a quote from a person, then open their interview document, press CMD+F, and search for a few words of the quote that AI surfaced. Formatting oddities often meant that the full quote wouldn’t show up in a search, so I’d search for a seemingly unique phrase to find the original quote.
\nSometimes I’d go with the quote that AI surfaced, copying it, cleaning up filler words and repetition from the transcribed audio, then using that in my final draft. Often, though, the quotes AI found were clues in a wider discovery process. I’d take a quote that AI surfaced, search for it in the source material, and often find a wider story or some more human anecdote that wasn’t the precise quote I was looking through but that would add color to the story.
And so I worked through the material, drafting early outlines from post-call intuition, refining them with AI-surfaced quotes, digging deeper into the source material as the AI found spots worth highlighting, then discovering something I’d forgotten or otherwise missed and sending the AI on a quest to find similar threads in other interviews. Rinse, repeat, as the piece took shape, written by me, with AI as a gopher.
\nThat left me with the work of thinking through the interviews and turning them into a narrative. That’s hard enough. And I could only do that by reading through the interviews and thinking through the answers.
\nA similar workflow could work for any research project. Whether pointing the AI at your carefully curated notes or at original source material, AI can help you find quotes that are similar but not exactly like what you’re looking for. It can organize those—but here there be dragons, and I’d argue your best work is done when you think through the content and come to your own conclusions on meaning and order, relying on your writing intuition on what to feature when. Research. Pull your thesis together. Use AI to help resurface quotes. Search for those quotes in your source material, and pull them into your writing. Revise. Proofread. Double-check everything.
\nWith an AI to help do the busywork of finding needles in the haystack of research, you’ll have more time to think through the material and waste less time looking for something you know was there but can’t manage to find again. AI saved you enough time already; invest a bit of that savings in double and triple checking everything, in using the quotes as a springboard to zoom out and work in more context.
\nAnd that’s a win—even if it does still require more work, more searching and re-checking, than just copying surfaced quotes directly from chat.
\nHeader Image by Niklas Hamann via Unsplash
","images":[{"url":"https://blog.reproof.app/media/pages/blog/ai-as-fuzzy-search/fb3e9e06a0-1774069356/niklas-hamann-r0rya09bex8-unsplash.jpg"}]},{"num":20230314,"slug":"accessibility-for-writers","title":"How to write accessibly and make your content better for everyone","subheading":"Accessibility for Writers","author":"Matthew Guay","tags":["writing","accessibility"],"color":"","date":"March 14, 2023","cover":{"extension":"jpg","filename":"daniel-ali-ju1yfzkrxvg-unsplash.jpg","height":1002,"id":"blog/accessibility-for-writers/daniel-ali-ju1yfzkrxvg-unsplash.jpg","mime":"image/jpeg","niceSize":"477.57 KB","template":"image","type":"image","url":"https://blog.reproof.app/media/pages/blog/accessibility-for-writers/a71baa7721-1678778990/daniel-ali-ju1yfzkrxvg-unsplash.jpg","width":1500},"text":"\n\n“Two of the most important characteristics of good design are discoverability and understanding.”
\n
\nDon Norman, The Design of Everyday Things
Ever stopped to think about how people read your blog posts? They might open them in their browser and read them directly. They might read your writing from your newsletter, in their email app, or might save your writing for later and read it in Instapaper or Pocket. They could get Siri or another screen reader to read your writing aloud, turning it into an ad-hoc podcast. They might skim your article for headings, or use keyboard shortcuts to jump around to the spot they're most interested in.
\nWriting isn't enough. You also need to make sure your words are accessible.
\nIt's easy to abdicate the responsibility of accessibility—of making your site, app, and content usable by everyone, regardless of how they're browsing what you've created—to the design and development team. It's their job to craft accessible code, to ensure everyone can open your app, browse your site, and read the words you've published. They can think about responsive design, screen reader support, and keyboard navigation. Your job is to write—and writing is accessible by default. Any screen reader app can read your writing, as long as the dev team does their job.
\nAnd yet, if your content isn't structured well, if your images don't include alt tags, if your terms aren't defined well enough for everyone to understand them, no accessible design can save your writing. The best screen reader won't be able to help people navigate your words if you haven't written them for navigation from the start.
\nThe good thing is, the same rules for creating great content for the web are the same as those for creating accessible content. A few minutes invested in improving your text before publishing may pay off dividends later in better search rankings and improved reader retention from your entire audience. At the least, they'll make your site better for everyone.
\nHere's where to focus when writing and publishing on your blog, to make sure everything you publish is accessible.
\nYou get exactly six heading options in HTML, from H1, the largest, to H6, the smallest. Use them wisely.
\nYou'll start your blog post with a title. That'll likely get formatted as an H1 (what's called \"Heading 1\" in Word and Google Docs)—and each page should have a single H1 tag that tells readers and search engines alike what you're writing about. So H1's taken care of; don't add another one.
\nThen you'll want to split your writing into sections. Under that title, you'll likely add an intro, then a heading to title the first section of what you're writing. That should be an H2—as should every subsequent, top-level heading. Every section heading in this blog post, for example, is an H2, as it's a straightforward post that doesn't need sub-sections.
\nIf what you're writing is more complicated, and sections need to be broken into smaller sections, use H3 headings, one for each sub-section. Switch back to an H2 once that section's finished, and you're introducing the next top-level section. Need to get even more precise? Put H4's inside your H3's, and H5's inside your H4's, and so on. Every time, make sure you nest them correctly. If you're writing a list of countries, with a list of cities nested under each country, and regions in cities nested under cities, and locations in regions under that, you'd end up with something like this:
\n# Asia: An Overview\n ## Japan\n ### Tokyo\n #### Shibuya\n ##### Shibuya Scramble Crossing\n ###### How to get there\n ###### What to do there\n ##### Shibuya Sky\n ##### Yoyogi Park\n #### Ginza\n ### Osaka\n ## China\n ## South KoreaIt's rare you'll need that much detail. But the header options are there when you need them. Just use them carefully.
\nScreen reader apps—tools like the built-in VoiceOver on Macs and the popular JAWS and NVDA on Windows—let readers browse a site by headers. It'll read the H1 title, then the H2 headings, and so on, so blind, vision impaired, and sighted readers alike can skim an article to find what they want. Get your headings wrong, though, and the screen reader will lead readers astray.
\nIt's not just screen reader apps that'll have trouble. Search engines, too, rely on headings to learn about your article and recommend specific sections. The bit of extra time it takes to get your headings right might be the thing that brings people to your site from Google, just for one specific section of your post.
\nYou're focused on words; images are there to aid your storytelling. They tell a thousand words on their own, or so they say, but they still need a few more words to help tell your story.
\nAlt text lets you add the words that your pictures are missing. An image on its own won't mean anything to a screen reader, or a search engine. The alt text lets you explain the image so everyone understands why it's there.
\nWhich, for what it's worth, might include sighted readers who don't quite understand the connection between your source material and the image illustrating it. The caption's another chance to explain the picture and its implications and relation to your copy.
\nYou need both: Alt text to clearly describe the image, and a caption to share the meaning of the image.
\nWrite the alt text to describe what the image the way you'd describe an image if you were talking about it. A photo of a tree might include the alt text \"A photo of a palm tree, standing in a field, under a blue sky.\" Then, write the caption to describe why the image is there, something like \"What could be more relaxing than sitting under a palm tree?\" And don't do it for only photos: Add alt text and descriptive captions to screenshots, GIFs, and videos alike—at least captions, for the latter.
\nYour site might show up in Google Image searches for palm trees, thanks to the alt text. And your readers will know exactly what and why you're showing, no matter how they're reading your writing.
\n\"Click here to learn more\" is the worst possible way to write a link.
\nYou won't even remember what \"Click here\" links to, a year from now. Your readers don't stand a chance. They deserve more information about what exactly they're in for, before they click.
\nThe best links describe exactly where they'll take you when you click them. The first time you mention a company or product name, link to its homepage. Link the credits after the quote to their original source—and link the whole \"said Person Name,\" not just the word \"said.\" Link to a full phrase, like notes apps are where ideas go to die, using the title or a direct quote when linking to another site on your site. And for CTAs (call to actions) like newsletter or app signup links, link the full phrase like \"join our newsletter\" or \"signup for Reproof\" instead of linking only the word \"join\" or \"signup.\"
\nIt's better for readers, who'll know what they're clicking on. It's better for screen reader apps, which will announce the linked text as yet another way to skim an article audibly (and here's where single-word links fail the most). And, it's better for Google search, where the entire search algorithm is built around links and their meaning.
\nSome things defy simple description. You can't add alt text to an emoji or a YouTube video embed. But you can add an aria-label to content that computers might need a bit of help figuring out how to read out loud.
Aria labels tell screen readers what an element on your site does. Your dev team might have already added aria labels to your site's menus and signup buttons. You can extend the trick to content you want to explain further in your blog posts.
\nSay you want to add a tongue-sticking-out emoji (😛) to your blog post to indicate sarcasm. Some screen readers will read out the emoji's official name, \"face with stuck out tongue.\" Others will skip over the emoji, or, perhaps worse, read out its unicode name U+1F61B. Instead, add your emoji in a span, and include an aria-label tag like this:
<span aria-label=\"just kidding\">😛</span>
Even better, you could also include a title tag, like this: title=\"just kidding\". That way, everyone will understand what you mean, with a screen reader or by hovering over the emoji.
Plain language—words your audience can understand the first time they read or hear it—is the newest buzzword in what we should have been doing all along. Write simply. \"Don't use a five-dollar word when a fifty-cent word will do,\" Mark Twain is said to have quipped in praise of simpler language.
\nSimple depends on your audience. You should know, generally, what your average readers should and shouldn't know. For the sake of the beginners, define things early on—perhaps in simpler, more introductory posts you can link to in subsequent, more advanced content. Use a trick from The Economist, where companies, no matter how well-known, are described the first time they're mentioned in an article (Coca-cola? \"The fizzy-drinks maker.\" Foxconn? \"A Taiwanese manufacturer.\" And so on.). They're tongue-in-cheek, at times (\"TikTok, a time sink.\"), a self-aware joke at the seeming redundancy with well-known companies. But no one knows everything; a few extra words to describe and define make your writing more accessible to everyone.
\nAnd to Google. Ever noticed a definition block at the top of a search result that didn't come from a dictionary? Often those come from in-copy definitions like these, which Google picks up as a more friendly way to explain a concept. Define words for your readers, and Google might take a liking to your definitions, too.
\nThen, it's back to the standard editing tricks. Read your writing out loud to see if it flows, and where to simplify. Cut out extraneous words and unnecessary phrases. Get others to proofread your writing and ask them for places you can simplify things. That extra bit of defining and editing, along with your well-structured prose and labeled images, will go a long way in helping all of your readers navigate your ideas.
\nEverything else in this list you'll need to check every time you write. But sometimes are once and done, thankfully, or at least something you can just check every so often.
\nYou know the core SEO things you should have on your site, the page title, site language, description, and more? Those things that help search engines play double-duty for accessibility. The title's going to be read out loud by screen readers; make sure it makes sense, for anyone who comes across it. The site language is how Chrome will decide if it should offer to translate your site for people who use a different language by default. And so on. Audit your site to make sure those things and core accessibility and SEO-focused features are working (check this simplified guide to the Web Content Accessibility Guidelines for the core things to check).
\nThen, try using your site in a screen reader. Check this guide to screen readers for a quick overview if you've never used one before, then try running through your blog using a screen reader. Notice anything that's broken, that would keep someone from successfully browsing your site through sound? Get that fixed, to make everything you publish better for everyone.
\nThen it's back to writing—this time, with a focus on making your writing great for everyone, every time.
\nImage Credit: Header photo by Daniel Ali via Unsplash.
","images":[{"url":"https://blog.reproof.app/media/pages/blog/accessibility-for-writers/a71baa7721-1678778990/daniel-ali-ju1yfzkrxvg-unsplash.jpg"}]}],"pagination":{"page":1,"pages":23,"offset":0,"limit":3,"total":68}},"status":"ok"}},"__N_SSG":true}