DEV Community: Shaher Shamroukh

AWS vs DigitalOcean for SaaS: Why We Chose DigitalOcean for a Production Rails App

Shaher Shamroukh — Wed, 20 May 2026 19:34:22 +0000

There is a moment every SaaS founder hits early on.

You open AWS, look at the console, and it feels like you have walked into an airport control tower.

Everything is powerful. Everything is configurable. Everything is also overwhelming.

Then you open DigitalOcean and think:

“This looks too simple to be serious.”

We had the same reaction while building RobinReach, a Ruby on Rails SaaS handling social media scheduling, background jobs, API integrations, media processing, and multi-tenant data.

And we still chose DigitalOcean.

Not because AWS is worse.

But because better infrastructure is not the same thing as a better decision for your stage.

The Wrong Question Most Engineers Ask

Most infrastructure debates start with:

“Which is better, AWS or DigitalOcean?”

But in real SaaS building, that is not the right question.

The real question is:

“Which system lets us move faster without increasing operational complexity?”

Because early-stage SaaS products do not fail due to lack of scalability.

They fail due to:

slow iteration cycles
operational overhead
DevOps complexity
decision fatigue
fragile deployments

Infrastructure is rarely the bottleneck early on.

Complexity is.

What We Actually Needed for RobinReach

RobinReach is not a simple CRUD app.

It includes:

Ruby on Rails API backend
Sidekiq background job processing
Redis queues
PostgreSQL database
Media processing for images and videos
OAuth integrations with multiple social platforms
Scheduled publishing across timezones
Multi-tenant architecture

On paper, this sounds like AWS territory.

But in reality, none of this requires AWS level infrastructure on day one.

What it requires is:

stable compute
reliable background jobs
predictable deployments
simple observability
low operational friction

AWS: What Looks Powerful vs What You Actually Feel

AWS is undeniably powerful.

You get:

infinite scaling options
global infrastructure
deep service ecosystem like S3, ECS, Lambda
enterprise grade security

But early-stage SaaS reality looks very different.

What you actually feel:

VPC design decisions before product market fit
IAM complexity from day one
service fragmentation
networking overhead
slower deployment workflows
DevOps dependency creeping in early

AWS is optimized for scale.

But early-stage startups are not a scaling problem yet.

They are a speed problem.

The Hidden Cost of AWS: Cognitive Load

The real cost of AWS is not money.

It is cognitive overhead.

Every small decision becomes a system design problem:

Which service should we use here
How should these services communicate
Why did this IAM role break production
Why is deployment slower than expected
Why do we need five services for something simple

Individually, these problems are solvable.

But together, they create friction.

And friction slows iteration.

In SaaS, iteration speed is everything.

Why DigitalOcean Worked Better for Us

DigitalOcean did not feel powerful.

It felt predictable.

And that predictability matters more than people think.

With DigitalOcean, we could:

deploy Rails apps quickly
run Sidekiq workers without orchestration complexity
manage PostgreSQL without infrastructure overhead
scale vertically in a controlled way
focus on product instead of infrastructure design

Most importantly:

We reduced the number of decisions we had to make outside of product work.

That alone increased our shipping speed.

The Real Decision Was Not Technical, It Was Strategic

We did not choose DigitalOcean because it is simpler.

We chose it because it reduced unnecessary system complexity at our current stage.

At this stage of RobinReach, the most valuable resource is not infrastructure power.

It is:

uninterrupted product iteration.

The Scaling Myth

There is a common belief in engineering culture:

“Start with AWS so you can scale later.”

But in practice, most SaaS companies do not fail because they chose the wrong cloud provider.

They fail because:

they over engineered too early
they slowed down before finding product market fit
they optimized systems they did not yet need
they lost iteration speed

Scaling is not the first problem.

Survival is.

When AWS Actually Makes Sense

This is not an anti AWS argument.

AWS becomes the right choice when:

traffic volume becomes consistently large
multi region deployment is required
enterprise compliance is mandatory
infrastructure specialization is needed
DevOps becomes a dedicated function, not a side task

At that point, AWS is not overkill.

It is necessary.

But early on, it can easily become premature complexity.

The Hidden Part Nobody Talks About: Billing Complexity

One of the biggest reasons we chose DigitalOcean is not only infrastructure simplicity.

It is billing clarity.

Because in early SaaS, the real pain is not cost itself.

It is unpredictable cost and unclear billing logic.

AWS: Powerful, but requires interpretation

AWS billing is not a single number per server.

It is a combination of:

EC2 compute usage
EBS storage
S3 storage and requests
data transfer in and out
load balancers
NAT gateways
logging and monitoring services
region based pricing differences

The problem is not that AWS is expensive.

The problem is:

You often only understand your bill after you have already been charged.

Even small changes in architecture can affect cost in non obvious ways.

DigitalOcean: simple, predictable, boring in a good way

DigitalOcean takes a different approach:

fixed monthly pricing for compute
clear pricing for databases
predictable bandwidth limits
simple storage pricing
no hidden service cross billing complexity

You do not need to decode your bill.

You already know what it will be.

That predictability changes how you build.

Why this matters more than people think

At early stage SaaS, the biggest cost is not infrastructure.

It is mental bandwidth.

If you constantly need to:

explain your cloud bill
debug unexpected cost spikes
optimize infra before you have scale

You are not building product.

You are managing infrastructure uncertainty.

The simple rule we followed

We asked ourselves:

Can we predict next month’s infrastructure cost within a reasonable range without analysis?

If the answer is no, complexity is too high for our stage.

Architecture Snapshot (What We Run on DigitalOcean)

A simplified view of our setup:

Rails application for API and web layer
Sidekiq workers for background processing
Redis for queues and caching
PostgreSQL as the primary datastore
Object storage for media assets

This setup is intentionally simple.

Not because we cannot handle complexity.

But because we are optimizing for speed of iteration.

The Real Lesson from Building RobinReach

Infrastructure decisions are not about capability.

They are about tradeoffs between:

flexibility and simplicity
power and cognitive load
scalability and iteration speed

And early-stage SaaS has one consistent truth:

The fastest team to iterate usually wins, not the one with the most complex infrastructure.

Final Thought

AWS did not feel wrong.

It just felt like solving problems we did not have yet.

DigitalOcean did not feel impressive.

It felt invisible.

