Things We Couldn't Build Before

I did not have building a WordPress plugin on my roadmap for 2026. AskMason is live in the WordPress plugin directory today because a client had a problem that did not fit anything I could point them to, and because Auth/Technic is a venture studio, which means that when a problem looks like it deserves a product, building the product is on the table.

The Problem

The client I mentioned above creates experiences, and every one of them is different. Each has its own long page: dates, logistics, what to bring, what the medical requirements are, what happens on day four. Their visitors arrive with one question, and the honest answer to almost every question is "it is on the page." It is. Somewhere in four thousand words.

Site search does not help because there is nothing to search across: the individual event page is pretty much the whole world for that experience. A general chatbot helps less, because it will happily answer from everything on the site, which for a question about a specific departure for a specific voyage is exactly the wrong source. What the page needed was narrower than that: a way to ask a single page a question, get an answer drawn from that page, and be told plainly when that page does not have an appropriate answer.

That is AskMason. A small ask box on a page. A visitor types a question and gets an answer from that page's own text, with the section it came from. When the page does not cover the question, the assistant says so and points the visitor at the contact phone number or email you set. The key: It does not make guesses.

https://wordpress.org/plugins/askmason/

Why Build It Instead of Buying It

Three reasons:

The first is the client needed it. Nothing on the market did this narrow thing as specifically and carefully as I wanted, and building it for them was work I would likely have done anyway. The plugin is the same code, with the client's specifics kept in settings rather than baked in, and far less expensive to them at the license rate than it would have been for me to build it as a work for hire.

The second is the market. WordPress runs a remarkably large share of the web, the plugin directory is a distribution channel that already exists, and the tooling to sell paid versions to a WordPress audience is mature. I can deliver a free version in the directory, and offer paid tiers for sites that want more. I do not have to build the channel or find the market, just develop a tool that people will want and look for.

The third is the studio. Even if AskMason never becomes a revenue line, I now have a solution I can put in front of my own clients, and I have learned how the WordPress plugin world works from the inside: the review guidelines, the freemium build tooling, the licensing, what a directory listing needs. Those learnings have already paid for the time.

What it Does, Carefully

It answers from the page, not from the internet. The plugin reads the page's text as stored, keeps a snapshot, and sends that to the model with every question. The model is told to use only that material, and the plugin checks. A question the page cannot answer gets a plain "this page does not cover that" and your contact details.

It runs on your own key. You bring an API key from the model provider (Anthropic in the free version), and the plugin sends each question to that provider under your account. There is no AskMason service in the middle and nothing goes to Auth/Technic. You pay the provider for what your visitors ask, and the plugin caches the page text with the provider so a long page costs one read per cache window rather than one per question.

It stays inside your limits. Daily limits per visitor, per address, and site-wide; a per-minute cap for bursts; a monthly token budget that takes the ask box off the page when the month's allowance is spent, rather than letting the bill run. Every question and answer is logged on your site, so you can see what people ask and what the page failed to answer. That log is the most useful thing in the plugin: it is a list of what your page is missing.

It respects who may read the page. Only someone who can already view the page can ask about it. A page password counts.

The free plugin is the whole product for one page on one site. Nothing in it is switched off and it does not expire. Paid tiers add the style controls and the other model providers, then answers from the whole site, a report of what your pages fail to answer, per-page settings and a webhook, then unlimited sites. Prices and the policies are on the pricing page.

Most importantly, it does not rely on Retrieval Augmented Generation so there's no need to embed the content... and it respects Elementor and other page builder tools... so as soon as you edit the page's contents, AskMason answers with the new material. No additional effort required.

https://authtechnic.com/askmason/pricing

What Made it Feasible

The honest part of this story is the workflow. AskMason went from first commit to listing in the WordPress directory in nine days: 85 commits, about eleven thousand lines of PHP and twelve hundred of JavaScript, 358 automated tests, five of which boot a real WordPress and ask real questions. I did not type most of that. I worked with a language model the way I would work with a strong engineer who never gets tired of writing tests: I decided what the plugin should do and what it must never do, I reviewed what came back, I rejected what was wrong, and I made the calls that needed a human, from the tier ladder to the wording of a refusal, and I designed and directed every element of the user interface and settings experience as well as the feature tiering and pricing, using common patterns from the WordPress plugin world as I see them through my own experience lens.

Twenty years ago I would have been required to hand-craft every brick of this, which means it likely would never have happened. I chose the name Mason for this tool and my own site's LLM-powered software architect's assistant for that exact reason. It makes the bricks now and lays them where I ask, freeing me to be the architect and to design software structures I never could have considered before.

Without LLM assistance and my own years of experience, spinning up this capability could have taken a half-year or more, and it surely would not have made economic sense to build and deploy a whole plugin for one client's page. That arithmetic has changed. It changed for the SaaS work, it changed for the internal tooling, it changed for the software I wrote for the reMarkable tablet because I wanted to simplify one thing it did not do already, and it changed for this. It will not stop here.

I want to be careful with that claim, because it is easy to oversell. The model did not propose the idea of AskMason or decide what it should do. It did not know that a visitor asking about visa requirements or extreme environment gear and medical evacuation protocols must never get a guess. It did not choose to make the free version complete rather than crippled. The judgment is the job, and it still takes the time judgment takes. What changed is everything around the judgment: the cost of trying an idea, the cost of a test suite, the cost of being wrong and fixing it.

The Takeaway

Building custom software is within reach today in a way it was not a few years ago. If your organization has a problem that a piece of software would solve, "why don't we just build that ourselves" is no longer an irrational thought. It is a question worth asking properly: what would it take, what would it cost, what would we learn. Sometimes the answer is still to buy. Increasingly, the answer is to build, and see where it goes.

AskMason is where one of those questions went. If you run a page people ask you about, try it on that page and tell me what it got wrong. That is what the log is for.