Issue 015
Jun 18, 2025 · 12 minute read
Here’s the thing about being an indie hacker: the ideas never stop. You’re deep into building one cool app, solving a real problem, and then BAM! Another idea hits you like a ton of bricks. A truly brilliant one, you think. And suddenly, you're juggling a handful of half-finished projects, each vying for your attention. It's a snowball effect, and if you're not careful, you end up building nothing at all. The constant influx of inspiration, while exciting, becomes a bottleneck. You’ve got one app that's your primary focus, getting all the deep, loving development, but then there are two, three, maybe even five more concepts buzzing in the back of your mind. Each of them has potential, each feels like a winner, but how do you know which to pursue without sacrificing momentum on your current project?
That's precisely why I've painstakingly refined a process to bootstrap new SaaS products, from a raw, fleeting idea to a functional waitlist and a live deployment, all within the span of about two hours. The core objective? Rapid signal validation. I need to quickly discern if an idea has real legs, if there's genuine market demand, before I commit precious weeks or months of intensive development time. This workflow allows me to keep my main project on track while simultaneously throwing a new concept out into the world, gathering interest through a lean waitlist and a few strategically placed tweets. It's about maximizing validation while minimizing investment.
So, how do I go from a shower thought to a live landing page with a waitlist in such an absurdly short timeframe? Let's dive deep into the trenches.
The very first, and arguably most critical, step in this rapid validation process is to subject the raw idea to immediate, brutal scrutiny. I don't just idly think about it, letting it marinate in my own echo chamber; I take it straight to my hyper-critical AI business partners: ChatGPT and Gemini. The secret to this step's effectiveness lies entirely in the prompt. I specifically instruct them to be harsh, to be critical, and most importantly, to act like seasoned venture capitalists or shrewd business partners. I lay out my raw, unfiltered idea – the problem it solves, the proposed solution, the target audience, initial thoughts on monetization, and any perceived competitive advantages.
They then fire back with an onslaught of piercing questions, potential pitfalls, market sizing challenges, unforeseen competitive landscapes, and hard truths about revenue model viability. It’s an incredibly efficient, unbiased way to poke every conceivable hole in an idea, forcing me to confront its weaknesses and refine its core value proposition. This initial sparring match often leads to significant pivots or even outright abandonment of an idea before a single line of code is written. It saves countless hours of wasted effort.
Once we've battled through the initial barrage, and I feel a refined version of the idea has a legitimate fighting chance, I leverage ChatGPT's prowess to churn out a comprehensive Product Requirements Document (PRD). This isn't some flimsy, bullet-point outline; it's a detailed, structured document that includes well-defined user stories, high-level technical requirements, a prioritized list of minimum viable features, and even a speculative roadmap for future iterations. This AI-generated PRD becomes the indisputable north star for the entire project, ensuring clarity and alignment even in this hyper-fast development sprint.
With a solid PRD in hand, the next challenge is maintaining absolute focus and ensuring that every single line of code I write aligns perfectly with the defined vision. This is where Cursor becomes an indispensable part of my workflow. I take that newly minted, comprehensive PRD and literally plug it directly into Cursor, setting it up as a "Cursor Rule."
What does this mean in practice? It means that as I'm writing code, interacting with the AI in Cursor, or even just navigating my codebase, Cursor always has the full context of the project's requirements, user stories, and technical specifications. It's like having an incredibly knowledgeable, omniscient pair programmer who not only understands the syntax but also the why behind every feature and every architectural decision. This constant contextual awareness keeps me honest, prevents scope creep (a solo founder's bane!), and allows me to generate highly relevant code suggestions and refactorings that adhere precisely to the PRD. It significantly boosts my coding efficiency and ensures I'm building exactly what's needed for the validation step.
Here's where the rubber truly meets the road, and honestly, this is the indisputable secret sauce for my rapid prototyping capabilities: Elixir, Phoenix, and especially LiveView. When people ask if I could achieve similar speeds with other stacks, like Next.js, my answer is always nuanced. Yes, Next.js is undeniably fantastic for spinning up projects quickly; its robust framework, massive ecosystem of well-maintained libraries, and incredible UI toolkits like shadcn/ui
make front-end development a dream. I genuinely wish Elixir had something as robust and instantly usable for componentry; it's exactly what I initially envisioned Bloom UI to be, before I quickly realised the monumental effort involved in building a truly comprehensive UI library. And let’s not even get started on the sheer elegance and developer experience of Supabase; sometimes, I admit, I do fantasize about pairing it with Next.js for certain data-heavy projects.
But despite all these compelling advantages, for a solo founder striving to validate ideas at lightning speed with minimal overhead, Elixir and Phoenix remain superior. Why? The reasons are multifaceted and deeply rooted in the architecture of the BEAM:
mix phx.gen.auth
gives you a fully functional, Postgres-backed, bcrypt-hashed, session-storing, and highly customizable authentication system in literally seconds. It's, without a doubt, the fastest way to add secure authentication to a web application I’ve ever encountered in any development stack. This immediately frees up enormous amounts of time that would otherwise be spent on boilerplate, allowing me to focus directly on the unique value proposition of the new idea.Now, armed with the power of Phoenix and a clear PRD, one of the absolute first things that PRD almost always defines is a simple landing page with a clear call to action: a waitlist signup. This is precisely where Bloom, my very own open-source component library for Phoenix LiveView, becomes a massive accelerant.
Bloom allows me to literally spin up a fully functional, database-backed landing page with a waitlist form in about 10 seconds flat. It's pre-styled with Tailwind CSS, ready to integrate seamlessly with a new Phoenix project. This isn't just about aesthetics; it bypasses hours, if not days, of fiddling with front-end components, form handling, and critical database migrations just to get a basic signup form working reliably. It's a mix bloom.landing_page
command and a quick mix ecto.migrate
away from having a user-facing way to capture interest. This immediate presence is crucial for market validation.
Once that waitlist is live, the single most important question is: is anyone actually interested? I need immediate, quantifiable feedback to understand if the idea has any legs whatsoever. This is where Logsnag, an incredibly simple yet powerful event tracking tool, combined with my own slim Elixir client, logsnag_ex
(which, of course, you can find on my GitHub!), becomes an absolutely indispensable part of my validation toolkit.
Every single new waitlist signup, every key event within the embryonic application, or even just someone clicking a specific button on the landing page, triggers a notification that gets sent straight to my phone via the Logsnag iOS app. If my phone starts buzzing persistently, delivering a steady stream of "New Waitlist Signup!" notifications, I know I've genuinely hit on something. That tangible, real-time signal is the strongest indicator that the app is worth investing more time into. Conversely, if my phone remains stubbornly silent, or the notifications are few and far between, it's a clear, swift signal to step back, re-evaluate, or simply move on to the next idea, without having sunk significant emotional or developmental cost. This immediate, clear-cut signal validation is the bedrock of my rapid prototyping strategy.
For a deeper dive into user behavior once the application starts to take shape, I leverage Phoenix's built-in analytics capabilities. For more advanced introspection and granular event tracking, I also consider integrating something like Tidewave. Knowing what users are doing, how they're interacting with the early features, and where they might be getting stuck is absolutely vital for making informed decisions on where to iterate next.
Database setup can quickly become a significant time sink and a financial drain, especially when you're just validating an idea. Services like Fly.io offer managed Postgres, which is great, but it adds to the cost. For these quick validation projects, keeping initial overhead to an absolute minimum is paramount. That's why I've wholeheartedly embraced Neon.tech's generous free tier.
Neon.tech provides a fully managed PostgreSQL database, which is crucial for offloading operational burden. Their free tier is surprisingly robust, offering ample storage and compute hours, along with incredibly powerful features like database branching. This means I can spin up multiple "branches" of my database for different experiments or features without incurring additional storage costs. It's a game-changer for rapid iteration and experimentation. It ensures I have a robust, scalable, and fully managed database solution from day one, without worrying about self-hosting a database, provisioning servers, or facing unexpected bills for an idea that might not even pan out. It’s all about frictionless data persistence.
Finally, getting the application out into the wild, accessible to potential users, is the ultimate test. Fly.io is my absolute go-to platform for Elixir deployments, and for good reason. Seriously, the process is ludicrously fast and straightforward. A simple fly launch
to initialize the project and then fly deploy
is usually all it takes to get a new Phoenix application live on the internet.
The Elixir buildpack on Fly.io is incredibly optimized, meaning my application goes from local development to a globally accessible URL in about a minute, sometimes even less. This blisteringly fast deployment cycle is critical for rapid iteration and getting real-world feedback. There's no complex CI/CD pipeline to set up initially, no convoluted infrastructure to provision. It's a direct, almost instantaneous path from my development machine to a live server.
This blisteringly fast deployment cycle means I can iterate quickly and get feedback in real-time, which is essential for rapid validation.So there you have it. From a raw, unrefined idea battling it out with AI partners, to a fully functional, deployed SaaS product with a waitlist, all within a couple of hours. It's a lean, mean, idea-validating machine that leverages the strengths of AI, modern developer tools, and the unparalleled productivity of Elixir and Phoenix. This workflow lets me pursue those fleeting inspirations without derailing my main build. If an idea truly sparks, I've got a head start; if it fizzles, I haven't lost much more than the time it takes to enjoy a strong coffee and listen to a good podcast. Now, if you'll excuse me, my phone just buzzed...
I hope you found this post useful, subscribe to my Substack below for similar content and follow me on Twitter and Bluesky for more Elixir (and general programming) tips.
If you're building a Phoenix project, I'd also encourage you to take a look at my open-source component library Bloom to help you out even further or check out my new voice to notes application to automatically tag and sync your voice to your calendar, my Slack decision capture product - Decided and my new favourite way of interacting with LLMs - Promptly.
Want to learn and master LiveView?
Check out the book I'm writing
The Phoenix LiveView Cookbook