And in early-stage SaaS, invisible infrastructure is often exactly what you want.

Because the less you think about infrastructure,

the more you can think about building something people actually use.

Building a Production MCP Server in Ruby on Rails, Lessons from RobinReach

Shaher Shamroukh — Thu, 30 Apr 2026 20:05:14 +0000

Building a Remote MCP Server in Ruby on Rails, A Production Guide

Most MCP tutorials are Python or Node.js.

This is the Rails version, built in production, serving real users, powering an AI agent inside a SaaS product.

Here's the architecture, the key decisions, and the gotchas that cost us time.

What MCP Actually Is

Model Context Protocol is a standard for connecting AI models to external tools and data sources.

Before MCP, you'd give Claude a document and ask it questions. After MCP, Claude can call your API, read your database, take actions in your product, all from a conversation.

The protocol is simple: JSON-RPC 2.0. Claude sends requests, your server responds. That's it.

What makes it powerful is the standard — Claude knows how to discover, authenticate with, and call any MCP server that implements the spec correctly.

Local vs Remote, Why This Distinction Matters

Most tutorials show local MCP servers a process running on the user's machine, communicating via stdio.

That works for developer tools. It doesn't work for SaaS.

For a multi-tenant web application, you need a remote MCP server an HTTP endpoint that authenticates each user and serves their specific data.

This changes everything:

	Local (stdio)	Remote (HTTP)
Transport	stdin/stdout	HTTP + SSE
Auth	None needed	OAuth 2.0 required
Multi-user	No	Yes
Deployment	User's machine	Your server
Use case	Dev tools, CLIs	SaaS products

Rails is perfect for remote MCP. It's already an HTTP server. It already has auth. You're just adding a new endpoint.

The Architecture

Claude (client)
      ↓  JSON-RPC 2.0 over HTTPS
POST /mcp/v1/messages
      ↓
ApplicationController (auth + plan gating)
      ↓
MCP Tool Handler
      ↓
Your existing Rails services

No new infrastructure. No separate process. No Node.js. Just a new controller that speaks JSON-RPC.

Step 1 — The Routes

# config/routes.rb
# These must be at root level — outside any scope or namespace

# OAuth Discovery — Claude hits these before anything else
get "/.well-known/oauth-protected-resource",   to: "mcp/oauth#protected_resource"
get "/.well-known/oauth-authorization-server", to: "mcp/oauth#authorization_server"

# OAuth Flow
scope "/mcp/oauth" do
  post "register",  to: "mcp/oauth#register"
  get  "authorize", to: "mcp/oauth#authorize", as: :mcp_oauth_authorize
  post "token",     to: "mcp/oauth#token",     as: :mcp_oauth_token
end

# MCP Endpoint
post "mcp/v1/messages", to: "mcp/v1/messages#create", defaults: { format: :json }

Critical: The .well-known routes must exist before you test anything with Claude.ai. When a user adds your integration, Claude hits these discovery endpoints first. Without them the connection silently fails and you'll spend a day wondering why.

Step 2 — Authentication

For a SaaS product, you likely already have API keys. Use them.

# app/controllers/mcp/v1/base_controller.rb
module Mcp
  module V1
    class BaseController < ActionController::API
      before_action :authenticate!

      private

      def authenticate!
        # Accept token from header or query param
        token = request.headers["Authorization"]
                       .to_s
                       .delete_prefix("Bearer ")
                       .strip
        token = params[:api_key].to_s.strip if token.blank?

        @api_key = ApiKey.find_by(key: token)

        unless @api_key
          render json: {
            jsonrpc: "2.0",
            error: { code: -32_600, message: "Unauthorized" }
          }, status: :unauthorized
        end

        @api_key&.touch(:last_used_at)
        @current_company = @api_key&.company
      end
    end
  end
end

Notice: we accept the token from both the Authorization header and a query param. This matters because some MCP clients pass it differently, and it lets users connect via a simple URL with ?api_key=xxx during development.

Step 3 — The JSON-RPC Handler

MCP uses JSON-RPC 2.0. Every request has a method, optional params, and an id. Your response always includes the same id.

# app/controllers/mcp/v1/messages_controller.rb
module Mcp
  module V1
    class MessagesController < BaseController
      def create
        body   = JSON.parse(request.raw_post)
        method = body["method"]
        params = body["params"] || {}
        id     = body["id"]

        result = dispatch(method, params)
        return head :no_content if result == :notification

        render json: { jsonrpc: "2.0", id: id, result: result }

      rescue JSON::ParserError
        render json: { jsonrpc: "2.0", error: { code: -32_700, message: "Parse error" } },
               status: :bad_request
      rescue => e
        Rails.logger.error("[MCP] #{e.class}: #{e.message}\n#{e.backtrace.first(3).join("\n")}")
        render json: { jsonrpc: "2.0", id: id, error: { code: -32_603, message: "Internal error" } }
      end

      private

      def dispatch(method, params)
        case method
        when "initialize"
          {
            protocolVersion: "2024-11-05",
            serverInfo: { name: "your-app", version: "1.0.0" },
            capabilities: { tools: {} },
            instructions: system_prompt  # injected into Claude's context
          }
        when "tools/list"
          { tools: [YourMcpTool.schema] }
        when "tools/call"
          call_tool(params)
        when /\Anotifications\//
          :notification  # no response needed
        else
          raise "Method not found: #{method}"
        end
      end

      def call_tool(params)
        name      = params["name"]
        arguments = params["arguments"] || {}

        result = YourMcpTool.new(@current_company).call(name, arguments)
        { content: [{ type: "text", text: result.to_json }] }
      rescue => e
        {
          content: [{ type: "text", text: { error: e.message }.to_json }],
          isError: true
        }
      end

      def system_prompt
        # This is injected into Claude's context at connect time.
        # Use it to tell Claude how to behave, what order to call things,
        # and any domain-specific rules your application has.
        # Keep it focused — Claude reads this on every connection.
        YOUR_SYSTEM_PROMPT
      end
    end
  end
end

Key point: Errors from tool calls should return isError: true with a message in the content, not an HTTP error status. Claude reads the response body, not the HTTP status code. A descriptive error message in JSON is far more useful than a 500 with no body.

Step 4 — The Tool Design Decision

This is the most important architectural decision you'll make.

Option A — Many small tools:

list_posts, create_post, delete_post,
get_analytics, search_media, generate_image...

Option B — One tool, many actions:

your_app (action: "list_posts" | "create_post" | ...)

We went with Option B. Here's why.

With many tools, Claude has to pick the right tool before starting. With one tool and an action parameter, Claude can reason about what to do mid-conversation without switching tools.

It also makes the integration cleaner from the user's perspective — they see one integration in their Claude settings, not a wall of tools.

The schema looks like this:

def self.schema
  {
    name: "your_app",
    description: "Brief description of what this tool does and when to use it.",
    inputSchema: {
      type: "object",
      properties: {
        action: {
          type: "string",
          enum: ACTIONS,  # your list of supported actions
          description: "The action to perform"
        },
        # ... your other parameters
      },
      required: ["action"]
    }
  }
end

Step 5 — OAuth Discovery

For Claude.ai's "Connect" button to work, you need to implement OAuth discovery.

The good news: you don't need a full OAuth server. You can use OAuth as a thin wrapper around your existing API keys.

# app/controllers/mcp/oauth_controller.rb
module Mcp
  class OauthController < ActionController::API

    # Tells Claude where your MCP server is
    def protected_resource
      render json: {
        resource: "#{base_url}/mcp/v1/messages",
        authorization_servers: [base_url],
        bearer_methods_supported: ["header", "query"]
      }
    end

    # Tells Claude how to authenticate
    def authorization_server
      render json: {
        issuer: base_url,
        authorization_endpoint: "#{base_url}/mcp/oauth/authorize",
        token_endpoint: "#{base_url}/mcp/oauth/token",
        registration_endpoint: "#{base_url}/mcp/oauth/register",
        response_types_supported: ["code"],
        grant_types_supported: ["authorization_code"],
        code_challenge_methods_supported: ["S256"],
        token_endpoint_auth_methods_supported: ["none"],
        scopes_supported: ["mcp"]
      }
    end

    # Claude registers itself as a client
    def register
      render json: {
        client_id:                    "claude_#{SecureRandom.hex(8)}",
        client_secret:                nil,
        grant_types:                  ["authorization_code"],
        token_endpoint_auth_method:   "none"
      }, status: :created
    end

    # User sees this page and approves the connection
    def authorize
      # Require the user to be logged in
      unless current_user_from_session
        session[:oauth_return_to] = request.fullpath
        redirect_to login_path and return
      end

      # Generate short-lived authorization code
      code = SecureRandom.hex(32)
      REDIS.setex(
        "mcp:oauth:code:#{code}",
        5.minutes.to_i,
        current_user_from_session.api_key.key
      )

      # Redirect back to Claude with the code
      redirect_to "#{params[:redirect_uri]}?code=#{code}&state=#{params[:state]}",
                  allow_other_host: true
    end

    # Claude exchanges code for an access token
    def token
      key = REDIS.get("mcp:oauth:code:#{params[:code]}")

      unless key
        render json: { error: "invalid_grant" }, status: :bad_request and return
      end

      REDIS.del("mcp:oauth:code:#{params[:code]}")  # single use

      render json: {
        access_token: key,   # your existing API key becomes the token
        token_type:   "Bearer",
        scope:        "mcp"
      }
    end

    private

    def base_url
      "#{request.protocol}#{request.host_with_port}"
    end

    def current_user_from_session
      # Hook into your existing session auth
      # For Devise: User.find_by(id: session["warden.user.user.key"]&.first&.first)
    end
  end
end

The key insight: your existing API key becomes the OAuth access token. You don't need a new token system. OAuth is just a wrapper around what you already have. The code is a short-lived Redis key that maps to the real API key. Claude exchanges it once, gets the API key, and uses it as a Bearer token forever after.

Step 6 — The System Prompt

This is the part nobody writes about. The instructions field in your initialize response gets injected into Claude's context on every connection.

Use it to teach Claude:

How to behave in your domain
What order to call actions in
Rules specific to your application
How to talk to users

A few principles we learned:

Tell Claude what to do first. "Always call get_account_status before anything else" — Claude follows this reliably.

Encode your validation rules. If certain actions must happen before others, put it in the system prompt. "Always validate before creating. Never skip this step."

Make it dynamic. We append user-specific context — their preferred language, brand tone, timezone — at connect time. Claude immediately writes in the right voice without the user having to explain anything.

Keep it focused. The system prompt should be under 500 words. Long prompts dilute Claude's attention. Every sentence should earn its place.

Testing

Test with curl before testing with Claude. If curl works, Claude will work.

BASE_URL="https://yourapp.com"
API_KEY="your_api_key"

# 1. Test the MCP handshake
curl -s -X POST "$BASE_URL/mcp/v1/messages" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $API_KEY" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}' | jq .

# 2. List your tools
curl -s -X POST "$BASE_URL/mcp/v1/messages" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $API_KEY" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}' | jq .

# 3. Call a tool
curl -s -X POST "$BASE_URL/mcp/v1/messages" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $API_KEY" \
  -d '{
    "jsonrpc": "2.0",
    "id": 3,
    "method": "tools/call",
    "params": {
      "name": "your_app",
      "arguments": { "action": "get_account_status" }
    }
  }' | jq .

# 4. Test OAuth discovery
curl -s "$BASE_URL/.well-known/oauth-protected-resource" | jq .
curl -s "$BASE_URL/.well-known/oauth-authorization-server" | jq .

Run these in order. Each one confirms a layer of the stack is working before you move to the next.

Lessons Learned

The .well-known routes are not optional.
This cost us a full day. Add them first. Test them before anything else.

Errors belong in the response body, not HTTP status codes.
Claude reads JSON. Return { error: "descriptive message" } with isError: true. A 500 with no body tells Claude nothing.

The system prompt matters more than the tool schema.
We spent too long on the schema and not enough on the prompt. Claude's behavior improved more from prompt changes than from schema changes.

Use Redis for lightweight state.
User preferences, session data, short-lived codes — Redis handles all of it without schema migrations. Fast, simple, already in your stack.

Sequential over parallel.
We considered letting Claude batch multiple actions. Don't. Claude reasons better when it processes one response before deciding what to do next.

Test from the user's perspective weekly.
Connect to your own MCP server as a real user and have a real conversation. You'll find issues that unit tests miss — awkward response formats, actions that don't chain well, edge cases in your tool schema.

