DEV Community: Yousef

The "Vibe-Coding" Epidemic

Yousef — Thu, 13 Nov 2025 15:19:35 +0000

The Rise of "Vibe-Coding" Platforms

The AI development landscape has seen an explosion of platforms promising to turn ideas into code instantly. Platforms like Lovable, Bolt, and V0 have popularized what's become known as "vibe-coding". An approach where you describe what you want in natural language and get code generated immediately, often skipping traditional planning, documentation, and structured development processes.

While these platforms can be impressive for quick prototypes and demos, they represent a fundamental misunderstanding of how software should be built. The "vibe" approach leads to significant problems that become apparent as projects grow beyond simple demos.

What Happens When You Skip Planning

Code is generated based on immediate prompts without understanding the full context of your product. There's no systematic gathering of requirements, no consideration of edge cases, and no comprehensive planning.

Features are built in isolation without understanding how they fit into the larger system. Critical requirements are missed because they weren't explicitly mentioned in the prompt. There's no consideration of user flows, business logic, or technical constraints. Projects become a collection of disconnected features rather than a cohesive product.

The Architecture Problem

When code is generated reactively, responding to individual prompts without considering overall system architecture, each feature is built independently. This leads to inconsistent patterns, duplicated logic, and architectural debt.

As you add more features, inconsistencies emerge. Code patterns vary across the application. Functionality gets duplicated. Separation of concerns breaks down. Without systematic architecture, technical debt accumulates rapidly. Every new feature compounds the problem. Refactoring becomes necessary but risky, because there's no clear understanding of how the system should be structured.

Missing Business Context

The focus is on "what" (the feature) without understanding "why" (the business need) or "who" (the target user). There's no consideration of business objectives, user personas, market positioning, or success metrics.

This leads to features that don't align with business goals. You might build something that looks impressive but doesn't solve real problems. Without understanding your target users and their needs, you're building in the dark. There's no clear success criteria or metrics to measure whether what you've built is actually working.

The Iteration Challenge

These platforms do provide versioning, but the way they handle it creates significant problems. Platforms like V0 (as they currently stand at the time of writing this blog) create a new version of your app, design, or code with every single prompt. This linear versioning approach means you're constantly generating new versions as you iterate.

You end up with a long chain of versions, each representing a different attempt or fix. You ask for a change, the AI makes a mistake, you prompt again to fix it, and another version is created. Before you know it, you have dozens of versions and no clear sense of which one actually worked or got you what you wanted.

This linear versioning makes it difficult to compare different approaches. You can't easily explore alternative implementations side-by-side. You can't branch off from a working version to try something different. Instead, you're stuck in a linear progression where each version builds on the previous one, even if the previous one was a mistake.

You spend more time navigating through versions and trying to remember which one had the feature you wanted than actually building new functionality. You get lost in the version history, unsure which version represents your actual product vision.

The Frustration of Random Changes

One of the most frustrating aspects of working with these platforms is the tendency for the AI to make random, unsolicited changes to your design. You ask for a small adjustment to a button, and suddenly the entire layout has been rearranged. You request a color change, and the AI decides to restructure your component hierarchy.

This happens because the AI is only trying to "solve" your immediate request without any consideration for the project as a whole. It doesn't understand the broader context of your application, the design system you've established, or the architectural decisions you've made. Each prompt is treated in isolation, so the AI makes assumptions and "improvements" that you never asked for.

This is partially a limitation of how these AI models are trained. They're optimized to generate code that works, but they lack the context and constraints that come from understanding a complete project. Without a comprehensive PRD, design system, or architectural documentation, the AI has no reference point for what should remain unchanged.

The result is an iterative process that feels like two steps forward, one step back. You make progress on one feature, but unrelated parts of your application get modified. You spend time reverting unwanted changes instead of building new features.

This is where a structured methodology bridges the gap. By establishing comprehensive documentation—PRDs, design systems, architectural specifications—the AI has the context it needs to make changes that respect the project as a whole. Changes are made within the constraints of the established system, not as isolated solutions to individual prompts.

Quality Assurance Gaps

Code is generated without systematic quality checks. There's no review process, no consideration of best practices, and no validation that the generated code meets production standards.

Security vulnerabilities go unnoticed. Performance issues aren't considered. Code doesn't follow best practices. There's no systematic testing approach. Production-ready code is assumed but not verified.

As projects grow, these quality gaps become critical. Security issues can expose user data. Performance problems can make applications unusable. Code that doesn't follow best practices becomes unmaintainable.

When Projects Hit the Wall

The approach works well for simple, isolated features but breaks down as projects grow. Without systematic planning and architecture, adding features becomes increasingly difficult, and the codebase becomes unmaintainable.

The pattern is familiar: quick start, rapid initial progress, then a gradual slowdown as complexity increases. Eventually, the codebase becomes so tangled that progress grinds to a halt. Teams spend more time fighting the codebase than building features.

Knowledge Loss

Code is generated but documentation explaining why decisions were made, what the architecture is, or how the system works isn't created. Knowledge exists only in the code (if at all), making it difficult for teams to understand or maintain.

There's no record of why features were built. It's difficult for new team members to understand the system. There's no documentation of architecture or design decisions. Knowledge is lost when original developers move on. Maintenance becomes guesswork.

This creates a knowledge debt that compounds over time. As team members change, understanding of the system is lost. New developers struggle to understand why things were built the way they were. Changes become risky because the impact is unclear.

The Real Cost

The problems become apparent as projects grow. In the short term, quick demos and prototypes work fine. But as you add features, inconsistencies emerge. Architecture becomes messy. Technical debt accumulates. Projects become unmaintainable. Adding features becomes difficult. Refactoring becomes necessary but risky.

The hidden costs are significant: time spent fixing issues that proper planning would have prevented, technical debt that requires expensive refactoring, features that don't align with business goals, lost productivity from inconsistent architecture, and difficulty scaling or maintaining the codebase.

Why Methodology Matters

Software development isn't just about generating code—it's about building systems that work, scale, and maintain. This requires systematic planning, proper architecture, business context, and quality assurance.

A structured methodology ensures that every aspect of your product is considered before code is generated. Data models and system architecture are designed before implementation. Features are grounded in business objectives and user needs. Multiple review processes validate output for completeness and quality.

Versioning systems enable exploration of different directions while preserving work. Projects are designed to grow from MVP to enterprise-scale without hitting architectural walls. Comprehensive documentation serves as living records of your product.

The right approach combines the speed of AI automation with the rigor of a proven methodology. It doesn't skip steps or take shortcuts. Instead, it automates the entire process from requirements gathering through deployment, while ensuring every aspect is properly considered.

How Codalio Addresses These Problems

Codalio was built to solve exactly these problems. Instead of generating code from isolated prompts, Codalio follows a structured, four-phase methodology that ensures comprehensive planning before any code is written.

