Building in Public

One of the most complete build-in-public threads in the archive. An experienced professional ("Hashversion") worked through positioning, scope, and infra choices live with expert-led feedback - a good template for how early-stage scoping conversations can go:

The problem: planning to launch multiple websites and not wanting to build a bespoke sponsorship/ad system for each one - wanted a universal, self-serve platform where website owners create and sell direct ad/sponsorship placements (banners, sidebars, sponsored newsletter slots), advertisers pay via recurring Stripe subscriptions, and the platform automates billing and takes a cut, without owners having to manually invoice.

Initial design (v0): a marketplace-style model, initially scoped across Astro (landing page) + Next.js (dashboard) + Hono (API).

1. Marketplace models are extremely hard to bootstrap from zero because you must solve supply and demand simultaneously. Recommendation: pick one specific, narrow niche first where you can realistically seed both sides quickly (e.g., only targeting devtool companies as advertisers - CodeRabbit, PostHog, etc. - against devtool-focused publisher sites) rather than going broad immediately.
2. Differentiate clearly from mature incumbents (Google AdSense, Meta Ads) - these have deep targeting/SDK moats built over years; a new entrant needs a genuinely different angle, not a stripped-down clone.
3. Narrow scope aggressively before designing the system. The original design was missing real answers on targeting mechanics and privacy/compliance (especially EU-relevant if targeting is in scope at all).
4. Recommended MVP process: get really clear and narrow on scope first (including explicitly deciding what's out of scope, like targeting/compliance if you're avoiding it for v1), write a clear requirements list including initial scale assumptions, then design.

How the founder actually responded/pivoted: narrowed to a clear single-sentence positioning - "minimal.ad helps developer-focused websites sell direct sponsorship placements with recurring billing" - and explicitly dropped the marketplace/discovery model for v1, reframing it as white-label sponsorship infrastructure for individual websites rather than a centralized marketplace. This was validated as the right call; the industry reference point given for "when a thin, hyper-targeted marketplace-like play can work" was TrustMRR (trustmrr.com, associated with indie maker Marc Lou), though even that was framed as "still tough."

• Interesting secondary point: because the product moved away from being a marketplace, the founder reasoned (and the industry agreed) that the audience-targeting strategy could reasonably go broad again, since the narrow-niche constraint was specifically about solving the two-sided marketplace cold-start problem, not a permanent constraint.

Infra/stack decisions and the reasoning behind them (a good real-world example of picking early infra):

• Stack: Neon (Postgres), Vercel (Astro landing page + Next.js dashboard), Cloudflare Workers (Hono API), Cloudflare R2 (object storage, chosen specifically to avoid egress fees).
• Guidance given: this stack is "manageable" for validating the idea, but plan to move off Vercel long-term since it gets expensive at scale. (Context shared: Vercel itself is built on AWS, which is part of why costs compound.)
• When asked where to move to after Vercel: the recommendation was consolidate onto Cloudflare if the rest of the stack (R2, CDN, image optimization) is already there, rather than introducing a third provider - with a specific migration guide linked (developers.cloudflare.com/pages/migrations/migrating-from-vercel/). Note: Cloudflare Pages has since merged into Cloudflare Workers.
• The main ongoing cost risk flagged for Vercel, once queues/cron/analytics/image-optimization are already offloaded elsewhere, is build minutes - described as easy to monitor and manage, especially as a solo developer.
• Deployment tooling used: GitHub Actions + Blacksmith (a faster/cheaper GitHub Actions runner alternative) for CI/CD, run by a single solo developer.

A different experienced professionals was running their entire personal project on Cloudflare Workers + R2 + Durable Objects + Email Bindings + KV, at roughly €5/month, and considered migrating to Kubernetes on a major cloud provider (jumping cost to roughly €70-100/month) purely to gain "real" K8s deployment experience ahead of an internship.

• the field verdict: not worth it for that specific goal. The suggested lower-cost alternative for gaining hands-on Kubernetes experience without a real production migration was minikube (a local, single-node K8s environment for learning/testing) - get the skill without paying for or maintaining a production-grade cluster you don't actually need.

• vazen.dev - a production-grade project starter kit, later featured in the orpc.dev ecosystem's list of starter kits. Feedback given: solid tech stack overall, but the landing page and README could use more polish - a reminder that technical quality and packaging/presentation quality are evaluated somewhat independently by outside reviewers.
• tokenspend.dev - a tool to calculate ROI on AI spend, shared for feedback with a launch promo code.
• Quant Force - a hackathon project: a platform where contestants upload a trading-engine Docker image, the platform spins it up in an isolated container, bombards it with a bot fleet, and produces a live leaderboard based on latency/throughput/correctness. Infra questions the builder worked through in public: container orchestration approach (leaning Kubernetes via Google Kubernetes Engine, citing feature breadth), Kubernetes namespaces for isolating contestant workloads. The finished project (including a PDF design doc and a demo video) was praised specifically for pairing a written design doc with a demo video - called out as a smart, differentiating way to prove genuine understanding of what was built, not just that it works. The project ultimately placed 3rd in its hackathon (only 1st place received an internship offer); the practical follow-up advice given was to reach out to recruiters and apply for an internship anyway, rather than assuming a non-first-place finish closes that door.
• WorkWire (workwire.com) - a pre-beta startup mentioned by an experienced professional, targeting a closed beta launch (~200 users) plus an angel round, alongside their own system-design upskilling via the app.