The Result

A production MCP server in Rails that:

Authenticates via existing API keys
Supports OAuth discovery for one-click connection in Claude.ai
Serves multiple tenants from a single endpoint
Reuses all existing Rails services
Deploys exactly like any other Rails endpoint

No new infrastructure. No Node.js. No separate process.

Just Rails doing what Rails does.

Try It

We built this for RobinReach, a social media management platform where users manage their entire social presence through a conversation with Robin, our AI manager.

robinreach.com → Settings → Connect Claude

Questions? Drop a comment. Happy to go deeper on any part of this.

AI Can Write Code But It Still Can’t Think Like a Developer

Shaher Shamroukh — Wed, 07 Jan 2026 17:32:16 +0000

Everyone is talking about AI replacing developers. Some say junior devs won’t even find jobs in 2026. As someone running a dev team at RobinReach, I think this is overblown and here’s why.

Writing Code Is Not the Same as Solving Problems

A lot of people think coding is just typing lines of code or building a simple website. Real software development is way more than that. You have to understand what a feature should actually do, how it should behave in tricky situations, track down bugs and find the root cause, design a system that is scalable and maintainable, and make decisions about trade-offs between speed, performance, security, and user experience.

And when it comes to full web apps, it gets even more complex. You are not just writing HTML or CSS. You have databases, backend logic, routing, state management, APIs, integrations, and frontend frameworks. AI cannot grasp the full system in context or reason about how all the pieces interact.

Static Websites Versus Full Web Apps

This is where people get confused. A static website is something simple, like a landing page or portfolio. You can set up a WordPress site or a Wix page in a couple of hours without any AI. It’s straightforward and there is nothing revolutionary about AI doing the same thing a little faster.

Full web apps are a different story. They have databases, backend logic, authentication, APIs, dynamic routing, state management, error handling, and scaling. Building and maintaining these apps requires problem-solving, debugging, and architectural thinking. AI is not ready to do that.

What Research Says

A recent MIT CSAIL study reported by IBM Think confirms this. It says that AI can churn out code but cannot think like a software engineer. AI struggles with planning long-term code, understanding an entire codebase, and handling legacy systems or specialized libraries.

Even the best AI does not remember previous prompts or understand how a project evolves over time. AI can write code but it cannot replace the reasoning, problem-solving, and judgment that real developers provide.

You can read the full article here: IBM Think – AI can write code, but can it beat software engineers?

My Experience at RobinReach

Even with AI tools, my junior developer drives the AI, not the other way around. They review suggestions, debug issues, validate fixes, and make architectural decisions. AI speeds up repetitive work but the thinking, problem-solving, and judgment are still fully human.

The Future of Development

The future is not AI replacing developers. It is humans working with AI. Developers who learn to use AI effectively will be faster and more productive. But understanding systems, reasoning through problems, and building robust software will always be human work.

Are we overestimating AI, or is the future really about developers guiding AI to solve real software problems?

Managing Multiple Brands in Rails: Multi-Tenant Patterns from RobinReach

Shaher Shamroukh — Mon, 22 Dec 2025 20:47:02 +0000

Scaling a SaaS application is one thing; letting a single user manage multiple brands, each with its own isolated data, is another.
At RobinReach, we faced this challenge head-on: users needed to handle multiple workspaces, each with its own social profiles, posts, and team members, all while switching seamlessly between them.
Here’s how we built it in Rails, and the lessons learned along the way.

The Challenge: Multi-Brand Management

Imagine a user managing three different companies on your platform. Each company has:

Its own social media profiles
Scheduled posts
Team members and roles
Analytics and performance data

Without proper isolation, cross-tenant data leaks become a nightmare.
Multi-tenancy is not just a database pattern, it’s a mindset for every layer of your application.

Workspace-Based Multi-Tenancy

At RobinReach, we modeled each brand or workspace as a tenant. All core models—Posts, SocialProfiles, Members, are scoped to a tenant. We use a thread-safe Current object to hold the tenant context:

class Current < ActiveSupport::CurrentAttributes attribute :company end

This allows all models to reference the current tenant easily:

class Post < ApplicationRecord belongs_to :company default_scope { where(company_id: Current.company.id) } end
With this pattern, every query automatically respects tenant boundaries.

Seamless Workspace Switching

Users expect to switch between workspaces without logging out. We store the current workspace in the session:
def switch_workspace(company_id) session[:current_company_id] = company_id Current.company = Company.find(company_id) end
This ensures that every action like viewing posts, scheduling content, or managing members, is scoped correctly to the selected workspace.

Background Jobs in a Multi-Tenant Environment

Multi-tenancy isn’t just about database queries; background jobs must also respect tenant boundaries.

Lessons Learned:
Always pass the tenant ID to background jobs.

Make jobs idempotent to prevent cross-tenant side effects.

Use Sidekiq queues strategically; high-volume tenants might need separate queues.

Best Practices for Workspace Multi-Tenancy

Enforce tenant isolation at all layers – models, services, jobs, and controllers.
Use thread-safe context objects (Current) for tenant information.
Design for fast workspace switching in the UI.
Keep background jobs idempotent and tenant-aware.
Cache per tenant when appropriate to reduce database load.
Monitor performance per workspace to detect heavy tenants early.

Conclusion

Building a multi-brand SaaS in Rails isn’t just a technical challenge, it’s a design mindset.
RobinReach demonstrates that with careful scoping, background job design, and workspace isolation, you can deliver a seamless multi-tenant experience.

For Rails developers building SaaS platforms, these patterns can save you from future headaches and set your app up for scale.

Building an AI Social Media Manager with Ruby on Rails: Architecture, Automation, and Lessons Learned

Shaher Shamroukh — Thu, 23 Oct 2025 19:56:33 +0000

Building an AI Social Media Manager with Ruby on Rails: Architecture, Automation, and Lessons Learned

In a previous post, How We’re Building a Social Media Empire with Rails and Sidekiq,
I shared how we scaled background jobs and task automation using Rails and Sidekiq. That article focused on how RobinReach
Our social media management platform handled large-scale post scheduling and media processing.

This time, we’re taking a deeper dive into how we integrated AI into our architecture and how Ruby on Rails continues to be the backbone of everything we build.

Why Rails Still Works for AI SaaS