Comprehensive Planning First: Codalio begins with conversational requirements gathering through specialized AI agents. The Interviewer agent asks targeted questions to understand your vision, target audience, and business objectives. This ensures all aspects of your product are considered before code generation begins.

Systematic Architecture: The Architect agent designs comprehensive data models and system architecture before any code is generated. The Rhino Framework ensures consistent patterns, proper separation of concerns, and scalable architecture from the start. This prevents the architectural debt that accumulates with reactive code generation.

Business Context Built-In: The Project Manager and Product Manager agents create comprehensive PRDs that include business objectives, target audience analysis, user personas, success metrics, and competitive positioning. Every feature is grounded in business context, not just technical capability.

Non-Linear Versioning: Codalio's versioning system allows you to create multiple PRD versions, compare different approaches, revert to previous concepts, and merge ideas. You can explore alternatives without getting lost in a linear chain of versions. This enables systematic iteration rather than reactive prompting.

Context-Aware Changes: By establishing comprehensive documentation, design systems, and architectural specifications, Codalio's AI agents have the context they need to make changes that respect the project as a whole. Changes are made within the constraints of the established system, preventing the random, unsolicited modifications that plague vibe-coding platforms.

Living Documentation: Comprehensive PRDs serve as living documentation of your product. Every aspect is documented from business strategy to technical architecture to user flows. This documentation evolves with your product and provides a complete record of decisions and rationale, preventing knowledge loss.

The Codalio Method doesn't just generate code. It builds software the right way. Combining the speed of AI automation with the rigor of a proven methodology. It addresses every problem that vibe-coding creates, ensuring that your project can scale from MVP to enterprise without hitting the walls that derail projects built on ad-hoc prompting.

Conclusion

Vibe-coding platforms promise magic, instant code from simple prompts. But software development isn't magic. It requires systematic planning, proper architecture, business context, and quality assurance.

The problems aren't immediately apparent. They emerge as projects grow. What starts as a quick prototype becomes increasingly difficult to maintain. Features don't align with business goals. Architecture becomes inconsistent. Technical debt accumulates.

The solution isn't to avoid AI-powered development. It's to use it within a structured methodology that ensures quality, scalability, and maintainability. By combining AI automation with proven development practices, you can build software that's both fast to develop and built to last.

From Vibe Coding to Informed Development: How Codalio PRD Transforms Your Cursor Workflow

Yousef — Tue, 04 Nov 2025 23:00:18 +0000

There's a growing trend in the developer community that we might call "vibe coding". Jumping into implementation with AI coding assistants like Cursor, typing out prompts, and hoping the generated code is close enough to what you need. It feels productive. It's fast. And it often works... until it doesn't.

The problem emerges in that last 20%: when you need to understand the "why" behind a feature, when architectural decisions matter, when business logic intersects with technical implementation. That's when AI coding tools hit a wall. They're brilliant at generating code, but they lack the product context that makes code truly useful.

This challenge has become so common that development agencies are seeing a new category of work: "rescue" projects—codebases that were built with AI assistance but need expert intervention to align with actual product requirements. The code works, but it doesn't solve the right problem.

The solution isn't to abandon AI coding tools. They're incredibly powerful. The solution is to give them the structured context they need to generate code that aligns with your product vision. That's where Codalio PRD comes in.

The Cursor Challenge: Why "Vibe Coding" Fails

When you ask Cursor to "create a REST API endpoint for product reviews," it generates functional code. But functional isn't the same as complete. Here's what gets missed:

Lack of Product Context

AI doesn't know the "why" behind features. Without understanding user personas, security requirements, or business rules, Cursor makes assumptions. For example, building a user authentication endpoint without understanding:

