I spent a week adding AI features to my developer tool suite. Natural language to regex. AI-powered SQL query explanations. The kind of features you'd expect in a 2026 product. They worked. Users could finally describe what they wanted in plain English and get a real answer back.
Then I ripped the AI out from under them.
Not the features themselves — some of them are still there, still labeled with the same Pro badge, still doing the same thing from the user's perspective. What changed is what runs behind the input box. The API calls to a remote LLM are gone. The features that survived are now powered by a few hundred lines of client-side pattern matching, and the features that couldn't survive that change are gone entirely.
This is the story of how that decision happened, why I think more solo developers should be making the same call, and the simple framework I now use before adding any new feature.
The setup
I run DevCrate — a suite of 22 browser-based developer tools. JSON formatter, JWT decoder, regex tester, cron builder, that kind of thing. The whole product has one promise: nothing leaves your browser. No accounts, no tracking, no data sent anywhere. You can paste production secrets into the JWT decoder and nothing will phone home.
That promise isn't a marketing line. It's the entire reason the product exists. Every other online dev tool sends your data to their server to process. Most developers don't think about it. The ones who do, want an alternative. That's me, that's my users.
For two months things were going well. Tools were shipping, search traffic was climbing, the project was actually starting to feel like a product. Then I had what felt like a great idea.
The "great" idea
The regex tool was popular but I could see the friction. People landed on it knowing what they wanted to match but not how to write it. "Match email addresses but not the ones with plus signs in them." "Find lines starting with a number followed by a period." Stuff that's trivial to describe and annoying to write as regex.
Solution: add a natural language input. Type the description, get the pattern. Powered by an API call to an LLM behind the scenes. Pro feature. Easy upsell.
Same logic applied to SQL — paste a query, get a plain English explanation. Inherited a 300-line query from a former coworker? Now you understand what it does in 10 seconds. Pro feature, easy upsell.
I built both. They worked. I shipped them. I felt clever.
The realization
A few days after shipping, I was testing the regex tool in the browser and noticed the network tab. The natural-language input was firing a request to api.anthropic.com — failing on CORS, technically, but trying. Every keystroke that triggered the "Generate" button was reaching out across the public internet with whatever the user had typed into the box.
The CORS failure was almost beside the point. The architecture was the problem. I had built a feature that, by design, took user input and sent it to a third party. The fact that it didn't currently succeed because the browser was blocking it was a security accident, not a security feature. The intended path was for that data to leave the machine.
I sat with that for a minute. I had two ways to think about it:
Option A: "Fix" the CORS issue by routing the request through my own Cloudflare Worker. Now the request succeeds. The user's regex description goes to my worker, which forwards it to the LLM, which sends back a pattern. Technically my homepage still says "nothing leaves your browser" because, well, it's only the Pro AI features that send anything anywhere. Everything else is still client-side.
Option B: Notice that the sentence I just wrote contains the word "only" doing a lot of load-bearing work, and that this is exactly how every product that betrays its users' trust talks about itself.
"Only the Pro features." "Only when you opt in." "Only the data we need." "Only to improve the service." Every analytics SDK is "opt-in." Every tracker is "for your benefit." Every data collection feature has a justification that sounds reasonable until you stack them up next to each other.
The whole reason DevCrate exists is that I got tired of products doing that. And here I was, doing that.
What I actually did
Here's the part where most blog posts oversimplify, so I want to be specific. I didn't remove the natural-language regex feature. I removed the AI behind it. There's a difference and it matters.
What got deleted entirely:
- The AI SQL query explainer. The whole feature is gone — there's no way to take an arbitrary SQL query and explain it without running it through a model, and I wasn't willing to do that. So that feature died.
What got rewired but kept:
- The regex tool's natural-language input. Same input box, same Pro badge, same "Generate →" button. But behind the button is now a function with about 30 hardcoded patterns covering the most common requests (email, phone, UUID, hex color, IPv4, "lines starting with a number," and so on). If your description matches one of them, you get the regex instantly. If it doesn't, you get a message explaining what phrases are supported, plus a link to my contact form pre-filled with what you tried — so I can grow the pattern list based on what real users are actually asking for.
- The cron tool's natural-language input. Same treatment. About 15 hardcoded patterns covering common schedules ("every weekday at 9am," "every 15 minutes," "first day of month"). No API call. If it doesn't match, you get a "suggest a pattern" link.
From the user's perspective, the regex and cron features still work for the common cases. The Pro badge is still there. The pitch is still "describe what you want, get the pattern." What's different is that nothing — not a single byte — leaves your browser when you use them. The features got dumber. The product promise got honest again.
I think this distinction is more useful than the version where I claim I "removed AI." A lot of AI features could be replaced with deterministic logic this way. The question isn't whether AI exists in your feature, it's whether AI is doing work a hardcoded function couldn't.
The framework I use now
This wasn't a one-off. Every product has a core promise — the thing you say to yourself and your users that defines what the product is. Privacy-first. Open source. No subscription. Beginner-friendly. Lightning-fast. Whatever it is, your features either reinforce that promise or they erode it.
Before I add any new feature now, I ask three questions:
1. Does this feature still work if I'm honest about what it does?
The test: write the marketing copy for the feature in the most boring, technical, accurate way possible. No spin. If "AI regex generator" becomes "we send your description to a third-party LLM provider and they return a regex pattern" and that statement contradicts something else on my homepage, the feature has a problem. Not necessarily a fatal one — but a problem worth solving before launch.
For the SQL explainer, the honest description was "we send your query to a third-party LLM." That broke the homepage promise. The feature died.
For the regex natural-language input, the honest description became "matches your description against a list of common patterns in your browser." That works fine. The feature lived.
2. What's the dumbest version of this feature that would still be useful?
The AI regex generator was an LLM call. The non-AI version was a 50-line function with hardcoded patterns. The dumb version covered 80% of real user requests, ran instantly, cost nothing, and didn't send a single byte off the user's machine. It wasn't as impressive. It was better for the product.
I'm not anti-AI. I use AI tools every day to build DevCrate. The question isn't whether AI is useful — it's whether this particular feature needs AI to deliver the value, or whether AI is just the impressive-sounding way to ship it.
3. Who benefits if I add this — me or the user?
This one stings. When I shipped the AI features I had a clear story: Pro upsell, modern feature set, market signal that the product is "real." Those are all reasons that benefit me. The user got a feature that mostly already existed in the form of asking ChatGPT directly — except now they were paying me for it.
Features that primarily benefit you (the developer) and only secondarily benefit the user have a way of eroding trust quietly. Users can feel it even when they can't articulate it.
What I'm not saying
I'm not saying don't add AI to your product. Many products genuinely benefit from AI features — that's why the entire industry is moving in that direction. Cursor, GitHub Copilot, Linear's AI features, Claude itself. All of them ship AI that earns its place.
I'm saying: be honest about whether your specific feature does. For a privacy-first browser tool, sending data to a third-party LLM was wrong — even when it was opt-in, even when it was a paid feature, even when the homepage was technically still accurate. For a code editor running on your local machine, calling out to an LLM is fine. The category matters more than the trend.
I'm also not saying I'd never bring real AI back to DevCrate. If I built a feature where the model ran entirely client-side — using something like WebLLM or a small WASM model — that would honor the privacy promise. The technology exists. It's not ready for the use cases I had in mind yet, but it's getting closer. When it's ready, that's a feature worth shipping.
The takeaway
The best moment to catch a feature that contradicts your product is before any user complains about it. Not because users won't notice — they will, eventually — but because by then the trust is already gone. The CORS error that flagged this for me was lucky timing. I'd rather build the kind of habit where I don't need lucky timing.
The version of the lesson I'm taking forward isn't "remove features." It's: separate the feature from the implementation. The AI was the implementation. The pitch was the feature. Some pitches can be kept by swapping the implementation. Some can't. Knowing which is which is most of the work.
The next time you find yourself adding a feature that requires a footnote to explain why it doesn't contradict your product's core promise, stop. Write the footnote. Read it out loud. Decide if you'd believe yourself.
If you wouldn't, your users won't either.
I'm William, the developer behind DevCrate. This is the kind of thing I'd love to talk through with other solo devs — if you've shipped a feature that you later realized fought with your product's core promise, I genuinely want to hear how you handled it.
What feature have you removed (or wished you'd removed) from your product? Drop it in the comments — I read every one.