Even in 2025, Ruby on Rails remains a perfect fit for startups building fast, scalable, and flexible SaaS products. When we started building RobinReach, we needed to:

Move fast with a clean architecture.
Handle complex background automation.
Support multi-tenant data isolation for agencies.
Integrate AI models that evolve quickly.

Rails gave us that foundation. With Hotwire and Tailwind CSS, we kept the frontend lean and responsive, no heavy SPAs needed.

Our Service-Driven Architecture

One of our early decisions was to adopt a service-driven architecture. Every core component from AI post generation to video rendering lives inside a dedicated service class.

That means each domain (posts, media, analytics, automation) can evolve independently while staying testable and predictable.

Example:

class Ai::ContentGeneratorService
 def initialize(post)
  @post = post
 end

 def call
  prompt = "Create a social media caption about #{@post.topic} in an engaging tone."
  response = RubyLLM::Client.new(model: "gpt-4o-    mini").complete(prompt)
 @post.update!(caption: response.text)
 end
end

By keeping logic inside services, we avoid bloated models and controllers, and it makes it easy to reuse across background jobs.

Using AI for Content Refinement

We started with the ruby-openai gem, but later switched to ruby-llm for its flexibility and broader model support.

Our AI layer powers features like:

RobinGen → generates captions, hashtags, and text variations.
RobinPilot → automates post creation from articles or ideas.
Content refinement → rewrites existing drafts to fit platform tone (LinkedIn, Instagram, etc.).

The workflow is simple:

User drafts or uploads content.
AI refines tone, grammar, or platform style.
User reviews and approves before scheduling.

We use background jobs to handle API calls asynchronously, ensuring the dashboard stays responsive while posts are being “AI-polished.”

Media Handling with MiniMagick and FFmpeg

For visuals, we rely on MiniMagick for image resizing and Streamio-FFmpeg for short-form video generation. These two tools help us dynamically create social media content that looks like it was edited manually.

Multi-Tenant Design for Agencies and Brands

RobinReach was designed for both businesses and marketing agencies. Each company account can manage multiple brands, each brand having its own users, social profiles, posts, and analytics.

We use a company context service to isolate data automatically:

Every query is scoped by company.
Each background job inherits that context.
Admins can switch between brands instantly.

This approach ensures data security and scalability without introducing unnecessary complexity.

Lessons Learned Building RobinReach

AI integration works best when it’s optional and assistive, not intrusive.
Service objects keep Rails clean and maintainable as complexity grows.
Multi-tenancy needs clear boundaries early, retrofitting it later is painful.
Rails still excels when paired with modern, lightweight tools like Hotwire and Tailwind.

Closing Thoughts

Building RobinReach has been a continuous learning process. We’ve learned that Rails is still one of the best frameworks for quickly turning complex ideas, like AI-driven automation, into production-ready features.

Our next steps include making RobinReach’s AI even smarter, from better content understanding to predicting the best times to post.

If you’d like to follow our journey or see how AI can simplify your social media workflow, you can check out RobinReach at https://robinreach.com/en
.

How We’re Building a Social Media Empire with Rails and Sidekiq

Shaher Shamroukh — Tue, 05 Aug 2025 21:23:22 +0000

It’s been a minute since I last published a blog post, mostly because we’ve been busy building RobinReach, a modern social media management platform powered by Ruby on Rails.

If you’ve ever tried building a tool that posts to multiple social platforms, handles different time zones, supports team approvals, automates publishing, and still provides clean analytics… you know it’s not a walk in the park.

What could’ve easily turned into a tangled mess of conditionals, platform-specific logic, and fragile scheduling code became a clean, maintainable, and scalable system thanks to Rails' service-oriented design and Sidekiq for background job handling.

The Stack That Powers RobinReach
RobinReach runs on a streamlined and modern Rails stack:

Ruby on Rails 7
PostgreSQL
Sidekiq + Redis for background jobs
Hotwire + Stimulus for reactive UI
TailwindCSS for styling

We manage thousands of scheduled posts across platforms like Instagram, LinkedIn, TikTok, Twitter, and YouTube, all orchestrated through Sidekiq workers that handle everything from publishing to AI content generation.

🧩 Why a Service-Oriented Architecture?
Each social media platform comes with its own rules: different APIs, content requirements, authentication flows, error handling, rate limits, the list goes on.

Instead of cluttering models or controllers with conditional logic, we split the logic by platform using dedicated service classes, like this:

module SocialMedia
  module InstagramDirect
    class Post < SocialMedia::ApplicationService
      def initialize(post, profile)
        # setup context
      end

      def call
        # 1. create media container
        # 2. wait for readiness
        # 3. publish
        # 4. return success or failure
      end
    end
  end
end

We use the same structure for:

SocialMedia::Twitter::Service
SocialMedia::LinkedIn::Service
Each class is responsible for only one job: posting to its platform.

What This Gives Us:

A clean interface: PlatformService.new(post, profile).call
Separation of concerns
Platform-specific logging + error handling
Easier testing, mocking, and maintenance

⏱ Why Sidekiq?

Publishing a post isn’t instant:

It needs to go out at the scheduled time
Some platforms require polling
Others need multi-step media uploads
You don’t want users waiting for any of that

Welcome Sidekiq.

We use Sidekiq to handle everything asynchronously and at scale.

A Typical Flow:

User schedules a post for a future time
We enqueue the job like this:

PostJob.perform_at(post.publish_time, post.id)

The job runs, finds the post, and calls the right service object
Everything happens in the background, with automatic retries if things fail.

💡The Sweet Spot: Service + Sidekiq
Here’s why the combination is so powerful:

🔧 Service Objects ⏱ Sidekiq
Encapsulate platform logic Handles execution & timing
Keep jobs thin Makes everything async
Testable, predictable Retryable, resilient
Modular per platform Scalable with queues

We can:

Add new platforms without touching existing logic
Retry failed posts automatically
Track errors in logs or monitoring tools
Move fast without fearing regression

🧪 Testability Bonus

Each service object is unit-tested on its own.
Jobs are tested separately with inline Sidekiq workers.
Because logic is separated, we can:
Mock external API calls in services
Simulate platform failures
Write isolated tests for platform behaviors

This would be a nightmare with fat models or controllers.

Final Thoughts
If you’re building a Rails app that interacts with third-party APIs, handles user actions asynchronously, or needs to scale beyond a weekend project…

