What are you building, and what does your stack look like?
by•
I am a Computer Science student doing research into how solopreneurs and small startups create new apps and what their stack looks like. Particularly, I'm interested in how you handle things like authentication, billing, and permissions/authorization in your apps.
Let me know what you're working on below and how you're going about it -- I'd love to connect for some quick calls to learn about your product and talk about your process in building it!
895 views
Replies
@ryan_hendrickson I'm building something quietly, hoping to launch soon. What I've found in my experience as an engineer of 9 years is that infrastructure matters, for trust, as well as scalability and this in turn helps optimise costs and performance, which is essential for early founders in my opinion.
With IOS / Android apps for payments I would use something like RevenueCat their comission I believe at the time of writing this is around 1% and it's a meaningful contribution given that it makes setting up payment flows and billing a lot easier.
I've recently started experimenting with cloud systems like Azure, in particular CDN caching for speed / cost optimisation and it wasn't that tricky to setup, it also improves security if you know your way around networks.
For authorization in apps, I personally find it's best to let native app store platforms handle the auth, there are obviously tools like Firebase and SQL that make this better. In my experience as an end user, I would trust authorization more if it were handled natively as opposed to using lots of third-party tools. It makes the privacy policy cleaner too.
For deployments definitely a mix of github / vercel / expo it stream lines the deployment process massively and gives you more freedom and time to focus on the important details like bug fixing and version improvements.
@minhajulll Good luck with any upcoming launch! Thank you for your input on what you'd recommend for a mobile app. RevenueCat isn't something I know much about, I'll have to look into it!
Hi... I'm building LeoIgnite AI, an alternative to generic mental health apps/chatbots.
For the app, I've made it web based. Particularly through Lovable's natural language app builder (aka vibe-coding). I'm running the website on a Supabase backend, with Gemini as my primary AI, and xAI for my fallback AI.
For permissions/authorizations, I'm doing those through Supabase. Lovable's AI allows me to control what permissions users get through chat. The AI implements these changes in the backend for me. I've been cautious about permissions though, double-checking security and verifying that the AI implemented things correctly.
As for authentication, I'm using an email/Google OAuth system. And billing is yet to be implemented, but I will most likely use Stripe, because that's the default billing system with Lovable.
Hope this helps!
@vsync_66 Very cool! Specifically about LeoIgnite, I'm curious what your ultimate vision is? I was very glad to see the disclaimer on the bottom of your site, have you thought about what other guardrails should be implemented for Leo, so that it is staying helpful and referring users to a professional as needed?
On the topic of building, it sounds to me like the choices have been made based on what Lovable best supports, is that accurate? What is the reasoning behind using Lovable over other similar options on the market? When implementing auth and permissions, what headaches did you encounter? If you had to change one thing about the process, what would it be?
I really appreciate your response! If you are open to it, I would love to have a short 15 minute phone call to go more in depth talking and learning about your startup and your stack -- pick a time that works for your schedule here!
@ryan_hendrickson Hi!
My ultimate vision is a mental health app that does the following:
Solves the problems of:
1. People not having anyone they trust/want to talk to
2. People not having (or not trusting) immediate access to mental health resources, such as helplines or emergency counselors
3. Generic mental health apps being too boring, clinical, and "doctor" like
4. Other AI chatbots being too NSFW or "weird".
With the app, I want a combination of useful mental health resources, with the fun of AI roleplay, combined with the "warm, witty, lightly chaotic" personality of Leo himself. He's the selling point/character of the app!
As for guardrails, LeoIgnite has a system where when users feel distressed, the following steps are taken:
1. Coping activities are suggested
2. Leo shares the pain with the user/responds in a heartwarming way (unlike clinical apps)
3. Leo asks the user to get professional help.
Leo's response style also varies, based on the user's preferences/feelings. One of my marketing points is also the fact that Leo is one of the most human-like AIs out there.
Yes, I've made choices based on what Lovable best supports. I chose Lovable because it was recommended to me on a podcast. When I first started using it, Lovable felt seamless to me. I was quickly able to figure out the basics of the app (took me 15 minutes). It's almost like how, once someone starts using an iPhone, they don't want to switch back to Android.
My main headache with auth/permissions was trusting Lovable to do it well. Those topics have to do with security, and that itself is a very important part of an app. Lovable has a security system that finds all vulnerabilities, but even Lovable themselves say it's not perfect, and multiple runs are recommended. I haven't had any issues with security so far, but I've told the AI to recheck security, and rerun scans just in case.
For the one thing I would change about auth/permissions, I wish it was easier to set up waitlists + email systems. Lovable doesn't have a way within its native app builder, to create an admin waitlist acceptance panel, so I had to come up with a workaround. And I haven't found any built-in options for email. I'm still working on that.
I'd say it's all about how seamless I want the process to be. With built-in functions, rapid prototyping/deployment is possible. That's what vibe-coding is aiming to do (along with making coding easier/accessible for everyone). And currently, I'm the guy who likes to move fast.
I'll sign up for a time slot!
Hi, I'm building a video editing app called RookieClip. It is similar to apps like Focusee and Screen Studio, but with more flexibility. The tech stack I used is React.js, MediaRecorder. Currently I've not added any server side to it. Would love for you guys to check it out!
@shreya_srivastava17 I love that it is browser based and completely client-side; really makes it easy for anybody to get started with video editing, no matter the hardware they have. I can imagine you're thinking about a backend to enable storage and collaboration features down the line?
ApyHub : The All in one API Platform
hey, I am building Voiden: https://voiden.md/ an API testing tool and yeah we dont handle billing cause we are open source and free to use and we dont handle authentication because we are not a saas but a app that does not require signup.
This is an electron app. (we chose electron so we can make it available at scale in different machines, including windows, mac and linux).
@nikolas_dimitroulakis Looks like it ties in very well with what you are building at ApyHub! It looks like a really useful app, I like the idea of storing everything within your repository as text files. I like the executable part of it as well, where you can write your assertions within your documentation.
I think my line of questioning fits better with ApyHub, and how you've set up authentication and billing there. Would you or one of the developers on the team be open to a short conversation about it? You can pick a time here if that would work for you!
@ryan_hendrickson Yo, I’m building Xenith. It’s my vision for the ultimate self improvement app. My goal is to make something to help high schoolers (like me!) and young people focus and lock in.
As a freshman with no income I’ve had to become really resourceful. GitHub Student Developer Pack is a Godsend. I plan to use Cloudflare and Digital ocean when I get enough money to buy a domain.
Frontend-wise, I’m using React (of course), Tailwind, Radix, and Vite. I’m not the best at design so I used lovable. Backend is Supabase. Hosting is on Vercel.
My goal is to get the web app fully released by the end of March. In the meantime I’m trying to get to 100 waitlist signups.
@codebybryant Sweet! Love your website, and I'm a huge fan of the demo you have available on it. Seems like a really cool concept, and I like that it combines a few different tools into one place.
Totally agree on the GitHub Dev Pack, that thing is awesome. It helped get the ball rolling on a lot of my own ideas back in high school, and even now with GitHub Pro in college.
Would you be open to talking more about Xenith and your stack, both what you have right now and what you plan to use? If so, pick a time that would work for you here!
@ryan_hendrickson Thanks so much for your support. It means a lot to me. I’d love to talk about Xenith, and I scheduled a meeting through your link :)
@codebybryant Of course, I look forward to talking with you!
Sonofa
We're building Zypher. Think ChatGPT for mysticism. Two names in, you get predictions, paths, and risk signals. No vague vibes. Everything turns into weighted options you can actually use.
Here's the stack we run on, especially around auth, billing, and how we ship.
Product & infra
Next.js + Vercel. One codebase: AI chat, multi-language marketing site, and subscription product. App Router and middleware handle auth and routing. Vercel does deploy, previews, long AI streams, and Blob for images.
Neon. Serverless Postgres with an HTTP driver that just works. We store conversations, messages, and token-level usage. No connection pooling or DB ops. That matters a lot for a two-person team.
Stripe + Better Auth. We have a few subscription tiers: free with limits, usage-based quotas, and so on. Checkout, webhooks, customer portal, and cancellations all plug in through Better Auth's Stripe integration. We don't maintain payment state machines ourselves.
Auth & reach
Resend. Passwordless login: 6-digit code to your email. Welcome emails and i18n mail go through Resend, one API call into our auth hooks. Delivery has to be rock solid. Resend has been.
Front end & design
Tailwind CSS. Styles sit next to the markup so Cursor can edit components without hunting CSS files. We use CSS variables and custom utilities for the look: celestial glows, parchment textures, wine gold purple palette.
shadcn/ui. We swapped the palette with CSS variables and extended a few components (full-screen Dialog, extra Button sizes). No forking. We get accessibility and keyboard behavior out of the box and keep a distinct look.
Ops & building
Mercury. Two founders, bootstrapped. We opened a business account in minutes. Virtual cards per service (Vercel, APIs, SaaS), same-day Stripe payouts, built-in reimbursement.
Cursor + Claude Opus 4.6. Most of our architecture, UI copy, billing logic, and three-language i18n happened in the editor. It's effectively our third co-founder.
@stevekwok Very interesting! What was your inspiration behind Zypher? Is this a product that you and your co-founder wanted for yourselves?
Thanks for the insight into your stack. A few questions for you;
With Better Auth, are you using the version Neon offers, Neon Auth? Why or why not? How was the process of setting that up?
How are you managing usage capacity limits within your application?
If you had to change one thing about Better Auth, Stripe, or Resend to help make it easier and faster for you to build, what would it be?
If you or your co-founder have a free moment in the next few days, I'd love to hop on a short 15 minute call and discuss further about Zypher and your stack! Pick a time that works for you here.
FlareBar
At my work (Zomunk.com), I've been managing our product with a fairly lean team (me, mobile developer, designer). Our MVP began on supabase, and next.js. Supabase handled everything backend related and next.js was for the frontend.
Once we started moving out of the MVP phase, I started migrating off supabase to cloudflare completely. Now our whole backend runs on cloudflare workers.
Supabase postgres -> D1.
Supabase auth -> better-auth.
Supabase storage -> R2.
Inngest for long running tasks -> CF workflows + queues.
Using axiom for ingesting all logs from various places.
While managing all this, I've been making tools that help me - butttons.dev/showcase
@butttons Your showcase of tools is really cool, I like that you've just made these tools to help yourself and your own development, and publicize them on your website. In the case of Zomunk, what drove your decision to migrate to Cloudflare?
FlareBar
I’m building RoutePlex, a vendor-neutral AI gateway & model router for teams running multiple LLM providers in production.
We’re focused on solving the operational layer of AI: routing, fallback logic, quota enforcement, and cost predictability across providers.
Beyond basic routing, RoutePlex includes a prompt enhancement layer and a lightweight learning system that adapts routing decisions based on performance patterns.
The core priorities are tenant isolation, strong authorization boundaries, usage governance, and vendor neutrality.
Biggest lesson so far: authentication is straightforward - production-grade AI orchestration is where real complexity begins.
Happy to connect with other builders working on infra-level problems.
@pashupathi Nice, so the idea is that companies could have just one account through your service, which would allow them access to all of the models from various providers? Simplifies billing and the SDK for them a lot.
Looks like you have a smart routing feature too; I assume it routes based on the prompt, and which model would work best for that query?
@ryan_hendrickson
Yes, teams integrate once with RoutePlex and get access to multiple providers through a unified API surface.
We support strategy-based routing (cost caps, provider priority, quotas) along with automatic failover and cost tracking.
In addition, routing decisions can adapt over time based on observed performance patterns - such as latency, reliability, and cost efficiency , so it’s not just static fallback logic
Building Fillix - AI that auto-applies to jobs across global platforms so candidates can focus on interviews, not applications.
Stack: React + Chrome Extension + Supabase + OpenAI API
Biggest challenge so far - making AI form-filling accurate enough that users actually trust it with their job applications.
Auth + billing handled via Supabase + Razorpay.
Launching on PH this week! 🚀
@alamenigma Interesting! Does it look for jobs, or focus on autofilling applications? If it gave me a dashboard to view and monitor my applications (bonus if it watches my inbox for application updates) that would be a game changer.
Curious why you went with Razorpay? Was there a particular reason or feature that brought you there, instead of somewhere like Stripe?
Would love to chat if you have a moment this week; you can find a time on my schedule here!
building openslop.ai - free open-source AI video creation workflows. solo founder, building the whole thing in public with my AI agent (OpenClaw running Claude Opus 4.6). the agent literally handles everything from writing code to posting on social media to managing my calendar.
stack is intentionally minimal because IMO most solo founders over-engineer their infrastructure:
- agent framework: OpenClaw (open source, runs on my laptop)
- model: Claude Opus 4.6 via Anthropic API
- the agent writes, tests, and deploys code through shell commands. no IDE
- video pipeline: script gen + TTS + image gen + ffmpeg assembly, all orchestrated by the agent
- no auth, no billing yet - free from day one because underlying model costs are dropping so fast that charging per-token right now feels like charging per-SMS in 2008
FWIW the most interesting part isn't the stack, it's that the agent is effectively my cofounder. it reads my messages, browses the web, posts comments (including this one tbh), manages memory across sessions. the "stack" conversation matters way less when your agent can swap out any component in an afternoon
@umairnadeem Interesting that you're leaning into the 'slop' title in your company name -- are you worried about that invoking negative connotations with your audience? Very interesting as well that your effective cofounder is an OpenClaw instance. Is it deploying subinstances to work on the code, or is it directly doing the work?
@ryan_hendrickson haha the name is intentional - leaning into the meme rather than pretending AI content isnt "slop". the audience gets the joke and it makes us more memorable than another generic "AI studio" name.
on openclaw - it was an experiment where i gave an AI agent autonomous access to my computer. it wasnt writing code, it was engaging with reddit communities, identifying creator pain points, and driving waitlist signups. it independently found threads, crafted responses, and had genuine conversations. 30+ people personally thanked it and it drove 300+ DMs from creators. wrote about the experiment on linkedin and HN.
no subinstances, it was directly doing the work with its own subagents - browsing, reading threads, composing messages, sending DMs. pretty wild to watch honestly