It’s a cool concept, but I can’t imagine what would make me want to frequent a message board that was explicitly designed to give wealthy users more of a voice. The wealthy have enough ability to project their influence as it is. The idea is considerably too capitalistic for my taste.
I totally get that! If it helps, my logic behind it is a mix of the following:
- The 'big' social media platforms already do this (give wealthy users more of a voice). It's just done in a less transparent and more manipulative way. Between ads and targeted algorithms, you get force fed content by large corporations and have your privacy invaded.
- Added based on user feedback, the 'message value decay' helps avoid both the situation you mentioned and more. Regardless of whether it's a politic message or an ad from a large corporation, if people hate seeing it, its value will drop quite drastically based on their reactions. Even an expensive message will be affordable to replace if it's disliked.
There's no doubt it's quite capitalistic (on the message submitter's side), but my goal was more focused on making that mechanic fair, straightforward, and respectful of users' privacy when compared to how it's usually done.
Of course, I'm extremely open to ideas/feedback on how it can be improved!
Just wanted to add a small update:
I've completed my research on charity donation integration and settled on donating to the EFF (Electronic Frontier Foundation)!
Mocking up the frontend changes with a dedicated page that will contain quarterly reports on donations, FAQ update, etc.
After some further research, settled on personally donating 25% of Say That Sh*'s revenue to the EFF every quarter <3 The standard seems to be something like 5% and that just seemed way too low?
I've realized the mechanics behind the site may not be all that interest to some (and likely disliked by many), so figured I'd share some of the technical details to give a little more 'meat' to the post.
The whole thing runs on three used Intel mini PCs (i5-10500T, 16-24GB RAM each) under my desk. k3s cluster with embedded etcd for HA. Total electricity cost is about $11/month.
Database: CloudNativePG operator manages PostgreSQL with automatic failover (5-30s). Built-in PgBouncer pooling via the Pooler CR so I don't need to manage a separate connection pooler. Continuous WAL archiving to a local Garage (Rust-based S3-compatible storage) machine gives me under 5 minutes RPO.
Cache/realtime: Redis Sentinel with 3 Redis + 3 Sentinel instances for automatic master failover. Socket.io sits on top with the Redis adapter so WebSocket connections work across multiple API replicas.
Backups are three-tier: Barman Cloud Plugin handles continuous PostgreSQL WAL + daily base backups. Restic does encrypted daily snapshots of secrets and pg_dumps. Longhorn handles volume snapshots. All three target the same Garage S3 box on my LAN. Six alerting rules monitor the entire chain — if any tier goes stale, I get a Telegram alert.
Screenshot generation was a fun one. When you post a message, the server generates a themed PNG of your message card for the email confirmation. Instead of spinning up a headless browser, I use Satori (JSX to SVG) + resvg (SVG to PNG). No Puppeteer, no Chrome, no browser at all. It renders the exact same React-like JSX with the user's theme colors and spits out a PNG in milliseconds.
The achievements system has 46 achievements across 8 categories and 6 tiers, all event-driven. When you post a message, leave a comment, or hit certain milestones, the evaluator checks eligibility and fires a WebSocket event for the toast notification. The whole thing is evaluated server-side so you can't fake progress.
Message value decay is borrowed from HN's own gravity-based ranking, actually. Values decrease over time following a configurable decay curve, and community reactions (likes/dislikes) directly influence the rate. Like a message and you slow its decay. Dislike it and it drops faster. The formula is feature-flagged so I can tune the gravity constant without a deploy.
Worker architecture: BullMQ with a dedicated worker process that runs independently from the API. Screenshots, emails, and async jobs all go through the queue. The worker can crash and restart without affecting API availability.
Monitoring is VictoriaMetrics + VictoriaLogs + Alloy + Grafana with 16 auto-provisioned dashboards. Probably the most overengineered monitoring setup for a message board in existence, but it's genuinely useful when something breaks at 3 AM.
The whole backend is NestJS with Prisma, frontend is Next.js 15 with React 19. CASL handles fine-grained permissions. Everything runs in non-root containers with dropped capabilities and network policies restricting pod-to-pod traffic.
Is this overengineered for a message board? Absolutely. But I've learned more about running production infrastructure in the last few months than I did in years of reading about it.
Interesting idea. Since it costs (at the moment) less than a dollar to post a message, does that still work well with Stripe?
I'm always a bit worried about making super low priced services myself with Stripe, mainly cause I've heard that's a common target for credit card testing fraud, but interested to hear your thoughts.
Thanks! And it does actually. I basically set all messages prior to the 50 cent value being hit as free just to promote early engagement and prevent transaction failures (Stripe suggest $0.50 as a minimum). But generally speaking, their (online transaction) fees are 2.9% + $0.30 so there's solid headroom.
I've got lots of features on both the frontend and backend to prevent automated behavior that could be problematic. But ultimately nothing is stopping someone from throwing a random number into the payment modal to see if it works (though they'd still have to enter an email, zip, expiration, and CVV too).
How do you deal with two people bidding to replace the same message?
I'm most curious about your development process. This has a very strong feel of being vibe coded, which I have nothing against. And your replies here also sound heavily LLM influenced. I als have no issues with that. I am more interested to know if my instinct about these things is accurate. Has developed in this way, over engineered as you say, essentially because the cost to do so is practically nothing with the advent of LLM coding?
Heya! I'll answer each question individually, definitely let me know if you'd like any clarification though :P
TL;DR:
Concurrent bids: First payment to complete wins; everyone else gets auto-refunded and notified. Uses version checking in the database so no one pays for a post that's already been replaced.
Vibe coding: Started from a half-finished project by a dev team that ghosted. Took over and built the rest with Claude Code, but spent roughly half the time on security, performance, and privacy compliance — not just generating code.
LLM content: Uses LLMs to draft technical/promotional writing, then edits and fact-checks. Natural writing style is similar to LLM output anyway.
3AM breakages: Mostly from experimental automation tooling, nothing production-critical.
Now for the full answers:
1. Two people bidding to replace the same message:
- Simple explanation: Optimistic locking with automatic refunds.
- A bit more detail: The first payment to fully process wins. The second (third, fourth, etc.) person gets an automatic full refund and a notification explaining that someone else beat them to it. Under the hood it's a simple "check before you activate" on the actual message acceptance. When you start paying, the system notes which message is currently live. When the payment completes, it checks whether that same message is still there. If someone else already replaced it, the payment gets refunded instead of going through. Realistically, this shouldn't be happening in any normal situation as the backend is quite responsive. But if I got heavy enough traffic (specifically paid message submissions), I'd likely tune the behavior to refresh frontend values even more frequently, same with optimizing the backend to reduce latency.
- Techno-babble: When you initiate payment, the system snapshots the current post's version number and stores it in the Stripe PaymentIntent metadata. When the webhook comes back confirming payment succeeded, it does an atomic PostgreSQL UPDATE ... WHERE id = $1 AND version = $2 with an increment. If updated.count === 0, someone else already won. The payment gets automatically refunded via the Stripe API, and the user gets a real-time WebSocket notification explaining what happened ("Someone else posted while your payment was processing. Your payment has been refunded."). There's also a per-user Redis distributed lock (SETNX with TTL) to prevent the same person from double-submitting, and post numbers use a PostgreSQL sequence that's only consumed after winning the activation race, so there are no gaps in the numbering. The whole activation path is idempotent, so Stripe webhook retries are handled gracefully.
2. Vibe coding: The initial project referenced to build the site was hand-built, unfortunately by a dev team I paid who basically ghosted me halfway through. I got my money back and there's a whole story behind that but basically I got sick of waiting for their bug fixes and was spending so much time troubleshooting, I figured I may as well take full charge. Claude Code got me from there to here. But frankly, about half the time I spent building the site was spent on performance optimization, security hardening, and aligning with GDPR (and California's) privacy standards.
3. LLM influenced responses: Your instinct is fairly good on that! For more technical breakdowns and generic 'promotion' stuff, I draft with LLMs and then adjust based on my own preferences (and after fact checking where relevant). To that end, my natural writing style is a bit stiff/serious so it ends up sounding about the same. You'd be right about it being overengineered due to the low barrier to entry as well. I'm far from new to containerization, but stepping into the K8S world and configuring everything manually was outside my scope when the ends were more important than the means. Not that I don't make significant efforts to learn about the stack I'm using every day I work on it.
4. 3AM breakages: Haha.. a decent chunk, but nothing critical fortunately! Mostly various tools I've been testing out to help with automation/management of the stack. For such testing, I'll sometimes half-build out scheduled/automatic workflows without giving them the same polish I do production stuff. Had a lot of fun fighting Flux between codebase changes, automated dependency PR merges, etc.
Sorry for the wall of text by the way, I haven't received much in the way of genuine intrigue (i.e. things worth responding to in detail) and as you can tell, I'm quite passionate.
Well congratulations! You've produced the thing you wanted to make and that's awesome! And I bet you learned heaps along the way.
We're moving into a really weird time where this grade of thing you have made with its robust infrastructure is going to be absolutely everywhere. Those things won't be the differentiating factor. It will be taste, opinion, and passion.
I'll probably be a meme in ten years for this but I don't think this is the one that's going to take off and make you wealthy(er?). People's brains are too addled by strobing media, mine included, for a simplicity to hold on to them. But I do think you have shown really valuable traits in shipping this that indicate you will have success sooner or later. And you can be proud of yourself for this. Well done.
Much appreciated! It really is quite amazing how 'easy' it is to get going without what used to be multiple textbooks' worth of foundational knowledge. I will say, having reasonable technical background, that I do totally get the hate people have towards vibe-coded apps. I wish maybe they were more discerning with it over blanket-rejection but with some of what I've seen out there, many concerns are quite valid.
I too highly doubt my site will be any significant money maker but despite it being part of the core mechanic, I'm mostly just happy realizing a shower thought in a way that was previously completely unattainable haha. If nothing else, the EFF will be getting at least $17.77 at the end of the month so I can say some non-personal good came of it.
Funnily enough, I hadn't even heard of the Million Dollar Homepage until users started mentioning it! The core concept is quite similar though, I do agree :) I think where I've differed a bit is more of the focus on community involvement in message value, with a weighted pricing + (free) discussion/reaction system. A lot of great feedback I got was around the potential for some high-priced message to just kill further interaction, which is similar to what happened once all the pixels were bought up on the homepage.
It’s a cool concept, but I can’t imagine what would make me want to frequent a message board that was explicitly designed to give wealthy users more of a voice. The wealthy have enough ability to project their influence as it is. The idea is considerably too capitalistic for my taste.
I totally get that! If it helps, my logic behind it is a mix of the following: - The 'big' social media platforms already do this (give wealthy users more of a voice). It's just done in a less transparent and more manipulative way. Between ads and targeted algorithms, you get force fed content by large corporations and have your privacy invaded. - Added based on user feedback, the 'message value decay' helps avoid both the situation you mentioned and more. Regardless of whether it's a politic message or an ad from a large corporation, if people hate seeing it, its value will drop quite drastically based on their reactions. Even an expensive message will be affordable to replace if it's disliked. There's no doubt it's quite capitalistic (on the message submitter's side), but my goal was more focused on making that mechanic fair, straightforward, and respectful of users' privacy when compared to how it's usually done. Of course, I'm extremely open to ideas/feedback on how it can be improved!
Just wanted to add a small update: I've completed my research on charity donation integration and settled on donating to the EFF (Electronic Frontier Foundation)! Mocking up the frontend changes with a dedicated page that will contain quarterly reports on donations, FAQ update, etc. After some further research, settled on personally donating 25% of Say That Sh*'s revenue to the EFF every quarter <3 The standard seems to be something like 5% and that just seemed way too low?
I've realized the mechanics behind the site may not be all that interest to some (and likely disliked by many), so figured I'd share some of the technical details to give a little more 'meat' to the post.
The whole thing runs on three used Intel mini PCs (i5-10500T, 16-24GB RAM each) under my desk. k3s cluster with embedded etcd for HA. Total electricity cost is about $11/month.
Database: CloudNativePG operator manages PostgreSQL with automatic failover (5-30s). Built-in PgBouncer pooling via the Pooler CR so I don't need to manage a separate connection pooler. Continuous WAL archiving to a local Garage (Rust-based S3-compatible storage) machine gives me under 5 minutes RPO.
Cache/realtime: Redis Sentinel with 3 Redis + 3 Sentinel instances for automatic master failover. Socket.io sits on top with the Redis adapter so WebSocket connections work across multiple API replicas.
Backups are three-tier: Barman Cloud Plugin handles continuous PostgreSQL WAL + daily base backups. Restic does encrypted daily snapshots of secrets and pg_dumps. Longhorn handles volume snapshots. All three target the same Garage S3 box on my LAN. Six alerting rules monitor the entire chain — if any tier goes stale, I get a Telegram alert.
Screenshot generation was a fun one. When you post a message, the server generates a themed PNG of your message card for the email confirmation. Instead of spinning up a headless browser, I use Satori (JSX to SVG) + resvg (SVG to PNG). No Puppeteer, no Chrome, no browser at all. It renders the exact same React-like JSX with the user's theme colors and spits out a PNG in milliseconds.
The achievements system has 46 achievements across 8 categories and 6 tiers, all event-driven. When you post a message, leave a comment, or hit certain milestones, the evaluator checks eligibility and fires a WebSocket event for the toast notification. The whole thing is evaluated server-side so you can't fake progress.
Message value decay is borrowed from HN's own gravity-based ranking, actually. Values decrease over time following a configurable decay curve, and community reactions (likes/dislikes) directly influence the rate. Like a message and you slow its decay. Dislike it and it drops faster. The formula is feature-flagged so I can tune the gravity constant without a deploy.
Worker architecture: BullMQ with a dedicated worker process that runs independently from the API. Screenshots, emails, and async jobs all go through the queue. The worker can crash and restart without affecting API availability.
Monitoring is VictoriaMetrics + VictoriaLogs + Alloy + Grafana with 16 auto-provisioned dashboards. Probably the most overengineered monitoring setup for a message board in existence, but it's genuinely useful when something breaks at 3 AM.
The whole backend is NestJS with Prisma, frontend is Next.js 15 with React 19. CASL handles fine-grained permissions. Everything runs in non-root containers with dropped capabilities and network policies restricting pod-to-pod traffic.
Is this overengineered for a message board? Absolutely. But I've learned more about running production infrastructure in the last few months than I did in years of reading about it.
Interesting idea. Since it costs (at the moment) less than a dollar to post a message, does that still work well with Stripe?
I'm always a bit worried about making super low priced services myself with Stripe, mainly cause I've heard that's a common target for credit card testing fraud, but interested to hear your thoughts.
Thanks! And it does actually. I basically set all messages prior to the 50 cent value being hit as free just to promote early engagement and prevent transaction failures (Stripe suggest $0.50 as a minimum). But generally speaking, their (online transaction) fees are 2.9% + $0.30 so there's solid headroom.
I've got lots of features on both the frontend and backend to prevent automated behavior that could be problematic. But ultimately nothing is stopping someone from throwing a random number into the payment modal to see if it works (though they'd still have to enter an email, zip, expiration, and CVV too).
How do you deal with two people bidding to replace the same message?
I'm most curious about your development process. This has a very strong feel of being vibe coded, which I have nothing against. And your replies here also sound heavily LLM influenced. I als have no issues with that. I am more interested to know if my instinct about these things is accurate. Has developed in this way, over engineered as you say, essentially because the cost to do so is practically nothing with the advent of LLM coding?
Also, has anything ever broken at 3am?
Heya! I'll answer each question individually, definitely let me know if you'd like any clarification though :P
TL;DR:
Concurrent bids: First payment to complete wins; everyone else gets auto-refunded and notified. Uses version checking in the database so no one pays for a post that's already been replaced.
Vibe coding: Started from a half-finished project by a dev team that ghosted. Took over and built the rest with Claude Code, but spent roughly half the time on security, performance, and privacy compliance — not just generating code.
LLM content: Uses LLMs to draft technical/promotional writing, then edits and fact-checks. Natural writing style is similar to LLM output anyway.
3AM breakages: Mostly from experimental automation tooling, nothing production-critical.
Now for the full answers:
1. Two people bidding to replace the same message:
- Simple explanation: Optimistic locking with automatic refunds.
- A bit more detail: The first payment to fully process wins. The second (third, fourth, etc.) person gets an automatic full refund and a notification explaining that someone else beat them to it. Under the hood it's a simple "check before you activate" on the actual message acceptance. When you start paying, the system notes which message is currently live. When the payment completes, it checks whether that same message is still there. If someone else already replaced it, the payment gets refunded instead of going through. Realistically, this shouldn't be happening in any normal situation as the backend is quite responsive. But if I got heavy enough traffic (specifically paid message submissions), I'd likely tune the behavior to refresh frontend values even more frequently, same with optimizing the backend to reduce latency.
- Techno-babble: When you initiate payment, the system snapshots the current post's version number and stores it in the Stripe PaymentIntent metadata. When the webhook comes back confirming payment succeeded, it does an atomic PostgreSQL UPDATE ... WHERE id = $1 AND version = $2 with an increment. If updated.count === 0, someone else already won. The payment gets automatically refunded via the Stripe API, and the user gets a real-time WebSocket notification explaining what happened ("Someone else posted while your payment was processing. Your payment has been refunded."). There's also a per-user Redis distributed lock (SETNX with TTL) to prevent the same person from double-submitting, and post numbers use a PostgreSQL sequence that's only consumed after winning the activation race, so there are no gaps in the numbering. The whole activation path is idempotent, so Stripe webhook retries are handled gracefully.
2. Vibe coding: The initial project referenced to build the site was hand-built, unfortunately by a dev team I paid who basically ghosted me halfway through. I got my money back and there's a whole story behind that but basically I got sick of waiting for their bug fixes and was spending so much time troubleshooting, I figured I may as well take full charge. Claude Code got me from there to here. But frankly, about half the time I spent building the site was spent on performance optimization, security hardening, and aligning with GDPR (and California's) privacy standards.
3. LLM influenced responses: Your instinct is fairly good on that! For more technical breakdowns and generic 'promotion' stuff, I draft with LLMs and then adjust based on my own preferences (and after fact checking where relevant). To that end, my natural writing style is a bit stiff/serious so it ends up sounding about the same. You'd be right about it being overengineered due to the low barrier to entry as well. I'm far from new to containerization, but stepping into the K8S world and configuring everything manually was outside my scope when the ends were more important than the means. Not that I don't make significant efforts to learn about the stack I'm using every day I work on it.
4. 3AM breakages: Haha.. a decent chunk, but nothing critical fortunately! Mostly various tools I've been testing out to help with automation/management of the stack. For such testing, I'll sometimes half-build out scheduled/automatic workflows without giving them the same polish I do production stuff. Had a lot of fun fighting Flux between codebase changes, automated dependency PR merges, etc.
Sorry for the wall of text by the way, I haven't received much in the way of genuine intrigue (i.e. things worth responding to in detail) and as you can tell, I'm quite passionate.
Well congratulations! You've produced the thing you wanted to make and that's awesome! And I bet you learned heaps along the way.
We're moving into a really weird time where this grade of thing you have made with its robust infrastructure is going to be absolutely everywhere. Those things won't be the differentiating factor. It will be taste, opinion, and passion.
I'll probably be a meme in ten years for this but I don't think this is the one that's going to take off and make you wealthy(er?). People's brains are too addled by strobing media, mine included, for a simplicity to hold on to them. But I do think you have shown really valuable traits in shipping this that indicate you will have success sooner or later. And you can be proud of yourself for this. Well done.
Much appreciated! It really is quite amazing how 'easy' it is to get going without what used to be multiple textbooks' worth of foundational knowledge. I will say, having reasonable technical background, that I do totally get the hate people have towards vibe-coded apps. I wish maybe they were more discerning with it over blanket-rejection but with some of what I've seen out there, many concerns are quite valid.
I too highly doubt my site will be any significant money maker but despite it being part of the core mechanic, I'm mostly just happy realizing a shower thought in a way that was previously completely unattainable haha. If nothing else, the EFF will be getting at least $17.77 at the end of the month so I can say some non-personal good came of it.
Thanks again and hope you have a wonderful week!
Reminds me of https://milliondollarhomepage.com/ (which is where I assume you got the inspiration from!)
Funnily enough, I hadn't even heard of the Million Dollar Homepage until users started mentioning it! The core concept is quite similar though, I do agree :) I think where I've differed a bit is more of the focus on community involvement in message value, with a weighted pricing + (free) discussion/reaction system. A lot of great feedback I got was around the potential for some high-priced message to just kill further interaction, which is similar to what happened once all the pixels were bought up on the homepage.
Oh this has the same spirit as that Washington Redskins episode on South Park. I'm lovin' it.
I’ll take that as a compliment and thank you haha, it was definitely made with spite for traditional social media ;)