💡 Split logic into service objects
🧠 Run tasks with Sidekiq

That combo gave us:

A cleaner codebase
Faster iteration cycles
Fewer bugs
Less stress

Rails gives you the foundation. These two patterns help you build skyscrapers on top of it.

Oh, and one more thing…
Turns out we’re not the only social media management tool built with Rails, shoutout to Publer, whose product and UX has definitely inspired us along the way.

Rails is alive and well. And with service objects + Sidekiq, it scales beautifully.

How to Integrate Your SaaS with AppSumo: A Step-by-Step Guide

Shaher Shamroukh — Thu, 13 Mar 2025 16:23:53 +0000

If you're launching your SaaS on AppSumo, integrating with their API is crucial for a smooth user experience. This guide walks you through the AppSumo authentication and license verification process, using a fully working Ruby on Rails example.

This article was inspired by RobinReach’s AppSumo integration.
Check out RobinReach for automated social media management! 🎯

Whether you're a founder or developer, this guide will help you integrate AppSumo seamlessly.

Why Integrate with AppSumo?

AppSumo offers lifetime deals (LTDs) to a large number of users.
To streamline onboarding and license verification, they provide an OpenID-based authentication system. By integrating with AppSumo's API, you can:

Verify purchases and activate licenses automatically
Handle license upgrades/downgrades
Respond to AppSumo webhook events
Improve user onboarding

Step 1: Setting Up the Authentication Flow

The first step in the integration is to set up an authentication flow that allows users to sign in via AppSumo.

1.1 Create an OAuth Redirect to AppSumo

In AppsumoAuthController, we define a method to generate the OAuth authorization URL and redirect users:

class AppsumoAuthController < ApplicationController
  skip_before_action :authenticate_user!
  skip_before_action :verify_authenticity_token

  CLIENT_ID = Rails.application.credentials.appsumo.client_id
  REDIRECT_URI = 'https://robinreach.com/appsumo/callback'

  def redirect
    auth_url = "https://appsumo.com/openid/authorize?client_id=#{CLIENT_ID}&response_type=code&redirect_uri=#{REDIRECT_URI}"
    redirect_to auth_url, allow_other_host: true
  end
end

This method constructs the OAuth authorization URL, allowing users to authenticate via AppSumo. Upon successful authentication, users are redirected to the specified callback URL.

1.2 Handle the Callback and Exchange Code for an Access Token

When users approve the authentication, AppSumo redirects them back with an authorization code. We exchange this code for an access token:

def callback
  code = params[:code]
  return redirect_to auth_url if code.blank?

  response = fetch_access_token(code)
  if response['access_token']
    session[:appsumo_access_token] = response['access_token']
    session[:appsumo_refresh_token] = response['refresh_token']
    redirect_to appsumo_license_path
  else
    render json: { error: response['error'] || 'Failed to authenticate' }, status: :unauthorized
  end
end

The fetch_access_token method sends a request to AppSumo to retrieve the access token:

def fetch_access_token(code)
  response = self.class.post('/token/', headers: { 'Content-Type' => 'application/json' }, body: {
    client_id: CLIENT_ID,
    client_secret: Rails.application.credentials.appsumo.client_secret,
    code: code,
    redirect_uri: REDIRECT_URI,
    grant_type: 'authorization_code'
  }.to_json)

  response.parsed_response
end

This step is essential for securely retrieving an access token, which will be used for further API requests.

Step 2: Fetch and Validate the License Key
Once authenticated, we need to fetch the license key to check if the user has a valid AppSumo purchase

def fetch_license
  access_token = session[:appsumo_access_token]
  if access_token
    response = self.class.get("/license_key/", query: { access_token: access_token })
    if response.success?
      license_key = response.parsed_response["license_key"]
      handle_license_verification(license_key)
    else
      refresh_access_token
    end
  else
    redirect_to new_user_session_path
  end
end

This method retrieves the license key and checks if it belongs to an existing Company. If not, the user is directed to sign up.

Step 3: Handling Webhook Events

AppSumo sends webhooks for key events like purchases, upgrades, and deactivations. We need to process them accordingly.

def webhook
  payload = JSON.parse(request.body.read)
  license_key = payload['license_key']
  event = payload['event']
  tier = payload['tier'].to_i

  case event
  when 'activate', 'purchase'
    REDIS.set(license_key, { license_key: license_key, tier: tier }.to_json, ex: 60 * 60 * 24 * 60)
    render json: { success: true, event: event }, status: :ok
  when 'upgrade', 'downgrade'
    update_license(license_key, payload['prev_license_key'], tier)
  when 'deactivate'
    deactivate_license(license_key)
  else
    render json: { success: false, error: 'Unknown event' }, status: :bad_request
  end
end

Why Store in Redis?

We use Redis to temporarily store the license data for quick access. This reduces the number of database queries and speeds up license verification. The data is set to expire after 60 days, ensuring that stale licenses are not kept indefinitely.

Updating the Company Based on the Event

For events like purchases or upgrades, we update the Company record to reflect the new subscription tier:

def update_company_license(license_key, tier)
  company = Company.find_by(license_key: license_key)
  if company
    company.update(plan_tier: tier)
  else
    Company.create(license_key: license_key, plan_tier: tier)
  end
end

This ensures that companies have the correct access level based on their AppSumo purchase.

Step 4: Securing Webhooks with Signature Verification
Since webhooks can be exploited, we verify requests using HMAC-SHA256 signatures:

def verify_signature
  timestamp = request.headers['X-Appsumo-Timestamp']
  signature = request.headers['X-Appsumo-Signature']
  body = request.raw_post

  return render json: { success: false, error: 'Missing headers' }, status: :unauthorized unless timestamp && signature && body

  message = "#{timestamp}#{body}"
  calculated_signature = OpenSSL::HMAC.hexdigest('SHA256', API_KEY, message)

  unless ActiveSupport::SecurityUtils.secure_compare(signature, calculated_signature)
    render json: { success: false, error: 'Invalid signature' }, status: :unauthorized
  end
end

This prevents unauthorized requests and protects your system from fraudulent webhooks.

Final Thoughts

Integrating AppSumo’s API into your SaaS can automate user onboarding, license management etc.

Key Takeaways:

