The homepage: a masonry grid of community-submitted questions paired with curated photography

nicequestions.com is a community-driven site where anyone can submit a thoughtful question. Each question gets paired with a photograph and displayed in a browsable masonry grid. Questions are organized into categories like “For Crossroads,” “For Loved Ones,” “Making Friends,” “Big Questions,” “For A Gathering,” and “Meet Yourself.”

I built it over a weekend in January 2026 using Next.js, Firebase, and a couple of external APIs.

The LLM Gate

The core moderation challenge: how do you let anyone submit a question while keeping the quality bar high, without manual review?

The answer is an LLM gate. Every submission gets sent to OpenAI’s GPT-4o-mini before it touches the database. The model checks whether the submission is actually a question (rejecting statements, commands, and gibberish), screens for harmful content, and filters spam. It’s deliberately permissive—the goal is to keep the door open for creative and unexpected questions while catching the obvious junk.

When a question passes, the model also cleans up grammar and punctuation and assigns it to one of the six categories. The whole validation, cleanup, and categorization happens in a single API call with structured JSON output at a low temperature for consistency.

Where the Images Come From

Each accepted question gets paired with a random photograph pulled from a curated Unsplash collection of film-style photography (2300+ photos). The images aren’t hotlinked—they’re downloaded as buffers and uploaded to Firebase Storage. This means the site doesn’t depend on Unsplash’s CDN at runtime, and the images persist even if the original Unsplash photos are removed.

The app also tracks each photo’s Unsplash ID in the database to prevent the same image from appearing twice.

The Database

There’s no traditional database here—everything lives in Firestore. Each question is a document with the question text, its assigned category, the Firebase Storage image URL, the Unsplash photo ID, and a timestamp. A separate config document tracks daily submission limits (200 attempts and 200 accepted questions per day) as a simple abuse prevention measure.

Stack

• Next.js (App Router) on Vercel
• Firebase (Firestore + Storage)
• OpenAI GPT-4o-mini for question validation
• Unsplash API for sourcing images
• Tailwind CSS for styling

The whole thing is anonymous—no user accounts, no authentication. Just a text box, an AI gatekeeper, and a growing collection of questions worth asking.

Building with OpenClaw

During this project I was trying out OpenClaw, and it was quite amazing to use the app on my phone and send text messages to have the app debugged.

This post exists because I’m trying to follow that advice myself. I often consume a lot of content like this.

If you’re reading this, you probably do too. So think about whether creating a bit more and consuming a bit less might bring things into better balance.

I’ve come to see notes as useful only when they lead to action. I used to enjoy capturing thoughts and storing them in notebooks or apps, but now I avoid that.

In practice, this means keeping a small “queue” of notes—on paper or digitally—that each support some action. It forces me to either do something with them or remove them.

What’s the real value in tracing an idea’s lineage? It feels secondary to the idea itself. Context is like explaining the history of a technology when people mostly care about the technology. Those who want the background are engaging at a different layer.

If readers are anything like me, they prefer fewer links. Articles overloaded with them often point to pages whose main substance is already expressed by the surrounding sentence.

I’ve long felt pulled toward some grand system for storing ideas. Some people capture excerpts obsessively; that makes sense if you care about catalogs of words, but if you care about ideas, excerpts lose too much. I think I’ve settled on this: if an idea is worth keeping, it’s worth re-wrapping in your own form. Make the idea your own.

I set this up using this very convenient guide. To see the Github repo for this blog, visit https://github.com/nathankoerschner/nathankoerschner.github.io/

View on GitHub

Support

If you need support, please contact me via email.

Privacy policy: No data of any kind is collected, shared, or stored.

Left to right: Matt Mohorn (CTO), Chris Mauzé (Founder & CEO), myself, and Amer Tadmori (COO)

When I joined Red Fox Analytics in 2022, the company had just crossed $1M in revenue, but the data infrastructure behind the product was held together with duct tape. The same logical pipelines existed in multiple places across GUI-based tools like Alteryx, Talend, and Tableau Prep, with no single source of truth and no scalable way to make changes. My job was to consolidate everything into code without breaking anything for live clients.

The catch: I had almost no SQL experience and zero exposure to dbt, the framework we’d chosen for the transformation layer. So before I could rebuild anything, I had to teach myself—learning SQL and dbt in real time while simultaneously keeping the existing pipelines running for clients who couldn’t afford a single day of broken data.

That meant every day was a balancing act: maintaining and debugging the legacy GUI workflows to keep reports flowing on time, while carving out space to design the system that would replace them.

Owning the Full ELT Stack

As I dug into the problem, I realized that rebuilding the transformation layer alone wouldn’t be enough. The fragmentation ran through every stage of the pipeline, and to actually fix this, I’d need to own the full ELT stack.

Extract: Extraction was handled by an offshore team pulling data from manual portals. I trained them on standardized workflows using bash scripts to invoke pipelines consistently.

Load: I built a Python-based ingestion engine driven by JSON spec files, where each pipeline had its own configuration that defined how files were validated, parsed, and loaded.

Transform: I designed a multi-tenant dbt architecture that served all clients from a single codebase, and wrote custom dbt macros encoding the business analytical logic specific to our CPG clients—sales velocity metrics, time period aggregation calculations, and inventory management metrics that had previously lived as scattered, manual calculations across the GUI tools.

Scaling Without Additional Engineering Hires

I built the platform to handle per-tenant customizations, so each client could tailor their data models to their specific needs without forking the shared codebase. A key part of this architecture was designing the customization layer to be accessible to non-engineers. I trained the nontechnical team in basic SQL so they could create and update atomic merchant customizations themselves, removing me as a bottleneck and scaling the team’s capacity without additional engineering hires.

I paired this with a custom orchestration layer on Google Cloud and managed the data warehouse migration from Snowflake to BigQuery as part of the broader overhaul.

Results

We eliminated reliance on Alteryx, Talend, and Tableau Prep, and reduced pipeline changes from hours of manual cross-tool work to a single code commit.

Once the core infrastructure was stable, I helped the CEO evaluate and select a CTO, then partnered with him to build the application layer that surfaced this data through an embedded BI tool for clients.

Acquisition

In March 2024, Daasity Inc. acquired Red Fox Analytics, specifically to integrate the retail CPG data infrastructure and analytical logic I’d helped build into their broader platform.

View on GitHub

View on GitHub

View on GitHub