Who your users are (verified purchasers vs. anonymous visitors)
What security requirements apply (GDPR compliance, data retention policies)
What business rules exist (only purchasers can review products they've bought)

The generated code might work, but it won't match your product's actual needs.

Architectural Blind Spots

AI generates code without understanding your system architecture. It doesn't know:

Your existing data model structure
Design principles that guide your implementation
Integration points with other systems
Scalability requirements

This leads to endpoints that don't fit your data model, violate design principles, or create architectural inconsistencies that require refactoring later.

Incomplete Requirements

When requirements are vague, AI fills in the gaps with assumptions. Missing validation rules, edge cases, and integration points become technical debt. The code works for the happy path, but fails when real users interact with it in unexpected ways.

The "Rescue" Problem

This is where the "rescue" cycle begins. Agencies receive projects where:

Code was generated quickly but doesn't match product requirements
Features are implemented but miss critical business logic
Validation rules are incomplete or incorrect
The architecture doesn't align with the product vision

The code works, but it needs expert intervention to become production-ready. This is expensive, time-consuming, and frustrating for everyone involved.

How Codalio PRD Solves This

Codalio PRD provides the structured product context that transforms AI coding from "vibe coding" to "informed development." Here's how:

Structured Product Context

Codalio's PRD builder uses specialized AI agents (Project Manager, Designer, Architect, Product Manager) that ask targeted questions to populate PRD sections. As you chat with these agents in the canvas, they generate:

Elevator Pitch: The core value proposition
Problem Statement: What problem you're solving
Solution: How your product addresses it
Vision: Where you're heading

These agents ensure completeness by scoring each section from their unique perspectives. This collaborative planning process ensures code aligns with product goals, not just technical requirements.

User-Centric Design

User personas, journeys, and flows inform implementation. Understanding user needs prevents over-engineering or missing critical features. When Cursor generates code, it can reference:

Who the user is (persona details)
What they're trying to accomplish (user journeys)
How they'll interact with the feature (user flows)

This prevents creating features users don't need or missing features they do.

Technical Specification

ERD diagrams, schema definitions, and sample data provide technical context. This prevents architectural mismatches. When Cursor generates endpoints, it knows:

The exact data model structure
Relationships between entities
Required fields and constraints
Sample data patterns

Code aligns with your architecture from the start.

Design Principles

Navigation design, sitemap, and design principles guide implementation. This ensures consistency across features. When generating code, Cursor can reference:

Design patterns used throughout the app
Navigation structure
UI component conventions

Features feel cohesive, not bolted-on.

Versioned Planning

PRD versions allow iterative refinement before coding. This prevents the "code now, fix later" anti-pattern.

You can:

Refine requirements in the PRD
Get stakeholder feedback
Score completeness (Project Manager, Designer, Architect, Product Manager perspectives)
Ensure readiness before generating code

Real Example: Building a REST API Endpoint

Let's see how this works in practice with a concrete example: implementing a "Create Product Review" endpoint.

Without PRD (Cursor alone)

Developer asks: "Create a REST API endpoint for product reviews"

Cursor generates:

@app.route('/api/reviews', methods=['POST'])
def create_review():
    data = request.json
    review = Review(
        product_id=data['product_id'],
        user_id=data['user_id'],
        rating=data['rating'],
        comment=data['comment']
    )
    db.session.add(review)
    db.session.commit()
    return jsonify(review.to_dict()), 201

What's missing:

Validation: Can any user review any product? Only purchasers?
Business rules: What's the minimum rating? Can users review products multiple times?
Data relationships: Is there a Purchase model? How do we verify purchase?
Error handling: What happens if the product doesn't exist? If the user already reviewed?
Edge cases: What if the product is discontinued? What if the user is banned?

Result: Code that works but doesn't match product requirements.

With Codalio PRD (Prevention)

PRD provides:

User personas: "Verified Purchasers" who can leave reviews
User flows: Review submission flow with validation steps
Schema: Review model with relationships (Product, User, Rating)
Business rules:
- Reviews must be from verified purchasers
- Ratings 1-5, required
- Comments minimum 20 characters
- One review per product per user
User stories: "As a verified purchaser, I want to leave a review so that other buyers can make informed decisions"

Cursor uses PRD context to generate:

@app.route('/api/reviews', methods=['POST'])
@require_auth
def create_review():
    data = request.json
    user = current_user

    # Business rule: Only verified purchasers can review
    purchase = Purchase.query.filter_by(
        product_id=data['product_id'],
        user_id=user.id,
        status='completed'
    ).first()

    if not purchase:
        return jsonify({'error': 'Only verified purchasers can review products'}), 403

    # Business rule: One review per product per user
    existing_review = Review.query.filter_by(
        product_id=data['product_id'],
        user_id=user.id
    ).first()

    if existing_review:
        return jsonify({'error': 'You have already reviewed this product'}), 409

    # Validation: Rating 1-5, required
    if 'rating' not in data or not (1 <= data['rating'] <= 5):
        return jsonify({'error': 'Rating must be between 1 and 5'}), 400

    # Validation: Comment minimum 20 characters
    if 'comment' in data and len(data['comment']) < 20:
        return jsonify({'error': 'Comment must be at least 20 characters'}), 400

    # Create review
    review = Review(
        product_id=data['product_id'],
        user_id=user.id,
        rating=data['rating'],
        comment=data.get('comment', '')
    )

    db.session.add(review)
    db.session.commit()

    # Update product average rating
    update_product_rating(data['product_id'])

    return jsonify(review.to_dict()), 201

Result: Code that aligns with product requirements, includes proper validation, respects business rules, and handles edge cases.

With Codalio PRD (Rescue)

Scenario: Existing code has issues (missing validation, wrong permissions)

Process:

Load PRD into Cursor context
PRD reveals: missing purchaser verification, incorrect rating validation
Refactor code using PRD as source of truth
Result: Code aligns with product requirements

The PRD acts as a single source of truth, making it clear what needs to be fixed and why.

Best Practices: Using PRD with Cursor

Here's how to get the most out of this workflow:

Start with PRD

Always generate or refine your PRD before coding. In Codalio, you interact with specialized AI agents in the canvas—each with their own perspective. The Project Manager asks about business goals and success metrics. The Designer explores visual style and user experience. The Architect probes technical constraints and data models. The Product Manager focuses on user needs and market positioning.

Answer their questions thoroughly—they're designed to uncover requirements you might miss. As you respond, the PRD populates in real-time, showing your progress with scores from each agent's perspective. Aim for scores above 8 before moving to code generation.

Reference PRD in Cursor

Include PRD sections in Cursor context. When asking Cursor to generate code, reference specific PRD sections:

"Based on the user personas in the PRD..."
"Following the user flow for review submission..."
"Using the ERD diagram from the PRD..."

This gives Cursor the context it needs to generate aligned code.

Iterative Refinement

Update PRD when requirements change, then regenerate code. Don't just patch code—update the PRD first, then let Cursor regenerate with the new context. This maintains consistency and prevents drift.

Version Control

Track PRD versions to understand requirements evolution. When you need to understand why code was written a certain way, check the PRD version it was based on. This creates a clear audit trail.

Collaborative Planning

PRD scoring (project manager, designer, architect, product manager) ensures completeness. Get scores above 8 before coding. This prevents generating code based on incomplete requirements.

Conclusion

The future of development isn't "AI replaces developers" or "developers ignore AI." It's "AI + structured planning = better outcomes."

Codalio PRD transforms AI coding from "vibe coding" to "informed development." By providing structured product context—user personas, business rules, technical specifications, and design principles—PRD enables AI coding tools like Cursor to generate code that aligns with your product vision from the start.

This prevents the "rescue" cycle. It reduces technical debt. It ensures code solves the right problems. And it makes development faster and more reliable.

Planning prevents problems. Structured context enables better AI assistance. Try Codalio PRD with your next Cursor project and experience the difference.

Synthetic Attributes in Rhino

Yousef — Thu, 23 Oct 2025 14:01:52 +0000

Synthetic attributes are one of Rhino's most powerful yet underutilized features, allowing you to create computed properties that enhance your API responses without cluttering your database. In this comprehensive guide, we'll explore how to implement synthetic attributes in a real-world blog application, demonstrating their practical benefits and advanced usage patterns.

What Are Synthetic Attributes?

Synthetic attributes are computed properties that don't exist in your database but are calculated on-the-fly and included in your API responses. They're perfect for derived data, analytics, and computed fields that would be expensive to store or frequently change.

Unlike regular database columns, synthetic attributes are:

Computed dynamically - calculated each time they're accessed
Read-only - cannot be set directly through the API
Context-aware - can access related models and associations
Type-safe - declared with specific data types for proper serialization

Building Our Blog Application

Let's start by setting up a complete blog application with three core models: Category, Blog, and BlogPost. This will give us a rich foundation to demonstrate various synthetic attribute patterns.

The Data Model

Our blog application follows a straightforward hierarchy:

# Category Model
class Category < ApplicationRecord
  has_many :blogs, dependent: :destroy
  rhino_owner_global
  validates :name, presence: true
end

# Blog Model
class Blog < ApplicationRecord
  belongs_to :user
  belongs_to :category
  has_many :blog_posts, dependent: :destroy
  rhino_owner_base
  rhino_references [:user, :category]
  validates :title, presence: true
end

# BlogPost Model
class BlogPost < ApplicationRecord
  belongs_to :blog
  rhino_owner :blog
  rhino_references [:blog]
  validates :title, presence: true
  validates :body, presence: true
end

Implementing Synthetic Attributes

Now let's add synthetic attributes to each model, demonstrating different use cases and patterns.

Blog Model: Analytics and Metrics

The Blog model is perfect for demonstrating analytics-focused synthetic attributes:

class Blog < ApplicationRecord
  belongs_to :user
  belongs_to :category
  has_many :blog_posts, dependent: :destroy
  rhino_owner_base
  rhino_references [:user, :category]
  validates :title, presence: true

  # Synthetic attributes
  attribute :word_count, :integer
  attribute :reading_time_minutes, :integer
  attribute :is_recent, :boolean

  # Calculate total word count across all blog posts
  def word_count
    blog_posts.sum { |post| post.body.split(/\s+/).count }
  end

  # Calculate estimated reading time (average 200 words per minute)
  def reading_time_minutes
    (word_count / 200.0).ceil
  end

  # Check if blog was published recently (within last 30 days)
  def is_recent
    return false unless published_at
    published_at > 30.days.ago
  end

  # Property restrictions for synthetic attributes
  rhino_properties_create except: [:word_count, :reading_time_minutes, :is_recent]
  rhino_properties_update except: [:word_count, :reading_time_minutes, :is_recent]
end

BlogPost Model: Content Analysis

Individual blog posts benefit from content-focused synthetic attributes:

class BlogPost < ApplicationRecord
  belongs_to :blog
  rhino_owner :blog
  rhino_references [:blog]
  validates :title, presence: true
  validates :body, presence: true

  # Synthetic attributes
  attribute :word_count, :integer
  attribute :reading_time_minutes, :integer
  attribute :excerpt, :string
  attribute :is_long_post, :boolean

  # Calculate word count for this post
  def word_count
    body.split(/\s+/).count
  end

  # Calculate estimated reading time (average 200 words per minute)
  def reading_time_minutes
    (word_count / 200.0).ceil
  end

  # Generate excerpt (first 150 characters)
  def excerpt
    body.truncate(150, separator: ' ')
  end

  # Check if post is considered "long" (over 1000 words)
  def is_long_post
    word_count > 1000
  end

  # Property restrictions for synthetic attributes
  rhino_properties_create except: [:word_count, :reading_time_minutes, :excerpt, :is_long_post]
  rhino_properties_update except: [:word_count, :reading_time_minutes, :excerpt, :is_long_post]
end

Category Model: Statistical Insights

Categories can provide valuable statistical information:

class Category < ApplicationRecord
  has_many :blogs, dependent: :destroy
  rhino_owner_global
  validates :name, presence: true

  # Synthetic attributes
  attribute :blog_count, :integer
  attribute :total_posts, :integer
  attribute :is_popular, :boolean

  # Count blogs in this category
  def blog_count
    blogs.count
  end

  # Count total blog posts across all blogs in this category
  def total_posts
    blogs.joins(:blog_posts).count
  end

  # Check if category is popular (has more than 5 blogs)
  def is_popular
    blog_count > 5
  end

  # Property restrictions for synthetic attributes
  rhino_properties_create except: [:blog_count, :total_posts, :is_popular]
  rhino_properties_update except: [:blog_count, :total_posts, :is_popular]
end

API Response in Action

With these synthetic attributes implemented, our API responses become incredibly rich. Here's what a blog response looks like:

{
  "id": 1,
  "title": "My Amazing Blog",
  "published_at": "2025-01-13T04:00:00.000Z",
  "created_at": "2025-01-13T17:44:49.893Z",
  "updated_at": "2025-01-13T17:44:49.893Z",
  "word_count": 1250,
  "reading_time_minutes": 7,
  "is_recent": true,
  "user": {
    "id": 1,
    "name": "John Doe",
    "email": "john@example.com",
    "display_name": "John Doe"
  },
  "category": {
    "id": 1,
    "name": "Technology",
    "blog_count": 3,
    "total_posts": 15,
    "is_popular": true,
    "display_name": "Technology"
  },
  "display_name": "My Amazing Blog",
  "can_current_user_edit": true,
  "can_current_user_destroy": true
}

Advanced Patterns and Best Practices

1. Performance Optimization

For expensive calculations, consider caching:

class Blog < ApplicationRecord
  attribute :expensive_calculation, :integer

  def expensive_calculation
    Rails.cache.fetch("blog_#{id}_expensive_calc", expires_in: 1.hour) do
      # Your expensive calculation here
      perform_heavy_computation
    end
  end
end

2. Conditional Attributes

You can make synthetic attributes conditional based on user permissions or other factors:

class BlogPost < ApplicationRecord
  attribute :analytics_data, :json

  def analytics_data
    return nil unless current_user&.admin?

    {
      views: view_count,
      engagement: engagement_score,
      trending: trending_score
    }
  end
end

3. Type Safety and Validation

Always declare your attribute types for proper serialization:

class Blog < ApplicationRecord
  # Good: explicit type declaration
  attribute :word_count, :integer
  attribute :reading_time_minutes, :integer
  attribute :is_recent, :boolean
  attribute :metadata, :json
end

Property Restrictions: Keeping Synthetic Attributes Read-Only

One of the most important aspects of synthetic attributes is ensuring they remain read-only. Rhino provides powerful property restriction methods:

# Exclude from create and update operations
rhino_properties_create except: [:word_count, :reading_time_minutes, :is_recent]
rhino_properties_update except: [:word_count, :reading_time_minutes, :is_recent]

# Or be more specific about what's allowed
rhino_properties_create only: [:title, :body, :published]
rhino_properties_update only: [:title, :body, :published]

Real-World Use Cases

Synthetic attributes shine in several scenarios:

1. Analytics and Metrics

User engagement scores
Content performance metrics
Reading time estimates
Popularity indicators

2. Content Processing

Word counts and readability scores
Auto-generated excerpts
Content summaries
Tag suggestions

3. Business Logic

Status calculations
Permission checks
Workflow states
Conditional data display

4. User Experience

Display names and labels
Formatted data (currency, dates)
Progress indicators
Status messages

Conclusion

Synthetic attributes in Rhino provide a powerful way to enhance your API responses with computed data without cluttering your database schema. By following the patterns demonstrated in this guide, you can create rich, dynamic APIs that provide valuable insights to your frontend applications.

The key is to remember that synthetic attributes should be:

Computed efficiently - avoid expensive operations
Properly typed - declare attribute types
Read-only - use property restrictions
Meaningful - provide real value to your API consumers

With these principles in mind, synthetic attributes can transform your Rhino applications from simple CRUD APIs into intelligent, data-rich interfaces that delight your users.

Your First Rhino Contribution: Making MVP Development Even Faster

Yousef — Fri, 10 Oct 2025 16:20:18 +0000

From Reading to Contributing

If you've been following our Rhino Framework series, you've seen how this framework can make MVP development 90% faster. You've learned about its architecture, understood how it works, and maybe even set up your own local environment. Now it's time to take the next step: actually contributing to the project.

This isn't just about getting your name in the commit history (though that's pretty cool too). Contributing to Rhino means you're helping shape the future of how we build web applications. Every contribution, from fixing a typo to implementing a new feature, makes the framework more powerful for developers around the world.