✅ Implement OAuth authentication for AppSumo users
✅ Retrieve and validate AppSumo license keys
✅ Handle webhook events for upgrades, downgrades, and deactivations
✅ Secure webhooks using signature verification

This integration ensures that your SaaS can handle AppSumo deals efficiently while providing a seamless experience to users.

🔗 Next Steps:

Test OAuth flow and webhook processing.
Monitor webhook logs for debugging.

For more details, refer to the AppSumo Licensing Guide.

This guide is inspired by RobinReach’s integration with AppSumo. Discover how RobinReach simplifies social media management with automation and smart scheduling! 🚀

Just Launched RobinReach: Multi-Channel Social Media Management 🚀

Shaher Shamroukh — Wed, 18 Dec 2024 09:40:19 +0000

Hey Everyone! 👋

I’m excited to share that RobinReach, my social media management platform, is now live on Product Hunt! 🎉

RobinReach is built with Ruby on Rails and designed for small businesses, teams, and agencies to simplify their social media workflows.

Here’s what makes it stand out:

🌍 Multi-channel support: Manage all your social media accounts (Instagram, LinkedIn, Facebook, Twitter, and more) in one place.

✍️ Content creation: AI-assisted tools for generating and optimizing posts.

🔁 Content repurposing: Easily reuse and adapt content for different platforms to maximize reach.

📊 Analytics: Actionable insights to measure performance and improve engagement.

Whether you're scheduling posts, repurposing old content, or reviewing metrics, RobinReach aims to save time and boost results.

💡 Built primarily with Ruby on Rails, integrated with ChatGPT, FFmpeg, and Unsplash. It also supports features like TikTok/YouTube Shorts video generation and Canva image editing.

👉 Check it out here: RobinReach on Product Hunt.

Would love to hear your thoughts on:
1️⃣ The concept—does it fill a gap you see in social media management?
2️⃣ The tech side—any feedback or tips on scaling multi-channel management features?
3️⃣ Advice on making the most of a PH launch if you've done one before!

Let’s chat—I'm happy to answer questions about the tech stack, challenges, or lessons learned. 🚀

ActiveRecord Calculations

Shaher Shamroukh — Tue, 29 Mar 2022 16:40:24 +0000

Let's talk about some useful methods that are very handy when we need to do some calculations to our database records.

So what is activerecord calculations?

ActiveRecord Calculations provide methods for calculating values of columns in the ActiveRecord models.

`count` Method

Let's start with a method that is widely knowing for simple count.

User.count 
#returns the number of users.

Keep in mind that count is not always the most performant with that being said
this article demonstrates the difference between count, size, length.

But count has much more to offer 🔥 so let's see the different usage of count below 👇

User.count(:address)
# returns the count of all users whose address exist in our db.

User.distinct.count(:city)
# returns the count of different cities we have in our db.

User.group(:city).count
# returns a hash with each city and it's count.
#{ 'Cairo' => 5, 'Qina' => 3 }

We can also do the above 👆 with multiple columns

Post.group(:status, :category).count
# {["draft", "business"]=>10, ["published", "art"]=>5}

`maximum` Method

User.maximum(:age)
# 98
# returns the maximum value on the given column.

`minimum` Method

User.minimum(:age)
# 18
# returns the minimum value on the given column.

`average` Method

User.average(:age)
# 27.5
# returns the average value on the given column.

`sum` Method

User.sum(:age)
# 7845
# returns the sum of the values on the given column.

`ids` Method

User.ids
# returns the users ids

Summary

Please check out the documentation for reference.

I hope you found the article useful and enjoyed reading as much as i enjoyed writing it 😃.

Ruby Sets

Shaher Shamroukh — Tue, 15 Feb 2022 20:06:25 +0000

What is a Ruby Set

Ruby Set is a class implementing the mathematical concept of Set.
Meaning it stores items like an array without duplicate items so all the items in a set are guaranteed to be unique and it is a lot more faster and has some special capabilities.

Before getting into how to use set class let's first determine when do we use it.

When to use sets

Here are the few cases where sets work better:-
1- Elements order does not matter.
2- No duplicate values allowed.
3- The sequences needs to be compared for equality regardless of the order.

How to use sets

>> require 'set'
>> fruits = Set.new
>> fruits << "Apple"
>> fruits.add("Orange")
>> fruits
=> #<Set: {"Apple", "Orange"}>

We can also do this

>> numbers = Set[1, 2, 3, 4]
=> #<Set: {1, 2, 3, 4}>
Notice no duplicates allowed:
>> numbers << 3
=> #<Set: {1, 2, 3, 4}>

Here are some useful methods to use with sets

#include?
>> numbers.include?(4)
=> true

#delete
>> numbers.delete(2)
=> #<Set: {1, 3, 4}>

#disjoint?
>> numbers
=> #<Set: {1, 3, 4}>
>> numbers.disjoint? Set[5, 6]
=> true      #No elements in common the opposite is intersect?

#union or |
>> numbers
=> #<Set: {1, 3, 4}>
>> numbers.union Set[2, 4, 5] 
=> #<Set: {1, 3, 4, 2, 5}>
>> numbers | Set[2, 4, 5] 
=> #<Set: {1, 3, 4, 2, 5}>

#delete_if & It's opposite keep_if
>> fruits
=> #<Set: {"Apple", "Orange", "melon"}>
>> fruits.delete_if { |f| f == "melon"}
=> #<Set: {"Apple", "Orange"}>

#clear
>> numbers.clear
=> #<Set: {}>

As well as the method above Set is easy to use with Enumerable objects.

For more details please check out ruby-doc

Now we know how to use ruby sets for better performance and easier coding.
So if you are using Ruby in your current project and you think that any of the cases above apply to you, you should consider using ruby sets.

I hope you enjoyed reading the article as i enjoyed writing it if so Please share it so more people can find it 🙂

Working With Folders & Files In Ruby

Shaher Shamroukh — Fri, 08 Oct 2021 20:05:27 +0000

How to work with folders and files in ruby?

Ruby has two built in classes for us to work with files and folders those classes are Dir for directories and File for the files.

Ruby `Dir` class.

To create a Dir instance, you pass a directory path to new like the following:

d = Dir.new("/home/shaher/work/test")
d.entries
=> ["..", ".", "file.txt", "main.rb", ".csv"]

We can also use the class method

Dir.entries("/home/shaher/work/test")
=> ["..", ".", "file.txt", "main.rb", ".csv"]

