February 4, 2026
February 4, 2026
February 4, 2026
The No-Code Stack We Use to Build Production Apps
People ask me what tools I use to build apps without a traditional engineering team. Usually they're expecting a simple answer — one platform, maybe two. The reality is that building a production app with no-code isn't about one tool. It's about assembling the right combination of tools that each do one thing well and connect cleanly to each other.
People ask me what tools I use to build apps without a traditional engineering team. Usually they're expecting a simple answer — one platform, maybe two. The reality is that building a production app with no-code isn't about one tool. It's about assembling the right combination of tools that each do one thing well and connect cleanly to each other.
Here's the exact stack we use at Novus Broker to build real, deployable applications — with honest notes on what works, what doesn't, and what I'd change.
The Builder: Replit
Replit is where the app itself gets built. It's not a traditional no-code drag-and-drop builder — it's closer to a development environment with AI assistance that lets you describe what you want and generates functional code.
Why we use it: Speed. I can go from concept to working prototype in days, not weeks. The AI agent understands context well enough that I can say "add a stats screen that shows monthly revenue and session count" and get something functional on the first try. It handles deployment, hosting, and version control in one place.
The honest trade-off: You're dependent on AI-generated code that you may not fully understand. When something breaks — and it will — debugging requires either enough technical intuition to describe the problem clearly or patience to iterate with the AI until it finds the fix. It's not the same as having an engineer who understands every line.
When I'd use something else: If I needed very complex custom animations, real-time multiplayer features, or heavy offline functionality, I'd look at FlutterFlow or native development. For most business applications, Replit handles it.
The Backend: Supabase
Supabase is where all the data lives — user accounts, client records, session logs, everything. It's an open-source alternative to Firebase that gives you a Postgres database, authentication, and row-level security out of the box.
Why we use it: Row-level security is the big one. When you're building an app where users store personal client information, you need absolute confidence that User A cannot see User B's data. Supabase handles this at the database level, which is more secure than trying to enforce it in your application code.
The honest trade-off: The learning curve is steeper than Firebase. Setting up row-level security policies requires writing actual SQL, which feels like a contradiction in a "no-code" stack. But it's worth the investment — you write the policy once and it protects every query automatically.
What surprised me: How generous the free tier is. For a pre-launch app with a few hundred users, you're unlikely to pay anything. The paid tier starts at $25 per month, which is reasonable for what you get.
The Payments: RevenueCat
RevenueCat manages subscriptions and in-app purchases. It sits between your app and Apple's App Store (or Google Play) and handles the complexity of subscription management — trials, renewals, cancellations, receipt validation, and analytics.
Why we use it: Because managing subscriptions directly through Apple's StoreKit framework is a nightmare. RevenueCat abstracts all of that into a clean SDK and dashboard. You define your products, connect your App Store account, and the SDK handles purchase flows.
The honest trade-off: Setup is more complex than it should be. You need to configure products in App Store Connect, create matching products in RevenueCat, link them through API keys, set up entitlements and offerings — and every piece has to match perfectly. I've spent more time debugging RevenueCat configuration than almost any other part of the build.
The non-obvious lesson: You can build your entire subscription UI yourself and just use RevenueCat for the backend processing. Their pre-built paywall templates exist, but if you've already designed your subscription screen, skip them and use the SDK directly. Less friction, more control.
The Auth: Supabase + Biometrics
Authentication is handled through Supabase's built-in auth system for initial signup, combined with biometric authentication (Face ID, fingerprint) for returning users.
Why this combination: First-time users sign up with email or phone verification. After that, they unlock the app with their face or fingerprint. It's the same pattern that banking apps use — secure enough for sensitive data, frictionless enough that people don't abandon the app because they forgot their password.
What we considered but skipped: Social login (Sign in with Google, Apple). For our target users — solo service providers who are often between sessions — biometrics is faster than any social login flow. We may add social auth later, but it wasn't necessary for launch.
The Communication: Twilio
Twilio handles phone number verification during signup and powers any SMS functionality. For an app that stores client phone numbers and may eventually offer caller ID or messaging features, having Twilio in the stack from the beginning made sense.
The honest trade-off: Twilio's pricing is per-message and per-verification, which means costs scale directly with usage. At small scale it's negligible — pennies per verification. At scale, it's a line item you need to monitor. We architected the app so that phone verification only happens once per account, not on every login, to keep costs predictable.
The Glue: Make (formerly Integromat)
Make connects everything that doesn't connect natively. Webhook processing, data transformation between systems, automated notifications, scheduled tasks — Make handles the workflows that exist between your tools.
Why Make over Zapier: More operations on the free tier, more flexible workflow logic, and visual scenario building that makes complex multi-step automations easier to understand and debug. Zapier is simpler for basic two-step automations, but Make scales better for anything beyond that.
What's Not in the Stack
Knowing what we don't use is as important as knowing what we do.
No custom backend server. Supabase handles API logic through edge functions when needed. Running a separate server adds complexity, cost, and another thing to maintain.
No separate analytics platform. RevenueCat provides subscription analytics. Supabase provides usage data. For pre-launch, that's enough. We'll add dedicated analytics when we have enough users to justify it.
No design tool in the daily workflow. Early mockups happen in Figma or even on paper. But once building starts, design iterations happen directly in the app. Maintaining a separate design file that needs to stay in sync with the actual product is overhead that slows a solo builder down.
The Total Cost at Launch
Here's what this stack actually costs to run a pre-revenue app:
Apple Developer Account runs $99 per year. That's mandatory for iOS distribution and non-negotiable. Everything else — Supabase, RevenueCat, Replit, Make — operates within free tiers at launch scale. Twilio costs a few dollars for verification SMS during testing.
Realistically, you're looking at roughly $100 to $150 for year one, pre-revenue. The tools scale in cost as usage grows, but by the time you're paying meaningful amounts, you should have revenue to cover it.
The Principle Behind the Stack
Every tool in this stack was chosen for the same reason: it does one job well, it has a free or cheap entry point, and it connects to the rest of the system cleanly.
The temptation with no-code is to find the one platform that does everything. That platform doesn't exist — and the ones that try to be everything end up doing nothing well enough for production use.
Build your stack like a toolkit, not a Swiss Army knife. Each tool is the best available option for its specific job. When a better option appears — and it will, because this space evolves fast — you can swap one piece without rebuilding the whole system.
That modularity isn't just a technical advantage. It's a business advantage. It means you're never locked into a single vendor's roadmap, pricing, or limitations. You stay flexible, and for a solo builder, flexibility is everything.
Novus Broker Technology builds production apps with no-code tools and helps businesses adopt the same approach. Get in touch if you're building something and want help choosing the right stack.
Here's the exact stack we use at Novus Broker to build real, deployable applications — with honest notes on what works, what doesn't, and what I'd change.
The Builder: Replit
Replit is where the app itself gets built. It's not a traditional no-code drag-and-drop builder — it's closer to a development environment with AI assistance that lets you describe what you want and generates functional code.
Why we use it: Speed. I can go from concept to working prototype in days, not weeks. The AI agent understands context well enough that I can say "add a stats screen that shows monthly revenue and session count" and get something functional on the first try. It handles deployment, hosting, and version control in one place.
The honest trade-off: You're dependent on AI-generated code that you may not fully understand. When something breaks — and it will — debugging requires either enough technical intuition to describe the problem clearly or patience to iterate with the AI until it finds the fix. It's not the same as having an engineer who understands every line.
When I'd use something else: If I needed very complex custom animations, real-time multiplayer features, or heavy offline functionality, I'd look at FlutterFlow or native development. For most business applications, Replit handles it.
The Backend: Supabase
Supabase is where all the data lives — user accounts, client records, session logs, everything. It's an open-source alternative to Firebase that gives you a Postgres database, authentication, and row-level security out of the box.
Why we use it: Row-level security is the big one. When you're building an app where users store personal client information, you need absolute confidence that User A cannot see User B's data. Supabase handles this at the database level, which is more secure than trying to enforce it in your application code.
The honest trade-off: The learning curve is steeper than Firebase. Setting up row-level security policies requires writing actual SQL, which feels like a contradiction in a "no-code" stack. But it's worth the investment — you write the policy once and it protects every query automatically.
What surprised me: How generous the free tier is. For a pre-launch app with a few hundred users, you're unlikely to pay anything. The paid tier starts at $25 per month, which is reasonable for what you get.
The Payments: RevenueCat
RevenueCat manages subscriptions and in-app purchases. It sits between your app and Apple's App Store (or Google Play) and handles the complexity of subscription management — trials, renewals, cancellations, receipt validation, and analytics.
Why we use it: Because managing subscriptions directly through Apple's StoreKit framework is a nightmare. RevenueCat abstracts all of that into a clean SDK and dashboard. You define your products, connect your App Store account, and the SDK handles purchase flows.
The honest trade-off: Setup is more complex than it should be. You need to configure products in App Store Connect, create matching products in RevenueCat, link them through API keys, set up entitlements and offerings — and every piece has to match perfectly. I've spent more time debugging RevenueCat configuration than almost any other part of the build.
The non-obvious lesson: You can build your entire subscription UI yourself and just use RevenueCat for the backend processing. Their pre-built paywall templates exist, but if you've already designed your subscription screen, skip them and use the SDK directly. Less friction, more control.
The Auth: Supabase + Biometrics
Authentication is handled through Supabase's built-in auth system for initial signup, combined with biometric authentication (Face ID, fingerprint) for returning users.
Why this combination: First-time users sign up with email or phone verification. After that, they unlock the app with their face or fingerprint. It's the same pattern that banking apps use — secure enough for sensitive data, frictionless enough that people don't abandon the app because they forgot their password.
What we considered but skipped: Social login (Sign in with Google, Apple). For our target users — solo service providers who are often between sessions — biometrics is faster than any social login flow. We may add social auth later, but it wasn't necessary for launch.
The Communication: Twilio
Twilio handles phone number verification during signup and powers any SMS functionality. For an app that stores client phone numbers and may eventually offer caller ID or messaging features, having Twilio in the stack from the beginning made sense.
The honest trade-off: Twilio's pricing is per-message and per-verification, which means costs scale directly with usage. At small scale it's negligible — pennies per verification. At scale, it's a line item you need to monitor. We architected the app so that phone verification only happens once per account, not on every login, to keep costs predictable.
The Glue: Make (formerly Integromat)
Make connects everything that doesn't connect natively. Webhook processing, data transformation between systems, automated notifications, scheduled tasks — Make handles the workflows that exist between your tools.
Why Make over Zapier: More operations on the free tier, more flexible workflow logic, and visual scenario building that makes complex multi-step automations easier to understand and debug. Zapier is simpler for basic two-step automations, but Make scales better for anything beyond that.
What's Not in the Stack
Knowing what we don't use is as important as knowing what we do.
No custom backend server. Supabase handles API logic through edge functions when needed. Running a separate server adds complexity, cost, and another thing to maintain.
No separate analytics platform. RevenueCat provides subscription analytics. Supabase provides usage data. For pre-launch, that's enough. We'll add dedicated analytics when we have enough users to justify it.
No design tool in the daily workflow. Early mockups happen in Figma or even on paper. But once building starts, design iterations happen directly in the app. Maintaining a separate design file that needs to stay in sync with the actual product is overhead that slows a solo builder down.
The Total Cost at Launch
Here's what this stack actually costs to run a pre-revenue app:
Apple Developer Account runs $99 per year. That's mandatory for iOS distribution and non-negotiable. Everything else — Supabase, RevenueCat, Replit, Make — operates within free tiers at launch scale. Twilio costs a few dollars for verification SMS during testing.
Realistically, you're looking at roughly $100 to $150 for year one, pre-revenue. The tools scale in cost as usage grows, but by the time you're paying meaningful amounts, you should have revenue to cover it.
The Principle Behind the Stack
Every tool in this stack was chosen for the same reason: it does one job well, it has a free or cheap entry point, and it connects to the rest of the system cleanly.
The temptation with no-code is to find the one platform that does everything. That platform doesn't exist — and the ones that try to be everything end up doing nothing well enough for production use.
Build your stack like a toolkit, not a Swiss Army knife. Each tool is the best available option for its specific job. When a better option appears — and it will, because this space evolves fast — you can swap one piece without rebuilding the whole system.
That modularity isn't just a technical advantage. It's a business advantage. It means you're never locked into a single vendor's roadmap, pricing, or limitations. You stay flexible, and for a solo builder, flexibility is everything.
Novus Broker Technology builds production apps with no-code tools and helps businesses adopt the same approach. Get in touch if you're building something and want help choosing the right stack.
