In the last few weeks, ProseLint Web had three big updates: it got a new name, added a page for open source licenses, and introduced a way to fully delete accounts. All of these changes came from community feedback, and I learned something valuable from each one.
In this post, I’ll explain what changed, why it happened, and what I learned while making these updates.
What changed
The rename
The app started out as The Vale App. Some community members pointed out that this name made it seem like an official Vale project, which it wasn’t. To clear up the confusion, I changed the name to ProseLint Web. It uses Vale, but it’s an independent, community-built web app.
The full details are in the name update post.
Open source license transparency
A user pointed out that ProseLint Web compiles Vale to WebAssembly and sends it to the browser, which is considered redistribution under the MIT license. They also noticed that not all Vale rule packages have the same license. That was a good observation.
Instead of just adding a license file, I created a /licenses page. It lists all 350+ npm dependencies by license type, shows each Vale rule package with its license, and includes Vale’s full MIT license text. The page updates automatically as dependencies change, so it stays accurate.
More on this in the license transparency post.
Account deletion
AA user pointed out there was no way to delete an account, which is a problem under GDPR. They were correct. Even though ProseLint Web handles documents on the client side, user accounts still keep an email address and authentication data. That information should be removable whenever a user wants.
Now, the app has a full account deletion process. There’s a Danger Zone section, a confirmation step where you type your email, and server-side deletion that fully removes your data.
Details are in the account deletion post.
What I learned from shipping all of this
Designing the features was simple. Most of my time and learning came from working on the infrastructure that supports them.
Updating domains
Renaming an app seems easy, but the domain is connected to everything: DNS records, SSL certificates, OAuth callback URLs, environment variables in Vercel, email domains, Supabase settings, and social login providers. I had to update each one carefully, and some things broke in staging before I fixed them.
The lesson here is to keep a checklist of every spot your domain shows up. There are always more than you expect.
Reconfiguring email and domains
ProseLint Web sends transactional emails for authentication (magic links, password resets, email confirmations). Changing the domain meant updating the sending domain, re-verifying DNS records for email deliverability (SPF, DKIM, DMARC), and making sure nothing landed in spam. Supabase’s custom SMTP and email template settings also needed updating.
This is one of those tasks that is invisible when it works and catastrophic when it doesn’t. A user who can’t receive a login email can’t use your app.
Handling Supabase updates
Supabase handles authentication and the database for ProseLint Web. After the rename, I had to update the site URL, redirect URLs, and email templates in the Supabase dashboard. I also updated the Supabase client settings in the Next.js app to point to the correct project and ensure the auth cookies use the correct domain.
I was surprised by how many settings are spread out in Supabase’s dashboard: authentication, email templates, URL settings, and API settings. Once I found everything, the updates went smoothly, but finding them took longer than I thought.
Account deletion with server-side Next.js
Building the account deletion process was the most interesting technical challenge. ProseLint Web uses Next.js with server-side API routes, and I needed to make sure deletion happened only on the server for security.
The flow works like this:
- The client sends a deletion request to a server-side API route
- The route verifies that the user is authenticated and that the confirmed email matches
- It calls Supabase’s admin API to delete the user and all associated data
- It clears the session and returns a confirmation
Using the Supabase Admin client (with the service role key) on the server side was essential. The regular client-side Supabase client doesn’t have permission to delete users — that requires elevated privileges that should never be exposed to the browser. Next.js API routes provided a clear boundary between what runs in the browser and what runs on the server.
Supabase docs deserve a shoutout
I want to specifically call out the Supabase documentation. It is genuinely excellent. When I was figuring out the admin API for user deletion, the server-side auth helpers for Next.js, and the nuances of Row Level Security, the docs had clear examples that closely matched real-world use cases. I didn’t have to piece together answers from Stack Overflow or GitHub issues — the official docs were sufficient.
If you’re building authentication with Supabase and Next.js, start with the Supabase Auth docs and the Next.js server-side guide. They explain exactly what you need, like creating a Supabase client for server components, handling cookies, and using the admin API for special tasks.
Good documentation makes a real difference when you’re deep in implementation. I try to remember that when I’m writing docs for my own projects.
Community feedback drives everything
Every one of these changes started with someone taking a few minutes to share feedback. The rename, license transparency, and account deletion requests came from the WTD community, which pointed out naming confusion.
Building in public means people will spot things you missed. That’s a good thing, not a problem. Every bit of feedback has improved ProseLint Web.
If you notice something that could be iIf you see anything that could be better, whether it’s a bug, a missing feature, or something about how the app works, I’d love to hear from you.
Thank you to everyone who has shared feedback so far. You’re helping shape this tool just as much as I am.