We can get hold of the entries using the entries method,
or using the glob technique.
And the main difference is that globbing the directory doesn’t return the hidden entries (entries whose names start with a period.)
It also permits the wildcard matching and the recursive matching in the subdirectories.

Now with entries method we have the files in a nicely structured array so let's dive into the file class to do the work on our files.

Ruby `File` class

To create the file and write value we can do the following

f = File.new("comment.txt", "w")

Now you will see the file created and we have the object to use.
Let's add some text to the file we just created and close the file

f.puts "this text meant to be added to the comment file"
f.close

well we added the text but we wanna add more and update the file then we do the following

f = File.new("comment.txt", "a")
f.puts "we added this extra text to update the file"
f.close

Now we have our file holds the text we added and updated.

But using File.new to create a File object make us close the file ourselves.
Ruby as always being elegant and meant for our happiness it provides an alternate way to open files that puts
the task of closing the file in it's hands.
File.open with a code block.

When we call File.open with a block, the block receives the File object as its single argument.
So we use that File object inside the block and When the block ends, the File object is automatically closed.

In the following example our file is opened and read in line by line for processing.

File.open("comment.txt") do |f|
  f.each do |line|
    puts line.upcase
  end
end
=> THIS TEXT MEANT TO BE ADDED TO THE COMMENT FILE
=> WE ADDED THIS EXTRA TEXT TO UPDATE THE FILE

Ruby stops iterating when it hits the end of the file and closes the file.

Another method ruby provides is readlines which reads the whole file into an array like the example below:

File.readlines("comment.txt") do |f| 
  f.each do |line| 
    puts line
  end
end
=> ["this text meant to be added to the comment file\n", "we added this extra text to update the file\n"]

But why all that and not just iterate on the file and avoid wasting the space required to hold the file’s contents in memory?

Summary

Along with File and Dir classes there is also FileUtils module which provides some practical and convenient methods that make it easy to manipulate files from Ruby in a concise manner and in ways that correspond to familiar system commands.
File class reference
Dir class reference

I hope you enjoyed reading this article and found it useful! 🙂

Ruby Regular Expressions

Shaher Shamroukh — Mon, 04 Oct 2021 18:18:47 +0000

What is Ruby regular expressions (ruby regex)?

Regular expressions appear in many programming languages, with minor differences.

Their purpose is to specify character patterns that subsequently are determined to match or not match.
Pattern matching, in turn, serves as the basis for operations like parsing log files, testing keyboard input for validity, etc.

Regular expressions have a reputation of being incredibly powerful.

Regular expressions are instances of the Regexp class.
and it's literal constructor is a pair of forward slashes:
//

//.class
=> Regexp

Between the slashes we add the specifics of the regexp.
Now Any pattern-matching operation has two ends: a regexp and a string.
and the simplest way to do that with the match method.
we can do this either way since regular-expression
objects and string objects both respond to match.
Ruby also provides pattern-matching operator,
=~(equal sign and tilde).

p "Match!" if /ruby/.match("ruby is wonderful")
=> "Match!"

p "Match!" if "ruby is wonderful"=~(/ruby/)
=> "Match!"

Building regular expression pattern

When we write a regexp, we put the definition of the pattern between the forward slashes //.
and what we are putting simply a set of predictions that we want to look for in a string.

regex components

Literal characters,/r/ “match this character”.
The dot wildcard character (.), “match any character”.
Character classes, [aeiou] matches any vowel.

So far, we’ve looked at basic match operations which are true/false tests.

regex.match(string)
string.match(regex)

Till now we got the basics of regexp, and for everyone
I definitely recommend trying out Rubular to build your own regexp taking advantage of it's quick reference, which is awesome for practice, and it is very interactive.

I hope you enjoyed reading the topic as much as i enjoyed writing it. 🙂

DEV Community: Shaher Shamroukh

AWS vs DigitalOcean for SaaS: Why We Chose DigitalOcean for a Production Rails App

The Wrong Question Most Engineers Ask

What We Actually Needed for RobinReach

AWS: What Looks Powerful vs What You Actually Feel

The Hidden Cost of AWS: Cognitive Load

Why DigitalOcean Worked Better for Us

The Real Decision Was Not Technical, It Was Strategic

The Scaling Myth

When AWS Actually Makes Sense

The Hidden Part Nobody Talks About: Billing Complexity

AWS: Powerful, but requires interpretation

DigitalOcean: simple, predictable, boring in a good way

Why this matters more than people think

The simple rule we followed

Architecture Snapshot (What We Run on DigitalOcean)

The Real Lesson from Building RobinReach

Final Thought

Building a Production MCP Server in Ruby on Rails, Lessons from RobinReach

Building a Remote MCP Server in Ruby on Rails, A Production Guide

What MCP Actually Is

Local vs Remote, Why This Distinction Matters

The Architecture

Step 1 — The Routes

Step 2 — Authentication

Step 3 — The JSON-RPC Handler

Step 4 — The Tool Design Decision

Step 5 — OAuth Discovery

Step 6 — The System Prompt

Testing

Lessons Learned

The Result

Try It

AI Can Write Code But It Still Can’t Think Like a Developer

Managing Multiple Brands in Rails: Multi-Tenant Patterns from RobinReach

Building an AI Social Media Manager with Ruby on Rails: Architecture, Automation, and Lessons Learned

How We’re Building a Social Media Empire with Rails and Sidekiq

How to Integrate Your SaaS with AppSumo: A Step-by-Step Guide

Just Launched RobinReach: Multi-Channel Social Media Management 🚀

ActiveRecord Calculations

So what is activerecord calculations?

ActiveRecord Calculations provide methods for calculating values of columns in the ActiveRecord models.

count Method

maximum Method

minimum Method

average Method

sum Method

ids Method

Summary

Ruby Sets

What is a Ruby Set

When to use sets

How to use sets

Here are some useful methods to use with sets

Working With Folders & Files In Ruby

How to work with folders and files in ruby?

Ruby Dir class.

Ruby File class

Summary

Ruby Regular Expressions

What is Ruby regular expressions (ruby regex)?

Building regular expression pattern

regex components

`count` Method

`maximum` Method

`minimum` Method

`average` Method

`sum` Method

`ids` Method

Ruby `Dir` class.

Ruby `File` class