{{ $company->industry?->name }}
<%= @company_count %>
``` **Laravel approach:** ```php // Controller public function dashboard() { $chartData = Auth::user()->companies() ->join('industries', 'companies.industry_id', '=', 'industries.id') ->selectRaw('industries.name, COUNT(*) as count') ->groupBy('industries.name') ->pluck('count', 'name'); $companyCount = Auth::user()->companies()->count(); return view('dashboard', compact('chartData', 'companyCount')); } // Blade template with Chart.js{{ $companyCount }}
``` **Analysis:** Rails includes more built-in solutions for common web patterns, while Laravel provides elegant foundations for custom implementations with broader JavaScript ecosystem integration. ### Model Relationships and Validation **Rails Company Model:** ```ruby class Company < ApplicationRecord belongs_to :industry, optional: true belongs_to :user validates :name, presence: true, length: { maximum: 255 } validates :description, length: { maximum: 2000 } before_save :update_slug scope :by_industry, ->(industry) { where(industry: industry) } private def update_slug self.slug = name.parameterize if name_changed? end end ``` **Laravel Company Model:** ```php 'datetime', ]; public function industry(): BelongsTo { return $this->belongsTo(Industry::class); } public function user(): BelongsTo { return $this->belongsTo(User::class); } public function scopeByIndustry($query, $industry) { return $query->where('industry_id', $industry); } protected static function boot() { parent::boot(); static::saving(function ($company) { if ($company->isDirty('name')) { $company->slug = Str::slug($company->name); } }); } } ``` **Validation comparison:** - **Rails:** Model-level validations with simple syntax - **Laravel:** Request-level validation with expressive rules and reusable Form Request classes ### Filtering and Search Implementation **Rails implementation** (from [Part 3](/posts/2025/06/02/company-management-mvp-in-2-hours-pt-3)): ```ruby # Custom filter class class CompanyFilters attr_reader :companies, :params def initialize(companies, params = {}) @companies = companies @params = params end def filter filter_industries filter_text_query scope end private def scope @scope ||= companies end def filter_text_query return unless params[:search].present? @scope = scope.where("LOWER(name) LIKE :query OR LOWER(description) LIKE :query", query: "%#{params[:search].downcase}%") end end ``` **Laravel implementation with Laravel Scout (full-text search):** ```php 'nullable|string|max:255', 'industry' => 'nullable|exists:industries,id', ]; } public function applyToQuery($query) { if ($this->filled('search')) { $query->where(function ($q) { $q->where('name', 'LIKE', "%{$this->search}%") ->orWhere('description', 'LIKE', "%{$this->search}%"); }); } if ($this->filled('industry')) { $query->where('industry_id', $this->industry); } return $query; } } // Controller usage public function index(CompanyFilterRequest $request) { $query = Auth::user()->companies()->with('industry'); $companies = $request->applyToQuery($query)->paginate(15); return view('companies.index', compact('companies')); } // Alternative with Laravel Scout for full-text search public function search(Request $request) { if ($request->filled('search')) { $companies = Company::search($request->search) ->where('user_id', Auth::id()) ->paginate(15); } else { $companies = Auth::user()->companies()->paginate(15); } return view('companies.index', compact('companies')); } ``` **Analysis:** Laravel's approach integrates validation and filtering elegantly while offering advanced search capabilities through Scout, while Rails provides more convention-based patterns. ## Performance and Scalability Deep Dive ### Laravel Performance Advantages **Laravel Octane** transforms PHP performance characteristics: ```php // Traditional PHP-FPM: ~100-200 requests/second // Laravel Octane with Swoole: ~2000+ requests/second // Laravel Octane with RoadRunner: ~1500+ requests/second // Installation and configuration composer require laravel/octane php artisan octane:install swoole php artisan octane:start --workers=4 --task-workers=6 ``` **Laravel Horizon** provides elegant queue management: ```php // Config: horizon.php 'environments' => [ 'production' => [ 'supervisor-1' => [ 'connection' => 'redis', 'queue' => ['default', 'emails', 'reports'], 'balance' => 'auto', 'processes' => 10, 'tries' => 3, ], ], ], // Real-time monitoring dashboard available at /horizon ``` ### Rails Performance Patterns **Rails performance optimisations:** - ActiveRecord optimisations and eager loading - Built-in caching strategies with Rails.cache - Hotwire for interactive features without JavaScript complexity - Convention-based performance patterns **Example Rails optimisation:** ```ruby # N+1 query prevention @companies = current_user.companies.includes(:industry) # Fragment caching <% cache @company do %> <%= render @company %> <% end %> ``` ### Deployment and Infrastructure **Laravel deployment advantages:** - **Shared hosting compatibility** - Laravel runs on basic PHP hosting - **Lower hosting costs** - PHP hosting typically costs 50-70% less than Ruby hosting - **Laravel Forge** - automated server provisioning and deployment - **Laravel Vapor** - serverless deployment on AWS **Cost comparison example:** - **Laravel hosting:** $5-20/month for small applications - **Rails hosting:** $15-50/month for comparable performance ## Real-World Development Considerations ### Team Dynamics and Hiring **Rails teams typically experience:** - Faster onboarding due to strong conventions - Consistent code structure across projects - Rapid feature development cycles - Smaller, specialised talent pool **Laravel teams typically experience:** - Easier hiring from large PHP developer pool (60% of web applications use PHP) - More flexibility in implementation approaches - Elegant code that's enjoyable to maintain - Strong integration with existing PHP infrastructure ### Project Evolution and Scaling **Rails excels when:** - Building standard web applications quickly - Team values convention over configuration - Rapid iteration and validation are critical - Developer productivity is the primary concern **Laravel excels when:** - Team needs implementation flexibility - Existing PHP infrastructure exists - Large developer talent pool is important - Code elegance and readability are priorities - Performance at scale is crucial (with Octane) - Lower infrastructure costs matter ### Modern Laravel Ecosystem Advantages **Spatie packages** provide incredible productivity: ```php // Laravel Permission for role-based access use Spatie\Permission\Models\Role; $user->assignRole('company-manager'); $user->givePermissionTo('edit companies'); // Laravel Backup for automated backups use Spatie\Backup\Tasks\Backup\BackupJob; BackupJob::dispatch(); // Laravel Medialibrary for file handling $company->addMediaFromRequest('logo') ->toMediaCollection('logos'); // Laravel Query Builder for complex queries $companies = QueryBuilder::for(Company::class) ->allowedFilters(['name', 'industry']) ->allowedSorts(['name', 'created_at']) ->paginate(); ``` ## The Deployment and DevOps Story ### Rails Deployment **Rails 8 with Docker** (from [Part 4](/posts/2025/06/09/company-management-mvp-deploying)): ```yaml # config/deploy.yml (Kamal) image: your-username/company-crm servers: web: - 192.168.1.100 env: clear: RAILS_ENV: production secret: - RAILS_MASTER_KEY - DATABASE_URL ``` **Convention-based deployment:** - Built-in Docker integration - Kamal for simple orchestration - Environment-based configuration ### Laravel Deployment **Laravel with Docker and optimised deployment:** ```dockerfile FROM php:8.2-fpm # Install PHP extensions RUN docker-php-ext-install pdo pdo_mysql opcache # Copy and optimize Laravel application COPY . /var/www/html WORKDIR /var/www/html RUN composer install --optimize-autoloader --no-dev RUN php artisan config:cache RUN php artisan route:cache RUN php artisan view:cache RUN php artisan event:cache # Enable OPcache for production performance RUN echo "opcache.enable=1" >> /usr/local/etc/php/conf.d/opcache.ini ``` **Laravel Forge deployment script:** ```bash cd /home/forge/your-site.com git pull origin main composer install --no-interaction --prefer-dist --optimize-autoloader --no-dev php artisan config:cache php artisan route:cache php artisan view:cache php artisan queue:restart php artisan octane:reload ``` **Deployment comparison:** - **Rails:** Convention-based with excellent Docker integration - **Laravel:** Flexible with multiple optimised hosting solutions and typically lower costs ## Framework Ecosystem Comparison ### Package Management and Extensions **Rails Gems:** - Convention-based gem integration - Strong opinions about gem selection - Batteries-included philosophy reduces external dependencies - Generators often included with gems **Laravel Packages:** - Composer-based package management - Rich ecosystem with elegant integrations - Multiple official packages for common needs (Nova, Cashier, Scout, Sanctum) - Spatie ecosystem provides comprehensive functionality - Flexible package architecture ### Development Tools **Rails Development:** - Rails console for debugging and experimentation - Built-in generators for scaffolding - Integrated testing framework - Convention-based development workflow **Laravel Development:** - Artisan commands for code generation - Tinker for interactive debugging - Laravel Telescope for application insights - Laravel Horizon for queue monitoring - Laravel Debugbar for development debugging - Flexible development workflow options ## Making the Decision: Context Matters ### Choose Laravel when: - **Large talent pool matters:** PHP developers are more abundant and often less expensive to hire - **Existing PHP infrastructure:** Your organisation already runs PHP applications or has PHP expertise - **Performance at scale:** Laravel Octane provides dramatic performance improvements - **Budget constraints:** Lower hosting costs and developer costs - **Flexibility is crucial:** You need multiple approaches to solve problems elegantly - **Learning curve concerns:** Laravel's documentation and community resources are exceptionally beginner-friendly - **Code elegance priority:** Your team values readable, expressive code syntax - **Modern tooling:** Comprehensive development environment with Sail, reactive interfaces with Livewire ### Choose Rails when: - **Speed to market is critical:** Convention-driven development accelerates initial velocity - **Team consistency matters:** You want predictable code structure across all projects - **Generator-based workflow appeals:** Scaffolding and generators match your development style - **Convention over configuration:** You prefer opinionated frameworks that eliminate decisions - **Ruby expertise exists:** Your team appreciates Ruby's expressiveness and Rails conventions - **Rapid prototyping:** Need to validate ideas quickly with minimal setup ## Conclusion Both Rails and Laravel excel at rapid prototyping, but they optimise for different developer experiences and project contexts. **For pure prototyping speed**, Rails typically wins due to its scaffolding and convention-driven approach. You can generate a complete CRUD interface in minutes, while Laravel requires more explicit setup but rewards you with elegant, readable code and modern development tools. **For long-term development sustainability**, both frameworks scale well, but Laravel's flexible architecture, performance advantages with Octane, and larger talent pool often provide advantages for growing teams. **For team dynamics**, consider your hiring constraints and developer preferences. Rails attracts developers who value convention and rapid development, while Laravel appeals to those who appreciate elegant syntax and flexible architecture. **For budget considerations**, Laravel often provides significant advantages in both developer hiring costs and infrastructure expenses, making it particularly attractive for cost-conscious startups and organisations. ### The bottom line: Don't overthink the framework choice. Both Rails and Laravel power successful companies at massive scale. Consider your team's expertise, hiring constraints, development timeline, and budget. Pick the framework that gets your MVP in front of users fastest, then iterate based on real user feedback rather than theoretical performance concerns. **The real success factors:** - Team expertise and preferences - Time to market requirements - Long-term maintenance considerations - Available talent pool and budget constraints - Infrastructure and hosting costs Choose the tool that your team can execute with confidently and ship quickly. Market validation trumps framework optimisation every time. --- *Ready to validate your business concept with rapid prototyping, regardless of framework choice? Both Rails and Laravel can accelerate your path to market when used effectively. [Let's discuss](/#contact) which approach aligns with your team's strengths and project timeline.* ## Footnotes [^1]: Ruby on Rails is a server-side web application framework written in Ruby under the MIT License. Rails is a model–view–controller framework, providing default structures for a database, a web service, and web pages. First released in 2004, it emphasises convention over configuration and the DRY principle. https://rubyonrails.org/ [^2]: Laravel is a free and open-source PHP web framework created by Taylor Otwell and intended for the development of web applications following the model–view–controller architectural pattern. First released in 2011, Laravel emphasises elegant syntax and developer happiness. https://laravel.com/ --- # Building the Same CRM: Rails 8 vs Django - Two Approaches to Rapid Development URL: https://goudeketting.nl/posts/2025/06/16/rails-vs-django-crm-comparison Date: 2025-06-16 Tags: rails vs django, rapid prototyping, crm comparison, ruby on rails, django, framework comparison, mvp development, python vs ruby, web development, startup development Reading time: 12 min > After building a complete CRM in 2 hours with Rails 8, I analysed what the same system would require in Django. Both frameworks excel at different aspects of rapid development, revealing distinct philosophies for MVP creation. **TL;DR:** Django and Rails take fundamentally different approaches to rapid development. Rails prioritises convention and speed-to-first-prototype, while Django emphasises explicit structure and long-term maintainability. Both excel at MVP development, but for different team needs and project contexts. ## Introduction After demonstrating how to [build a complete CRM in 2 hours with Rails 8](/posts/2025/05/19/company-management-mvp-in-2-hours-pt-1), I—and others—wondered: "How would this compare to Django?" and "Would Python be better for this?" Rather than declaring one framework superior, I wanted to understand the fundamental differences in approach. Both Django and Rails power successful startups and enterprises—they just optimise for different development priorities. **What we're comparing:** - Development philosophy differences - Code structure and organisation approaches - Built-in features vs. explicit implementation - Setup complexity and configuration styles - Team productivity factors for rapid prototyping The goal isn't to pick a "winner," but to understand when each framework's strengths align with your project needs. ## Different setups The setup experience reveals fundamental philosophical differences between the two ecosystems. Rails[^1] embraces an "everything included" approach where `rails new company_crm --database=postgresql --css=bootstrap` creates a complete, opinionated project structure with database configuration, asset pipeline, testing framework, and styling integration ready to go—you can start building features immediately. Django[^2] follows Python's[^3] explicit philosophy, requiring manual assembly of components: creating virtual environments (`python -m venv`), installing individual packages (`pip install django psycopg2-binary django-crispy-forms`), configuring `settings.py` with database connections and installed apps, setting up URL routing, and manually organising static files and templates. While Rails optimises for immediate productivity with sensible defaults, Django prioritises transparency and flexibility, giving you explicit control over every component at the cost of initial setup time. Rails developers often joke about "convention over configuration," while Django developers appreciate knowing exactly what's happening in their application stack—both approaches have merit depending on whether you value speed-to-first-prototype or explicit understanding of your system's architecture. ## The Challenge: Identical Feature Set Our Rails CRM, built across [four detailed tutorials](/posts/2025/05/19/company-management-mvp-in-2-hours-pt-1), included: - User authentication with registration, login, and password reset ([Part 2](/posts/2025/05/26/company-management-mvp-in-2-hours-pt-2)) - Company CRUD operations with industry categorisation ([Part 1](/posts/2025/05/19/company-management-mvp-in-2-hours-pt-1)) - User-specific data isolation (each user sees only their companies) - Professional Bootstrap styling with responsive design - Interactive dashboard with charts and metrics ([Part 2](/posts/2025/05/26/company-management-mvp-in-2-hours-pt-2)) - Advanced filtering and pagination ([Part 3](/posts/2025/06/02/company-management-mvp-in-2-hours-pt-3)) - Production deployment with Docker ([Part 4](/posts/2025/06/09/company-management-mvp-deploying)) Let's examine how each framework approaches these requirements. ## Part 1: Project Setup - Two Philosophies ### Rails 8: Convention-Driven Setup As shown in [Part 1 of our tutorial](/posts/2025/05/19/company-management-mvp-in-2-hours-pt-1): ```bash rails new company_crm --database=postgresql --css=bootstrap rails db:create rails g scaffold Company name:string slug:string industry:references description:text ``` **Rails provides by convention:** - Complete project structure with opinionated defaults - Automatic database configuration - Integrated asset pipeline and styling - Generator-based rapid scaffolding - Built-in testing framework setup ### Django: Explicit Configuration Approach ```bash # Virtual environment and dependencies python -m venv crm_env source crm_env/bin/activate pip install django psycopg2-binary python-decouple django-crispy-forms # Project creation django-admin startproject company_crm cd company_crm python manage.py startapp companies ``` **Django's explicit configuration in `settings.py`:** ```python INSTALLED_APPS = [ 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'crispy_forms', 'crispy_bootstrap5', 'companies', ] DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql', 'NAME': config('DB_NAME', default='company_crm'), 'USER': config('DB_USER', default='postgres'), 'PASSWORD': config('DB_PASSWORD', default=''), 'HOST': config('DB_HOST', default='localhost'), 'PORT': config('DB_PORT', default='5432'), } } ``` **Philosophy comparison:** - **Rails:** "Convention over Configuration" - rapid start with opinionated defaults - **Django:** "Explicit is Better than Implicit" - clear, configurable setup from the beginning ## Part 2: Authentication - Built-in vs. Composed ### Rails 8: Generator-Based Authentication ```bash rails generate authentication rails db:migrate ``` This single command creates a complete authentication system with user models, controllers, views, and email reset functionality. ### Django: Leveraging Built-in Auth with Custom Views Django includes robust authentication in `django.contrib.auth`, but requires composition: ```python # companies/views.py from django.shortcuts import render, redirect from django.contrib.auth.forms import UserCreationForm from django.contrib.auth import login from django.contrib.auth.decorators import login_required def register(request): if request.method == 'POST': form = UserCreationForm(request.POST) if form.is_valid(): user = form.save() login(request, user) return redirect('company_list') else: form = UserCreationForm() return render(request, 'registration/register.html', {'form': form}) @login_required def company_list(request): companies = Company.objects.filter(user=request.user) return render(request, 'companies/list.html', {'companies': companies}) ``` **Authentication approach comparison:** - **Rails:** Complete system generated instantly, opinionated structure - **Django:** Flexible composition of built-in components, requires template creation ## Implementation Analysis: Different Strengths ### Development Speed Factors **Rails optimises for initial velocity:** - Scaffolding generates working CRUD in seconds - Convention eliminates configuration decisions - Integrated toolchain reduces setup friction - Generator-based workflow for common patterns **Django optimises for sustainable development:** - Explicit code structure aids team collaboration - Powerful admin interface for data management - Flexible architecture adapts to changing requirements - Strong integration with Python data ecosystem ### Code Organization Patterns **Rails Example - Company Controller:** ```ruby class CompaniesController < ApplicationController before_action :set_company, only: [:show, :edit, :update, :destroy] def index @companies = current_user.companies.page(params[:page]) end def create @company = current_user.companies.build(company_params) if @company.save redirect_to @company, notice: 'Company created successfully.' else render :new end end private def company_params params.require(:company).permit(:name, :industry_id, :description) end end ``` **Django Example - Company Views:** ```python from django.shortcuts import render, redirect, get_object_or_404 from django.contrib.auth.decorators import login_required from django.core.paginator import Paginator from .models import Company from .forms import CompanyForm @login_required def company_list(request): companies = Company.objects.filter(user=request.user) paginator = Paginator(companies, 25) page_companies = paginator.get_page(request.GET.get('page')) return render(request, 'companies/list.html', {'companies': page_companies}) @login_required def company_create(request): if request.method == 'POST': form = CompanyForm(request.POST) if form.is_valid(): company = form.save(commit=False) company.user = request.user company.save() return redirect('company_detail', pk=company.pk) else: form = CompanyForm() return render(request, 'companies/create.html', {'form': form}) ``` ### Where Each Framework Excels **Rails strengths for rapid prototyping:** - Minimal setup friction - Instant CRUD generation - Convention-based development speed - Integrated toolchain - Strong community around rapid development patterns **Django strengths for sustainable development:** - Explicit, readable code structure - Powerful admin interface for data management - Excellent ORM with complex query capabilities - Strong Python ecosystem integration - Flexible architecture that adapts well to growth ## Feature Implementation Comparison ### Dashboard and Analytics **Rails approach** (from [Part 2](/posts/2025/05/26/company-management-mvp-in-2-hours-pt-2)): ```ruby # Controller def index @chart_data = current_user.companies .joins(:industry) .group('industries.name') .count end # View (with Chartkick gem) <%= pie_chart @chart_data, donut: true %> ``` **Django approach:** ```python # View from django.db.models import Count def dashboard(request): chart_data = Company.objects.filter(user=request.user) \ .values('industry__name') \ .annotate(count=Count('id')) return render(request, 'dashboard.html', {'chart_data': chart_data}) # Template ``` **Analysis:** Rails includes more batteries for common web app patterns, while Django provides flexible foundations for custom implementations. ### Filtering and Search **Rails implementation** (from [Part 3](/posts/2025/06/02/company-management-mvp-in-2-hours-pt-3)): ```ruby # Custom filter class class CompanyFilters def filter filter_industries filter_text_query scope end private def filter_text_query return unless params[:search].present? @scope = scope.where("LOWER(name) LIKE :query", query: "%#{params[:search].downcase}%") end end ``` **Django implementation:** ```python # Using django-filter (recommended approach) import django_filters class CompanyFilter(django_filters.FilterSet): name = django_filters.CharFilter(lookup_expr='icontains') industry = django_filters.ModelChoiceFilter(queryset=Industry.objects.all()) class Meta: model = Company fields = ['name', 'industry'] # View def company_list(request): companies = Company.objects.filter(user=request.user) company_filter = CompanyFilter(request.GET, queryset=companies) return render(request, 'companies/list.html', {'filter': company_filter}) ``` **Analysis:** Django's approach requires additional packages but provides more sophisticated filtering capabilities out of the box. ## Real-World Development Considerations ### Team Dynamics **Rails teams often experience:** - Faster onboarding due to conventions - Shared understanding of project structure - Rapid feature development cycles - Less configuration debugging **Django teams often experience:** - More explicit code review discussions - Easier debugging due to explicit flow - Better long-term code maintainability - Stronger integration with data science workflows ### Project Evolution **Rails excels when:** - Building standard web applications - Rapid iteration is essential - Team values convention over configuration - Time-to-market is critical **Django excels when:** - Data modelling complexity is high - Admin interface usage is heavy - Team has strong Python expertise - Integration with scientific/data tools is needed ## Performance and Scaling Considerations Both frameworks scale well to millions of users, but with different optimisation patterns: **Rails scaling patterns:** - Convention-based performance optimisations - Strong caching patterns built into framework - Hotwire for interactive features without JavaScript complexity - ActiveRecord includes and counter caches **Django scaling patterns:** - Explicit query optimisation opportunities - Flexible caching backends - Strong database query profiling tools - Built-in database optimisation features ## The Deployment Story **Rails deployment** (from [Part 4](/posts/2025/06/09/company-management-mvp-deploying)): - Built-in Docker integration with Rails 8 - Kamal for simple production deployment - Convention-based environment configuration **Django deployment:** - Flexible deployment options (Gunicorn, uWSGI, etc.) - Strong support across all major platforms - Explicit configuration for production settings ## Conclusion The bottom line: Both Django and Rails excel at prototyping, but they optimise for different scenarios. ### Choose Django when: - Your MVP involves significant data processing or analysis - You need Django's built-in admin interface for content management - Your team has Python expertise or works extensively with data science tools - Long-term maintainability and explicit code structure are top priorities ### Choose Rails when: - Speed to market is critical for validation - Your team values developer happiness and quick iteration cycles - You're building a typical web application or SaaS product - You want maximum functionality with minimal configuration **For pure prototyping speed**, Rails typically wins due to its conventions and generators. You can scaffold a complete CRUD interface in minutes, while Django requires more explicit setup. **For scaling and maintenance**, both frameworks handle growth well, but Django's explicit approach often makes large codebases easier to navigate for new team members. ### The real decision factors: - **Team expertise** - Use what your team knows best - **Project timeline** - Rails for fastest MVP, Django for more structured development - **Long-term vision** - Consider your scaling plans and maintenance requirements Ultimately, don't overthink it. Both frameworks power successful companies at massive scale. Pick the one that gets your MVP in front of users fastest, then iterate based on real feedback rather than theoretical concerns. --- *Ready to validate your next business concept rapidly, regardless of framework choice? Both Rails and Django can get you to market quickly when used correctly. [Let's discuss](/#contact) which approach fits your specific needs and timeline.* ## Footnotes [^1]: Ruby on Rails is a server-side web application framework written in Ruby, following the model-view-controller (MVC) pattern. First released in 2004, Rails emphasises convention over configuration and the DRY (Don't Repeat Yourself) principle. https://rubyonrails.org/ [^2]: Django is a high-level Python web framework that encourages rapid development and clean, pragmatic design. Created in 2003 and open-sourced in 2005, Django follows the "batteries included" philosophy while maintaining explicit configuration. https://www.djangoproject.com/ [^3]: Python consistently ranks as one of the most popular programming languages according to the Stack Overflow Developer Survey, with particularly strong adoption in data science, machine learning, and web development communities. https://survey.stackoverflow.co/2024/technology --- # Deploying a Complete CRM: Rails 8 Rapid Prototyping to Production in 15 Minutes (Part 4) URL: https://goudeketting.nl/posts/2025/06/09/company-management-mvp-deploying Date: 2025-06-09 Tags: mvp development, rapid prototyping, crm, ruby on rails, rails 8 tutorial, minimum viable product, kamal, digitalocean, web development, startup mvp development, docker, solid queue, solid cable, solid cache Reading time: 10 min > After building a complete CRM in under two hours, we now need to deploy it to the web. We do this using kamal, dockerhub, and the docker setup that comes shipped with rails 8. **TL;DR:** In this final instalment, we deploy our complete CRM to production using Rails 8's built-in Docker integration and Kamal for orchestration. We configure DockerHub as our container registry, set up a DigitalOcean droplet with managed PostgreSQL, and configure Rails 8's solid_queue, solid_cache, and solid_cable for production-ready background processing. With proper environment configuration and DNS setup, we achieve a fully functional, SSL-secured production deployment in under 15 minutes. Combined with our 2-hour development time, we've gone from concept to live, stakeholder-accessible CRM in just over 2 hours total—demonstrating Rails' unmatched speed for MVP validation. ## Introduction After [finishing the CRM last week](/posts/2025/06/02/company-management-mvp-in-2-hours-pt-3), we should now deploy it. Rails 8 ships with docker[^1] integration and Kamal[^2] is made for easily managing these deployments. We'll deploy to DigitalOcean[^3] because of its easy scaling and simple setup, but first a reminder why this is important. **Why we're doing this and why it matters for your business:** When stakeholders can interact with a functional prototype that looks and feels production-ready, buy-in happens 3x faster than with static mockups. I've seen this repeatedly with B2B SaaS companies validating new features—functional beats beautiful every time when it comes to early validation. We're going to add a timer to track how long it takes to get our CRM live. My estimation is that it takes less than an hour, but let's see if Rails can surprise us again. ### Our setup Before we begin, let's talk through the setup we'll be using for deploying. Kamal uses Docker and DockerHub out of the box to deploy our application. In essence, what Kamal will be doing once we run a deploy is create a new image (or update it with the newest changes) on DockerHub and subsequently push it to our DigitalOcean droplet. That means there are a few separate elements we need to set up. Let's deploy this CRM and demonstrate why Rails remains unmatched for business validation speed! ## Account setup {:class='text-sm !-mt-4'}*⏱️ Elapsed time: 00:00* First, we should create accounts for [DockerHub](https://app.docker.com/signup){:target="_blank"} and [DigitalOcean](https://m.do.co/c/6a5def9f808d){:target="_blank"}. I just used my GitHub account, since that's what I use for all my development interactions. Of course, we also need a domain to deploy it to. I'll use a subdomain on my own website, but the setup will be the same for a normal domain. These foundational accounts create our deployment pipeline—the invisible infrastructure that transforms your validated prototype into a stakeholder-accessible application. ## Deploy configuration {:class='text-sm !-mt-4'}*⏱️ Elapsed time: 01:30* ### DockerHub We're going to need the account information from DockerHub to handle deploys correctly. Copy your username from [DockerHub](https://hub.docker.com/){:target="_blank"} and paste it into `deploy.yml` in our application in the following places: ```yml # config/deploy.yml image:<%= notice %>
<% end %> <% if alert %><%= alert %>
<% end %> ``` I added this above the Navbar partial, but you can put it wherever you like. That should be all we need for the authentication. Let's test it! {:class='max-h-80 mx-auto'} That's looking good! However, we just logged in and we see all the companies that we already created before. We need to ensure that companies are linked to each user, so every user can have their own list of companies. ## Password reset {:class='text-sm !-mt-4'}*⏱️ Elapsed time: 47:52* — *Time remaining: 72:08* If we now click on `Forgot password?` we can go to the form where we request a reset link for our password. Once we fill in our email and click `Email reset instructions`, `letter_opener` will open the email that gets sent with the reset link. Clicking that leads us to the `/passwords/edit` page, but in the address bar it looks weird. The weird gibberish you see there is actually the reset token. This token has a limited validity and can only be used once. Let's update the page real quick to be in line with the other pages: ```erb<%= user_companies.count %>
Companies
| Name | Last contacted at | <% @companies_to_contact.each do |company| %>
|---|---|
| <%= company.name %> | <% if company.last_contacted_at.present? %> <%= company.last_contacted_at.strftime("%B %d, %Y") %> <% else %> Not contacted yet <% end %> |
<%= notice %>
<% content_for :title, "Companies" %>| Name | Industry | Last contacted at | <% @companies.each do |company| %> <%= render company %> <% end %> <%= link_to "New company", new_company_path, class: 'btn btn-outline-primary' %> ``` And update our company row partial: ```erb <%# views/companies/_company_.html.erb %> |
|---|---|---|---|
| <%= company.name %> | <%= company.industry.name %> | <%= company.last_contacted_at %> | <%= link_to 'Show', company_path(company), class: 'px-2' %> <%= link_to "Edit", edit_company_path(company) %> |