Understanding the Rhino Contribution Landscape

Before we dive into specific examples, let's talk about what kinds of contributions Rhino needs. The framework is built on familiar technologies (Rails and React), so if you know these, you can start contributing immediately.

The most valuable contributions fall into three categories: code improvements, documentation, and testing. Code contributions include bug fixes, new features, and performance optimizations. Documentation contributions help other developers understand how to use the framework. Testing contributions make the framework more reliable for everyone.

When you're looking for your first contribution, keep an eye out for issues labeled with good first issue or help wanted. These are specifically chosen to be well-documented, limited in scope, and good learning opportunities that won't take weeks to complete.

Real Example: Issue #232 - Organizations Factory for Testing

Let's look at a real issue that's perfect for first-time contributors.

What This Issue Is Asking For

Issue #232 is asking for the rhino_project_organizations gem to install an organizations factory for testing. Here's what that means in plain English:

The Rhino framework has a modular architecture with different gems for different features. One of these gems is rhino_project_organizations, which handles multi-tenant functionality (think multiple companies using the same application).

Currently, when developers want to test code that uses organizations, they have to manually create test data. This issue is asking for a FactoryBot factory to be automatically installed when someone includes the organizations gem, making testing much easier.

Why This Matters

Testing is crucial for any framework. When developers can't easily create test data for organizations, they either:

Skip writing tests (bad)
Write complex, hard-to-maintain test setup code (also bad)
Avoid using the organizations feature entirely (really bad)

By providing a factory out of the box, we make the organizations feature more accessible and encourage better testing practices.

To tackle this issue, you'd need to understand FactoryBot (how to write factories for test data), Ruby gems (how gems are structured and install files), Rails testing (how tests are organized), and multi-tenancy (basic understanding of how organizations work).

You'd start by exploring the rhino_project_organizations gem structure, looking at how other gems install factories (like rhino_project_core), examining the existing test setup in the template project, and studying FactoryBot documentation and best practices.

Real Example: Issue #215 - Refactoring Timestamp Attributes

Here's another great example of a contribution opportunity.

What This Issue Is Asking For

Issue #215 is about refactoring how Rhino handles timestamp attributes in ActiveRecord models. Currently, the code uses send(:all_timestamp_attributes_in_model) which is a private method. The issue asks to use the public all_timestamp_attributes_in_model method instead.

This is a Rails API change. In newer versions of Rails, this method became public, so we no longer need to use the send() workaround to access it.

Why This Matters

Using private methods (even through send()) is generally not a good practice because:

It can break when Rails updates
It's harder to understand what the code is doing
It makes the codebase less maintainable

By switching to the public API, we make the code more robust and easier to understand.

For this issue, you'd need Rails knowledge (understanding of ActiveRecord and Rails API changes), Ruby metaprogramming (understanding of send() and method visibility), version compatibility (how to check what Rails versions support which methods), and testing (how to verify the change doesn't break anything).

You'd focus on gems/rhino_project_core/lib/rhino/resource/active_record_extension/properties.rb, Rails documentation for the all_timestamp_attributes_in_model method, the test suite to understand how this method is used, and Rails version compatibility requirements.

The Contribution Process Step-by-Step

Now that you understand what these issues are asking for, let's walk through the actual process of making a contribution.

First, you'll need your own copy of the Rhino project. Fork the repository on GitHub, then clone it locally:

git clone https://github.com/your-username/rhino-project.git
cd rhino-project

Getting the codebase running locally is crucial for understanding how it works. Install dependencies, set up the database, and start the development servers:

bundle install
npm install
rails db:setup
rails s  # In another terminal: npm start

Never work directly on the main branch. Create a feature branch with a descriptive name:

git checkout -b fix/organizations-factory-installation

Before making changes, run the existing tests to make sure everything works. This gives you a baseline to ensure your changes don't break anything:

bundle exec rails test

This is where the real work happens. Start small and test frequently. Make one small change at a time, run tests after each change, use rails console to experiment with your changes, and read existing code to understand patterns.

When you're ready to submit, write clear, descriptive commit messages and push your changes:

git add .
git commit -m "fix: install organizations factory when rhino_project_organizations gem is included"
git push origin fix/organizations-factory-installation

Then go to GitHub and create a pull request with a clear title, detailed description of the problem and solution, and a link to the original issue.

Code review is a learning opportunity, not criticism. Read feedback carefully, ask questions if you don't understand, make requested changes promptly, and thank reviewers for their time and input.

Tools and Commands You'll Use

Here are the essential tools you'll become familiar with during your contribution journey.

Git Workflow Basics - You'll use git status to check your changes, git diff to see what you've modified, git add to stage files, and git commit with descriptive messages. Always push to your fork with git push origin branch-name.

Rails Console for Testing - The Rails console is your best friend for experimenting. Start it with rails console, then test your changes with commands like Organization.create(name: "Test Org") or FactoryBot.create(:organization). You can also check if methods exist with Organization.respond_to?(:all_timestamp_attributes_in_model).

Running the Test Suite - Use bundle exec rails test to run all tests, bundle exec rails test --verbose for more output, or bundle exec rails test test/models/organization_test.rb for specific files. You can also run tests matching a pattern with bundle exec rails test -n test_organization_creation.

Debugging Techniques - When things go wrong (and they will), add debug statements with puts "Debug: #{variable.inspect}", use the debugger with require 'debug'; debugger, check Rails logs with tail -f log/development.log, or use interactive debugging with require 'pry'; binding.pry.

What to Do When You're Stuck

Getting stuck is normal. Here's how to get unstuck:

Reading Existing Code for Patterns - The best way to understand how to implement something is to see how similar things are already implemented. Search for similar patterns with grep -r "factory.*install" gems/ or grep -r "all_timestamp_attributes" gems/. Look at how other gems handle similar functionality.

Using GitHub Search - GitHub's search is powerful for finding examples. Search for "factory installation" in the repository, look at similar pull requests, and check how other Rails gems handle similar problems.

Asking for Help - Don't suffer in silence. Ask questions in GitHub Discussions, join our Discord for real-time help, comment on the issue you're working on, or open a draft PR early to get feedback.

Breaking Down the Problem - When an issue seems overwhelming, read the issue carefully to understand what's being asked for, find similar implementations to see how similar problems have been solved, start with the simplest case (don't try to solve everything at once), test your understanding by explaining the problem to someone else, and ask questions rather than guessing.

Ready to Get Started?

Contributing to Rhino is easier than you might think. The framework is built on familiar technologies, the community is welcoming, and there are plenty of opportunities to make a meaningful impact.

