The Internal Tools You Can Vibe Code and the Ones That Will Cost You Later
A developer's $2,400 MRR SaaS reveals where pure AI coding works and where expertise matters

Hey Adopter,
Orel Zilberman runs WriteStack, a scheduling platform for Substack creators with 120 paying customers and $2,400 in monthly recurring revenue. He built it as a solo founder using AI development tools heavily. But he didn’t vibe code the entire platform.
He’s a software developer with nine years of experience. The distinction matters because it reveals where vibe coding actually works and where technical expertise still provides the edge.
What AI-assisted development actually looks like
uses Cursor for daily development. AI autocomplete handles 95% of his code. When he builds a feature, he tells the AI which files to reference and what he wants. It generates the foundation, usually on the first try. Then he fixes bugs and adjusts the code for WriteStack’s infrastructure.This is AI-assisted development, not vibe coding. Fast, but not fully automated. What used to take weeks now takes hours, but it requires someone who understands software architecture, debugging, and system integration.
Then he tried pure vibe coding for one feature. A year-end summary tool similar to Spotify Wrapped. He paid $25 for Bolt credits and built it without writing a single line of code.
This worked because the feature was self-contained, didn’t need deep integration with existing infrastructure, and could be tested independently.
The pivot that found product-market fit
WriteStack started as an outline generator for Substack posts. Orel built it, launched it, and learned it solved the wrong problem. Users didn’t need help writing. They needed help staying consistent and growing their audience through Substack notes.
His development background made the pivot feasible. He understood the codebase, knew which components to refactor, and could redirect the infrastructure without starting from scratch. AI tools accelerated the work, but strategic technical decisions required human judgment.
Where vibe coding works and where it breaks
Orel’s experience reveals the practical limits of pure vibe coding.
What works:
Self-contained features with clear boundaries
Tools that don’t require deep system integration
Prototypes you can test independently
Dashboards with standard patterns
His $25 Wrapped feature fit these criteria. It generated summary statistics without touching WriteStack’s core logic.
What still requires developer expertise:
Maintaining complex systems over time
Integrating new features with existing infrastructure
Optimizing performance and handling edge cases
Making architectural decisions that prevent technical debt
WriteStack has bugs. Orel fixes them because he understands the system. A non-technical founder using pure vibe coding would struggle to diagnose production issues.
The maintenance burden compounds. Building something once is cheap. Keeping it running and adding features still requires technical literacy.
The build versus buy calculation for operators
When I asked Orel if businesses would drop SaaS subscriptions to build custom tools, he pushed back. Building once is cheap. Maintaining it still costs more than paying $50 to $200 monthly for established products.
His framework: build custom for highly specific workflows where no SaaS alternative exists. Buy general-purpose software because the maintenance burden outweighs subscription savings.
The calculation shifts when building to sell. Orel’s $25 feature generates revenue as part of a product customers pay for. The maintenance cost is worth absorbing. For internal tools, the math rarely works unless the tool solves a problem unique to your competitive advantage.
Three practical takeaways for operators
Vibe coding works for bounded problems, not complex systems
Simple internal tools, prototypes, or self-contained features work well with vibe coding platforms. But projects requiring ongoing maintenance, system integration, or debugging production issues still need technical expertise. Know which category your project falls into before choosing your approach.
Speed to validation requires market judgment
Orel’s first product failed. His second found traction. AI tools made rebuilding cheaper, but they didn’t tell him what to build. The skill that matters is listening to users and validating demand. Technical leverage helps you test faster, not smarter.
The solo technical founder gained leverage, not the non-technical founder
One developer with AI coding tools now does what previously required a small team. But leverage accrues to people who already understand software development. Non-technical founders can build prototypes, but scaling those into production systems still requires technical literacy or hiring developers.
AI coding tools lowered the barrier to building software, but they didn’t eliminate it. Orel’s $25 vibe-coded feature works because it’s simple and self-contained. His $2,400 MRR platform works because he has the technical expertise to maintain, debug, and evolve it over time.
The opportunity for non-technical operators is real but bounded. Build internal tools, prototypes, and simple features. Test ideas fast. But understand that scaling those prototypes into production systems still requires technical literacy or partnerships with developers who have it.
The leverage shifted, but it didn’t disappear the need for technical expertise. It amplified what developers can do solo.
Adapt & Create,
Kamil








Thank you for the opportunity man!
Had a lot of fun having this podcast with you :)