Here's your action plan: Pick an issue (start with #232 or #215, or find another "good first issue"), set up your environment (get the codebase running locally), understand the problem (read the issue carefully and explore the codebase), make a small change (don't try to solve everything at once), ask for help (use Discord or GitHub discussions when you're stuck), and submit your contribution (open a pull request and celebrate!).

Remember, every expert was once a beginner. The Rhino community is here to help you learn and grow. Your first contribution might be small, but it's the first step toward becoming a valuable member of the open source community.

This post is part of our Hacktoberfest 2025 series. Follow along as we explore Rhino Framework through real examples and community contributions.

A Deep Dive into the Rhino Framework

Yousef — Tue, 07 Oct 2025 10:02:28 +0000

Welcome to our engineering blog series on Rhino, a framework that truly embodies the principles of Model-Driven Development (MDD). As a vibe-coding friendly framework, Rhino is perfect for developers who want to focus on their application's core logic and bring ideas to life with minimal friction. In this series, we'll explore how its architecture accelerates development by providing a robust set of tools and conventions out of the box. This first post will provide a high-level overview of the framework's structure, walk through a practical example, and then dive into the core mechanisms that make it such an intuitive platform.

The Rhino Mono-repo: A Unified Structure

At its core, the Rhino framework is organized within a single mono-repo called rhino-project. This approach houses both the backend Ruby gems and frontend JavaScript packages in one place, fostering a cohesive development experience. This structure allows for streamlined dependency management and ensures that all components of the stack are designed to work together seamlessly.

Backend Gems

The backend functionality is broken down into a collection of modular Ruby gems located in the gems/ directory. This design allows developers to selectively include the features they need. The cornerstone is the rhino_project_core gem, which delivers foundational capabilities like authentication, authorization, and a dynamic system for generating API endpoints. Building upon this core, specialized gems such as rhino_project_notifications, rhino_project_organizations, and rhino_project_subscriptions offer targeted functionalities for notifications, multi-tenancy, and payment processing, creating a layered and extensible architecture.

Frontend Packages

The frontend consists of a suite of JavaScript/TypeScript packages located in the packages/directory. These packages offer a variety of tools and reusable components for constructing the user interface. Notable packages include @rhino-project/core, which contains essential UI components and hooks that integrate directly with the backend API, and @rhino-project/config, which provides shareable configurations for development tools like ESLint and Prettier. To simplify project setup, the create-rhino-app package provides a command-line tool to quickly scaffold a new application.

A Practical Example: The Tutorial Application

To understand how these pieces fit together, let’s look at the official Rhino tutorial, which guides you through building a simple blog application. This example leverages the rhino-project-template, a pre-configured project that includes CI/CD setup and demonstrates the core functionalities of the framework without any additional modules like organizations.

The Data Model

The blog application is built around three primary models: Category, Blog, and BlogPost. Their relationships are straightforward: a Category can have many blogs, a Blog belongs to a category and a user, and a BlogPost belongs to a blog.

Here is how these models are defined in the application:

# Category Model:  
# File Path: app/models/category.rb  

class Category < ApplicationRecord  
  has_many :blogs, dependent: :destroy

  # Rhino specific code  
  rhino_owner_global

  validates :name, presence: true  
end

# Blog Model:  
# File Path: app/models/blog.rb  
class Blog < ApplicationRecord  
  belongs_to :user  
  belongs_to :category  
  has_many :blog_posts, dependent: :destroy

  # Rhino specific code  
  rhino_owner_base  
  rhino_references [:user, :category]

  validates :title, presence: true  
end

# BlogPost Model:  
# File Path: app/models/blog_post.rb  
class BlogPost < ApplicationRecord  
  belongs_to :blog

  # Rhino specific code  
  rhino_owner :blog  
  rhino_references [:blog]

  validates :title, presence: true  
  validates :body, presence: true  
end

Now that we have our data models, the next question is: how are they exposed through an API? This is where Rhino's controller system comes into play.

Exposing the API: A Deep Dive into Controllers and Policies

Rhino provides a flexible and powerful system of controllers and policies that work in tandem to secure and expose your API endpoints with minimal boilerplate.

The Controller Hierarchy

The controllers in rhino_project_core follow a clear inheritance hierarchy, which allows for shared functionality while enabling specialization where needed.

ActionController::API (from Rails)  
    └── Rhino::BaseController  
        ├── Rhino::AccountController  
        ├── Rhino::ActiveModelExtensionController  
        ├── Rhino::CrudController  
        │   └── Rhino::ActiveRecordDiscardController  
        ├── Rhino::SimpleController  
        └── Rhino::SimpleStreamController

Rhino::BaseController: This is the foundation for all other controllers in the framework. It integrates essential modules for authentication, authorization (via Pundit), and error handling. It’s an abstract controller and doesn’t handle routes directly.
Rhino::CrudController: This is the default controller for database-backed resources. For the models we created in the tutorial (Category, Blog, BlogPost), this controller provides the standard Create, Read, Update, and Destroy (CRUD) actions out of the box.
Other Controllers: The hierarchy also includes specialized controllers like Rhino::ActiveRecordDiscardController for soft-deletes, Rhino::AccountController for managing user-specific data, and others for handling virtual models and simple resources.

Authorization with Policies

Authorization is seamlessly integrated into the BaseController via the Pundit gem, meaning every controller action is automatically authorized. The framework provides a default policy, Rhino::CrudPolicy, which is used by the CrudController to enforce basic authorization rules. For instance, it might allow any authenticated user to create a resource but permit only the resource owner to update or destroy it.

The true power of this system is the ability to override these defaults. By creating a BlogPolicy in your application, the CrudController will automatically use your custom logic instead of the default policy when handling actions on Blog resources.

Here is an example from the CrudController showing how Pundit is used:

# In Rhino::CrudController  
def update  
  @record = policy_scope(model_class).find(params[:id])  
  authorize @record

  # ... rest of the update logic  
end

In this snippet, authorize @record triggers Pundit to find a policy corresponding to the record's class. If a BlogPolicy exists, its update? method will be called to determine if the action is permitted.

Dynamic Resource Routing: The Heart of Vibe-Coding

One of Rhino's most significant features, and what makes it so conducive to vibe-coding, is its ability to automatically generate API endpoints directly from your models. This Model-Driven Development approach minimizes configuration and lets you focus on your application's logic. Here’s a step-by-step breakdown of how it works.

1. The Central List: Rhino.resources

At the heart of the system is a simple array of strings, Rhino.resources, which holds the names of all the models to be exposed as API endpoints. This is defined in rhino-project/gems/rhino_project_core/lib/rhino_project_core.rb:

# module Rhino  
# ...  
mattr_accessor :resources, default: if Rails.env.production?  
                                      ['ActiveStorage::Attachment']  
                                    else  
                                      ['ActiveStorage::Attachment', 'Rhino::OpenApiInfo', 'Rhino::InfoGraph']  
                                      end  
 # ...  
end

2. Registration: Adding Your Resource

You add your own resources to this list using the Rhino.setup block, typically located in an initializer file. In the template project, this is done in rhino-project-template/config/initializers/rhino.rb:

# frozen_string_literal: true

Rhino.setup do |config|  
  # ...  
  # The list of resources exposed in the API  
  config.resources += [ "User", "Account" ]  
end

3. Gaining Capabilities: include `Rhino::Resource`

For a model to be a valid resource, it must include the Rhino::Resource module. This module, found in rhino-project/gems/rhino_project_core/lib/rhino/resource.rb, equips the model with the necessary methods to communicate with the routing system.

# app/models/blog.rb  
class Blog < ApplicationRecord  
  include Rhino::Resource

# ...  
end

By including this module, the Blog model now has methods like route_key and controller_name that the router will use.

4. The Router: Generating the Routes

The final step occurs in the routes file, rhino-project/gems/rhino_project_core/config/routes.rb. Here, the code iterates over the resource classes and generates the routes.

# frozen_string_literal: true

Rails.application.routes.draw do  
  scope Rhino.namespace do  
    # ...  
    Rhino.resource_classes.each do |m|  
      # ...  
      resources m.route_key, path: m.route_path, controller: m.controller_name, only: m.routes, rhino_resource: m.name, format: false   
      # ...  
    end  
  end  
  # ...  
end

The key is the call to Rhino.resource_classes. This method converts the array of strings in Rhino.resources into an array of class objects, allowing the router to call the methods provided by the Rhino::Resource module to build the routes dynamically.

Conclusion

The Rhino framework provides a well-architected foundation that champions a Model-Driven Development approach. By combining a mono-repo structure with a powerful system of controllers, policies, and dynamic routing, it facilitates a rapid, 'vibe-coding' workflow that streamlines development. This allows you to build secure and scalable APIs with remarkable efficiency by focusing on what matters: your data model. In our next post, we will build upon this foundation and explore some of the more advanced features Rhino has to offer. Stay tuned!

Contributing to Rhino: Building the Future of MVP Development

Yousef — Wed, 01 Oct 2025 16:24:30 +0000

Why Contribute to Rhino?

So you've read about Rhino Framework and you're thinking, "This sounds interesting, but how can I actually help?" Great question. Contributing to open source projects like Rhino isn't just about writing code - it's about building the tools that make development better for everyone.

When you contribute to Rhino, you're not just fixing bugs or adding features. You're helping shape the future of how we build web applications. Every contribution, from fixing a typo in documentation to implementing a new feature, makes the framework more powerful and accessible for developers around the world.

What Makes Rhino Different for Contributors

Unlike many open source projects that require deep knowledge of complex systems, Rhino is designed to be contributor-friendly. The framework is built on familiar technologies (Rails and React), so if you know these technologies, you can start contributing immediately.

The codebase is structured with clear patterns and conventions, making it easy to understand how different parts work together. Plus, the framework's focus on higher-level abstractions means you can work on meaningful features without getting lost in low-level implementation details.

Types of Contributions We Need

Documentation and Examples

One of the most valuable contributions you can make is improving documentation. This includes:

Tutorial content: Step-by-step guides for common tasks
API documentation: Clear explanations of how different components work
Example applications: Real-world projects that demonstrate best practices
Video content: Screen recordings showing how to use different features

Bug Fixes and Improvements

The Rhino project has several open issues that are perfect for contributors:

Good first issues: Simple fixes that help you learn the codebase
Performance improvements: Optimizing existing functionality
UI/UX enhancements: Making the admin interface more user-friendly
Testing: Adding tests for existing features or improving test coverage

New Features and Integrations

As the framework evolves, we need contributors to help with:

New components: Building reusable UI components
Integrations: Connecting with third-party services
Advanced features: Multi-tenancy improvements, authentication enhancements
AI integration: Making the framework work better with AI tools

Getting Started with Your First Contribution

1. Set Up Your Development Environment

First, you'll need to get the Rhino codebase running locally:

# Fork the repository on GitHub
git clone https://github.com/your-username/rhino-project.git
cd rhino-project

# Install dependencies
bundle install
npm install

# Set up the database
rails db:setup

# Start the development servers
rails s
# In another terminal:
npm start

2. Find an Issue to Work On

Look for issues labeled with "good first issue" or "help wanted". These are specifically chosen to be beginner-friendly and well-documented. Some current examples include:

Issue #232: Add organizations factory for testing
Issue #215: Refactor timestamp attributes method
Documentation: Improve getting started guide
Examples: Create simple blog model example

3. Understand the Codebase Structure

Rhino follows a clear structure that makes it easy to navigate:

Backend: Rails application with models, controllers, and services
Frontend: React components with TypeScript support
Admin: Auto-generated admin interfaces
Testing: Comprehensive test suite with examples

4. Make Your Changes

Start with small, focused changes. Don't try to fix everything at once. Make sure your changes are well-tested and documented.

5. Submit a Pull Request

When you're ready, submit a pull request with:

Clear description of what you changed
Tests for new functionality
Updated documentation if needed
Screenshots for UI changes

Community and Support

Getting Help

GitHub Discussions: Ask questions and share ideas
Discord Community: Real-time chat with other contributors and developers in our Discord
Code Reviews: Learn from feedback on your contributions

If you have something in mind that's not an existing GitHub issue, reach out to our Discord community to talk directly with developers who can help guide you through the contribution process.

Recognition and Growth

Contributing to Rhino isn't just about the code. It's about:

Building your portfolio: Showcase your skills to potential employers
Learning new technologies: Gain experience with modern development practices
Networking: Connect with other developers and industry professionals
Making an impact: Help shape the future of web development

The Impact of Your Contributions

Every contribution to Rhino makes a difference. Whether you're fixing a small bug, improving documentation, or adding a new feature, you're helping developers around the world build better applications faster.

The framework is used by startups, enterprises, and individual developers who need to move quickly without sacrificing code quality. Your contributions help these developers focus on what matters most - building the features that make their applications unique.

Ready to Get Started?

Contributing to Rhino is easier than you might think. The framework is designed to be accessible, the community is welcoming, and there are plenty of opportunities to make a meaningful impact.

Start by exploring the GitHub repository, reading through some issues, and setting up your development environment. Don't worry about making mistakes - that's how we all learn. The important thing is to get started and be part of building the future of web development.

This post is part of our Hacktoberfest 2025 series. Follow along as we explore Rhino Framework through real examples and community contributions.

Rhino Framework: The Real-Code Solution for MVP Development

Yousef — Wed, 01 Oct 2025 16:23:43 +0000

The MVP Development Problem (And Why It Sucks)

Look, building an MVP shouldn't be this hard. But here we are, spending weeks setting up authentication, admin dashboards, and all the boring stuff before we can even start building what actually matters.

Every web app needs the same basic stuff:

User authentication (because apparently we can't just trust people)
Admin dashboards (because someone needs to manage all this chaos)
Database setup (the fun part where nothing works the first time)
Frontend build tools (because why make it simple?)
Testing frameworks (that we'll probably ignore anyway)
Background jobs (for all the stuff that takes forever)

These "commodity" features eat up like 50% of your development budget. That's insane. You're spending half your time and money on stuff that every app needs, instead of building the features that make your product actually interesting.

The Current Development Landscape

When building MVPs, developers typically choose between two approaches:

Traditional Framework Development

Most developers start with Rails, React, or similar frameworks. This gives you complete control and flexibility, but comes with a significant time investment. You need to set up authentication, build admin interfaces, configure databases, and handle all the infrastructure yourself. While this approach works well for experienced teams, it can take weeks just to get to a working prototype.

Rapid Development Tools

Various tools promise faster development through visual builders, AI generation, or pre-built components. These can be great for prototyping, but often come with limitations around customization, scalability, or long-term maintenance. The challenge is finding the right balance between speed and flexibility.

Enter Rhino Framework

Rhino Framework is what happens when you take Ruby on Rails and React, and actually make them work together properly. It's real code that you can see, test, and modify. No black boxes, no vendor lock-in, no "trust us, it works."

What Makes Rhino Different

Complete Application Out of the Box Rhino comes with a fully functional application template that includes user authentication, admin dashboards, and multi-tenant architecture. Instead of spending weeks setting up these commodity features, you get a working application in minutes. The authentication system handles user registration, login, password reset, and email verification. The admin interface automatically generates CRUD operations for your models, complete with filtering, searching, and bulk actions. Multi-tenancy is built-in with account-based organization structure, so you can support multiple customers from day one.

90% Faster MVP Development Traditional Rails development requires you to set up authentication (usually with Devise), configure admin interfaces (often with ActiveAdmin), set up multi-tenancy, configure frontend build tools, and handle deployment. With Rhino, all of this is pre-configured and working. You can focus on building your unique business logic instead of reinventing the same infrastructure components. The framework provides higher-level abstractions that reduce boilerplate code, making it easier to build and maintain complex applications.

AI-Ready Architecture Rhino is designed to work seamlessly with AI development tools. The framework uses structured patterns and higher-level abstractions that AI can understand and generate. Instead of asking AI to write low-level Rails code, you can describe your business requirements in natural language, and AI can generate the appropriate Rhino components. This makes AI-assisted development more reliable and maintainable, as the generated code follows consistent patterns and best practices.

Key Benefits for Developers

For Junior Developers

Minimal Learning Curve: Since Rhino is built on Rails and React, you're learning industry-standard technologies. The framework provides clear patterns and conventions, so you don't have to figure out how to structure your application. The pre-configured setup means you can see how authentication, admin interfaces, and multi-tenancy work in a real application, giving you hands-on experience with production-ready code.

Instant Productivity: Instead of spending weeks learning how to set up authentication or build admin interfaces, you can start building your unique features immediately. The framework handles all the commodity functionality, so you can focus on learning the business logic and user experience aspects of development.

For Senior Developers

Time Savings: Senior developers often find themselves rebuilding the same infrastructure components across projects. With Rhino, you get a proven foundation that handles authentication, admin interfaces, multi-tenancy, and deployment. This lets you focus on the complex business logic and user experience that differentiates your application.

Scalability: Rhino is built on Rails and React, so you get all the scalability benefits of these mature frameworks. The multi-tenant architecture is designed to handle growth, and the codebase is structured to support enterprise-level features as your application evolves.

For Startups

Faster Time-to-Market: Startups need to validate their ideas quickly. With Rhino, you can go from idea to working prototype in days instead of months. The pre-configured infrastructure means you can focus on building the features that matter to your customers, not the technical foundation.

Lower Development Costs: By eliminating weeks of infrastructure setup, Rhino reduces development costs significantly. You can allocate more resources to user research, feature development, and customer acquisition instead of technical setup.

Getting Started with Rhino

Prerequisites

Ruby 3.3.4 or newer
Node.js 20.14.0 or newer
PostgreSQL 15 or newer

Quick Setup

Clone the template:

git clone https://github.com/rhino-project/rhino-project-template.git
cd rhino-project-template

Set up environment:

rails rhino:dev:setup

Install dependencies:

bundle install
npm install

Set up database:

rails db:setup

Start development servers:

# Terminal 1: Rails server
rails s

# Terminal 2: Frontend development server
npm start

Visit http://localhost:3000 to see your application running!

What You Get Out of the Box

User Authentication: Sign up, sign in, password reset
Admin Dashboard: Access at /admin for content management
Multi-tenant Architecture: Account-based organization structure
Modern UI: Professional interface with Bootstrap and React
Background Jobs: Queue system for long-running tasks
File Storage: Active Storage for file uploads
Testing Setup: Comprehensive testing framework

Real-World Example: From Idea to MVP

Let's say you want to build a SaaS application for project management. With traditional Rails development, you'd need to:

Set up authentication (2-3 days)
Build admin interface (1-2 weeks)
Configure multi-tenancy (2-3 days)
Set up frontend build tools (1-2 days)
Implement file uploads (1-2 days)
Configure background jobs (1-2 days)

Total: 2-3 weeks of setup before you can start building features

With Rhino Framework, all of this is pre-configured. You can start building your project management features immediately, focusing on what makes your application unique.

The Future of Web Development

Rhino Framework represents the future of web development: a middle ground between the flexibility of traditional frameworks and the speed of modern development tools. As AI becomes more capable, frameworks like Rhino will be essential for:

AI-Assisted Development: Higher-level abstractions that AI can understand
Rapid Prototyping: Quick iteration and experimentation
Production Readiness: Real code that scales with your business
Team Collaboration: Consistent patterns and best practices

What's Next

This is the first in a series of tutorials that will show you how to build real applications with Rhino Framework. Over the next few weeks, we'll cover:

Week 2: Building your first model and admin interface
Week 3: Creating custom React components
Week 4: Advanced features and deployment

We'll also be participating in Hacktoberfest 2025, so you can contribute to the framework while learning how to use it.

Join the Community

GitHub: rhino-project
Documentation: rhino-project.org
Discord: Codalio

Conclusion

Rhino Framework solves the fundamental problem of MVP development: too much time spent on commodity features, not enough time on what makes your product unique. By providing a real-code foundation with all the essential features pre-configured, Rhino lets you focus on building the features that matter.

Whether you're a junior developer looking to build your first application or a senior developer tired of reinventing the wheel, Rhino Framework provides the perfect balance of speed, flexibility, and production readiness.

Ready to build your MVP 90% faster? Let's get started with Rhino Framework.