DEV Community: Autumn

Before You Rebrand: A Second Act Approach to Marketing

Autumn — Thu, 19 Mar 2026 17:10:57 +0000

The idea of starting over feels powerful. It’s satisfying to imagine a clean system with no outdated language or choices. No half-finished ideas stitched together over time. Just a fresh start with where you’re at right now.

In software, a blank slate or a “rewrite” promises modern architecture and tidy patterns. In marketing, it promises a sharper story with messaging that finally says what we meant all along.

Part of the appeal is control. When you start from scratch, you get to make every decision again. You’re no longer constrained by what came before. You don’t have to explain past campaigns. You don’t have to reconcile inconsistencies. You just… begin.

There’s also relief in it. If performance is slipping, if competitors look cooler, or if the website feels dated, a rewrite feels like action. It signals progress, even before anything has actually improved. We like to believe that if we built it today, we’d build it better.

The problem is, the blank slate erases more than mistakes. It erases context, hard-won lessons, and even the invisible architecture that’s been holding everything together.

The rewrite reflex

The rewrite reflex rarely makes its first appearance as a dramatic announcement. It usually begins as a quiet frustration. Things feel heavier than they used to. Progress feels slower. The structure that once made sense now feels layered, maybe even messy. And at some point, someone wonders out loud whether it would be easier to just start over.

In software, that conversation is familiar. When architecture feels dated, patterns are inconsistent, and new features take more effort than expected, a rewrite starts to sound appealing because it promises clarity and control.

“If we rebuilt it today, we’d design it differently. We’d avoid the compromises. We’d get it right.”

In marketing, we don’t usually call it a “rewrite.” We might say, “We need a rebrand.” Or, “Our messaging isn’t working.” Or, “We’ve outgrown this.” But underneath it, the instinct is the same: let’s just start over.

There’s nothing wrong with this impulse, though. It usually comes from a good place, like wanting the story we tell to reflect who we’ve become. We want the product, the brand, and the market perception to feel aligned. When something feels off, replacing it feels like decisive action.

But the rewrite reflex assumes that history is the problem.

Sometimes the issue isn’t that the system exists. It’s that we haven’t taken the time to understand what’s actually working inside it. In software, years of knowledge are embedded in the code. In marketing, context is embedded in how customers already perceive you, even if imperfectly.

That’s valuable.

What marketing “rewrites” usually ignore
When a team decides to “start fresh,” the focus is usually on what feels broken, like a dated website or generic messaging. Maybe competitors feel sharper. Internally, it may feel like the brand no longer reflects the company’s direction.

All of that can be true, but what often gets overlooked is what’s already working quietly in the background.

Every brand exists inside a context. Customers already compare you to something. They already have a mental shortcut for what you are and what problem you solve. Even if your messaging isn’t perfect, it has been doing the steady work of setting expectations.

A full rewrite can disrupt that context and unintentionally erase the language your best customers resonated with. It can even shift the frame of reference, making it harder to place.

There’s also the question most teams skip: who already loves this?

Before rewriting everything, it’s worth asking which customers immediately “get” your value and why. What were they comparing you to when they chose you? What specific attributes mattered to them? What did they believe they were buying? What made them say yes?

Those answers reveal more about your positioning than any new tagline will.

Often, the problem isn’t that the brand is wrong. It’s that it was never fully articulated. The differentiators are there, but they’re buried under feature lists or overly broad messaging. The value themes are real, but they haven’t been distilled.

A rewrite wipes the surface clean, but in mature companies, there is usually more structure beneath all that than anyone realizes.

The second act approach to marketing

A second act in marketing doesn’t mean erasing what came before. It means understanding what’s already true and making it clearer.

In software, a second act might look like refactoring, modernizing a stack, or tightening architecture without discarding years of domain knowledge. In marketing, it looks similar. You don’t abandon your history. You clarify it. You strengthen the parts that have quietly been working. You refine the structure so the value is easier to see.

For our own marketing, this hasn’t meant a dramatic rebrand or a new identity. It has meant revisiting our service pages and rewriting them with more precision so they reflect the work we’re actually doing today. It has meant creating new service pages where our capabilities have expanded, instead of trying to force new strengths into old language.

It has meant widening the company's voice. Our engineers are speaking at events, attending meetups, and contributing to the conversation alongside leadership. More of our team members are writing blog posts, which means our perspective is broader and more grounded in real project experience. We’re highlighting what we do well instead of trying to sound like everything to everyone.

We’re also experimenting. Testing new content formats. Trying different social approaches. Paying attention to what resonates. Not because we’re chasing trends, but because we’re curious about how to better articulate the strengths we already have.

None of that meant we had to start over. It meant we had to look closely at what exists and ask how to evolve it.

That’s the difference.

When a rewrite actually makes sense
Rewrites aren’t always wrong. Sometimes they’re necessary.

In software, that might look like:

The business model has fundamentally changed
The architecture can’t support where the company is headed
The cost of preserving the system outweighs the cost of rebuilding
In marketing, it’s similar. A true reset may be warranted if:

You’ve shifted customer segments entirely
You’ve entered a new market with different expectations
Your business model has materially changed
Your previous positioning was never clearly defined in the first place
In those cases, you’re not refining the same story. You’re telling a new one.

But most situations aren’t like that. More often, what feels broken is misalignment. The product evolved, a team matured, or the market shifted slightly, and the language just hasn’t caught up.

Lean into the layers
Starting over will always feel tempting. In code and in marketing, most mature systems aren’t broken. They’re layered with context that took years to build.

Before you rewrite, it’s worth asking what actually needs to change. Sometimes the answer is everything. More often, it’s alignment and a clearer articulation of what’s already working and where you’re heading.

Good software deserves a second act. So do good brands!

When Reporting Quietly Becomes the Slowest Part of your Rails app

Autumn — Wed, 18 Mar 2026 23:08:17 +0000

Reporting rarely shows up as a problem on day one.

It usually starts with something small and useful. You set up a dashboard, a few queries, and maybe a quick way to answer a question that used to take too long.

This seems to work fine, so it gets left alone.

Then the app grows.

With more data, more questions, expanded filters, and more metrics, this process begins to carry more weight than it was designed for.

At some point, it stops feeling simple.

We start to see reporting become one of the slowest, most complex parts of an otherwise healthy Rails application.

The pattern we keep running into

What’s interesting is that this doesn’t happen because of one bad decision. It’s usually a series of reasonable ones.

A query gets a little more complex. Then another layer gets added. Active Record turns into raw SQL. Indexes are introduced to keep things fast. Views are added to organize the logic.

Each step makes sense on its own, right?

But over time, the system becomes harder to understand, slower to run, and more difficult to change. Upgrades get riskier, and even small changes start to feel expensive.

Teams often try to fix this by adding more indexes or introducing views, but they don’t make queries faster. Materialized views can work for smaller datasets, but become costly to refresh as things grow

None of these approaches are wrong. They just don’t always address the root of the problem.

A shift in how we approach reporting

Instead of continuing to optimize increasingly complex queries, we step back.

Most reporting is time-based: Days. Weeks. Months.

That gives us a clue.

Rather than calculating everything on the fly, we look for the smallest useful unit of data. Often that’s a day. Sometimes it’s something else. But there’s usually a clear base unit underneath the complexity.

Once you find that, you can start shaping the data in advance rather than rebuilding it on every request.

What tends to work better in practice

From here, a few patterns make reporting systems much easier to work with as they grow.

We create tables that are designed specifically for reporting, storing only the data needed to answer those questions. Instead of querying across many tables with complex joins, we aim to keep reporting queries focused and predictable.

We move heavy data processing out of request time, so user-facing performance doesn’t compete with reporting workloads. In some cases, this means using a follower database or a separate process to prepare reporting data in the background.

And we accept a small tradeoff: not everything needs to be real-time. In many cases, slightly delayed but fast and reliable reporting is a much better experience than slow, live queries.

We’re walking through this LIVE

We’ve been seeing this pattern often enough in client work that we decided to put together a short session to walk through how we approach it.

If reporting has started to feel heavier than it should, you’re welcome to join us.

Join the session

Ruby 4.0 and Ruby Box: What Changed and How to Upgrade Safely

Autumn — Wed, 04 Feb 2026 17:04:47 +0000

Ruby 4.0 dropped over the holidays, bringing us all new primitives for isolation, parallelism, and performance, as well as upgrade anxiety (inevitable) and the perpetual temptation to just rewrite our entire app (resist!). Let’s dive in!

Ruby Box: Isolation without abandoning Ruby’s flexibility

Ruby Box introduces a way to evaluate code inside an isolated environment. This means constants, classes, and monkey patches defined in a box do not leak out unless you explicitly expose them.

At a high level, Ruby Box is a formal mechanism for scoping global state.

Basic example

box = RubyBox.new

box.eval do
  class User
    def role
      :admin
    end
  end
end

defined?(User)
# => nil

Outside the box, User does not exist.

Selectively exposing behavior

box = RubyBox.new

user_class = box.eval do
  class User
    def role
      :admin
    end

    self
  end
end

user = user_class.new
user.role
# => :admin

Why this matters in real applications

In legacy Rails apps, global state is often the hidden cost of change. Monkey patches, initializer side effects, and gem overrides accumulate quietly as tech debt over the years. Ruby Box gives us a new way to:

Run isolated test scenarios without polluting the global runtime
Experiment with alternative implementations safely
Evaluate upgrades to dependencies without forking the app

This is particularly relevant when incrementally modernizing older systems, which is exactly where we see the most rewrite pressure among new (and sometimes existing!) Planet Argon clients.

ZJIT: A new foundation for Ruby performance

RUBYOPT="--zjit" ruby app.rb

Ruby 4.0 introduces ZJIT, a next-generation JIT compiler designed to be more maintainable and extensible than previous implementations.

ZJIT is not yet a universal replacement for YJIT, but it establishes a clear direction. Because it’s a work in progress, it's not enabled by default just yet. Here is a quote from the release notes. “ZJIT is faster than the interpreter, but not yet as fast as YJIT. We encourage you to experiment with ZJIT, but maybe hold off on deploying it in production for now. Stay tuned for Ruby 4.1 ZJIT.”

Enabling ZJIT

What changes in practice

You do not write Ruby differently to use ZJIT. The benefit is structural, not syntactic. ZJIT introduces:

A cleaner internal compiler architecture
Larger compilation units
A path to future optimizations that do not require rewriting Ruby code

For teams running mature applications, this matters because it provides immediate and actual performance in runtime evolution instead of theoretical gains that could maybe possibly potentially come with a risky application rewrite.

Ractors: Continued progress toward true parallelism

Ractors were introduced in Ruby 3.0. Ruby 4.0 refines the model and reduces internal contention, making parallel execution more practical.

Basic Ractor usage

r = Ractor.new do
  "Hello from another core"
end

r.take
# => "Hello from another core"

Structured communication with Ractor::Port

port = Ractor::Port.new

producer = Ractor.new(port) do |p|
  p.send("work item")
end

consumer = Ractor.new(port) do |p|
  p.receive
end

consumer.take
# => "work item"

Why this matters for Rails applications

Most Rails apps today rely on process-level concurrency. Ruby 4.0 continues the slow but intentional shift toward safer parallel execution within a single process.

That unlocks future architectural options without forcing a move to an entirely different stack or runtime.

Core language and standard library improvements

Ruby 4.0 also includes a collection of smaller improvements that add up over time.

Improved conditionals

if foo
  && bar
  || baz
  do_work
end

Ruby 4.0 improves parsing and readability in complex multi-line expressions, reducing subtle bugs in legacy conditionals.

Array enhancements

[1, 2, 3, 4].rfind(&:even?)
# => 4

Small additions like this reduce custom utility code that often proliferates in older codebases.

Better error context

Ruby 4.0 enhances error messages by showing both caller and callee context, making it easier to debug layered systems.

def a
  b
end

def b
  raise "boom"
end

a

The resulting stack trace now surfaces more actionable information, which is especially valuable in large applications with deep call chains.

Why We’re Excited about 4.0

At Planet Argon, most of our Ruby work starts with systems that have a history, are in full use by a large customer base, and can’t afford a risky, drawn-out rewrite.

Ruby 4.0 reinforces a belief we have held for years:

You do not need to rewrite your application to modernize it.

We’ll be using the new 4.0 features to:

Help isolate risk (Box)
Help performance evolve independently of application code (ZJIT)
Get better concurrency out of Ruby apps (Ractors)
Reduce friction in our everyday maintenance work

And how about that! None of these requires throwing away working software. :)

Upgrade strategy: How we recommend teams approach Ruby 4.0

Upgrading to Ruby 4.0 should be treated as an engineering initiative, not a version bump.

Here is the strategy we typically recommend.

1. Establish a behavioral baseline

Before upgrading, ensure you have:

A reliable test suite
CI visibility into failures
Basic performance benchmarks

This is not about perfection. It is about confidence.

2. Upgrade Ruby before Rails

Move the Ruby version forward first while holding Rails constant where possible. This isolates runtime changes from framework changes, making failures easier to reason about.

3. Use Ruby Box experimentally

Do not start by restructuring your application. Use Ruby Box in test or tooling contexts first:

Isolated test execution
Dependency experiments
Refactoring spikes

Treat it as a safety tool, not a refactor mandate.

4. Measure, then enable JIT options

Evaluate YJIT and ZJIT in staging or production-like environments. Measure memory, CPU, and latency. Choose deliberately.

Performance gains should be empirical, not assumed.

5. Avoid the rewrite trap

The biggest risk we see is teams using upgrades as justification for a rewrite. Ruby 4.0 explicitly reduces the need for that by improving the runtime itself.

Modernization works best when it is incremental, observable, and reversible.

Closing thoughts

Ruby 4.0 seems designed for giving long-lived systems room to keep evolving. For teams maintaining legacy Ruby and Rails applications, this release is a reminder that stability and progress are not opposites. With the right strategy, they actually reinforce each other!

This post was originally shared on [Planet Argon's blog](https://blog.planetargon.com/blog.

How to Demo Your Application to a New Development Team

Autumn — Thu, 14 Aug 2025 19:00:23 +0000

When you start working with a new development team, one of the first and most valuable things you can do is walk them through your application. It's more than just clicking around—it's about sharing the story of your app: what it does, who it serves, and how it's built.

We’ve seen a lot of client-led demos, and we’ve learned what makes them effective—and what leaves teams guessing. This post outlines a simple framework for walking a development team through your application. It includes key talking points to help you deliver a clear and helpful overview that saves time and builds shared understanding from the start.

We’ll cover:

How to introduce your business and users.
What technical details are most beneficial to share early on.
What’s changed in your app recently—and what’s coming up.
How to prepare the team for emergencies and escalations.
What kind of support you need from the dev team week-to-week.

By the end, you’ll have a helpful checklist for your next application walkthrough.

1. Start with the Big Picture: Your Business and Your Users

As the new team onboards to your application, it will be important to highlight the technical aspects of what the application does. However, something people often miss when demonstrating to a new team is explaining the why behind the application.

What business purpose does your app serve?
Who are your users?
What problems does it solve for them?
How do you interact with those users?

Start from the 30,000-foot view:

→ “Our users are [x] who want a way to [y].”

Then, take on the personality of a daily user:

→ “So if I want to get [y] from the app, I would log in and navigate to [critical page #1] or [critical page #2].”

Finally, show how your team engages with those users:

→ “As a customer service representative, we can pick up a user’s case and [do x] or [do y].”

This context helps the engineering team understand why they’re building and supporting the product, making it easier to navigate the app with purpose instead of aimlessly clicking around.

2. What Does the Application Do?

After covering what the application looks like for users and administrators, it is time to move over to the more technical functions of its structure. A senior engineer, CTO, or technical project manager would best lead this section of the demonstration.

Here, we should aim to answer questions like:

Where is the application hosted?
Is there up-to-date documentation on how to set up the application?
Are there important services that the onboarding team needs to be aware of (like Sidekiq Pro or AppSignal)?

Here are a few key areas to touch on:

Hosting and setup:

→ “When we have a new engineer starting, the first thing we ensure they have access to is [x].”

Application history:

→ “This started as a basic [code framework] app but has since expanded to include [other frameworks/tools].”

Important services:

→ “We use Sidekiq Pro for background jobs and AppSignal for monitoring.”

Known quirks or exceptions:

→ “An important thing that may not be super clear in the documentation is [x], which exists for [y purpose].”

Build process:

→ “When a change is ready, the testing suite runs and then [x] happens.”

These insights give the onboarding team a strong technical foundation to begin working efficiently.

3. Where Does the Application Stand Today?

After giving the team an idea of what the business does and how the application is set up, it’s time to get into the current state. This section aims to give the team a healthy understanding of what new features have been implemented recently, any ongoing issues, and cover important things to be aware of for future work.

What’s new:

→ “In the last three months, we added a new way for users to [x].”

What’s wrong:

→ “We’ve been having issues with [x] and [y], which we [have/haven’t resolved yet].”

What’s bothering you:

→ “It hasn’t happened in a while, but every few months, I worry about [x].”

What’s coming:

→ “In the next two months, the Ops team would like to see [x] happen.”

This helps the team prioritize their focus areas and understand where they can add the most value.

4. Preparing the team for emergencies

Emergencies are never fun, but they happen. Use this part of the demo to walk the team through what to do when something goes wrong.

What do you do when things go poorly?
Where do you look if there is an outage?
How have outages historically escalated to the engineers?
Have there been recurring themes in the recent outages?

How escalations happen:

→ “Historically, [x person/people] are the first to tell us when something is wrong.”

Where to look:

→ “When we get a report, we start by checking [x]. That usually tells us [y].”

Recovery process:

→ “If we need to rollback to a previous version of the app or database, here’s how we typically do that.”

Sharing your existing process gives your new team a sense of confidence and preparedness for when things break.

5. Helping Teams Help You

Finally, wrap up your demo by discussing what a successful working relationship looks like. Be clear about how you like to work, how you prefer to get updates, and what you expect from your dev partners.

For more on how to build collaborative and inclusive developer relationships from day one, check out this episode of Maintainable Software Podcast with April Wensel, where she shares thoughtful insights on navigating legacy code with empathy and intention.

Cadence:

→ “Every Tuesday morning, our operations team meets to review priorities and plan the next few weeks. I need updates on [x] and any [y] incidents before that meeting.”

Preferred processes:

→ “It’s easiest for me if updates are made in [x-way].”

Escalation protocols:

→ “If there’s a new incident or outage, I’m responsible for notifying [x-people]. For that, I need to know [y] and [z].”

Making it happen 🚀

Demos don’t have to be polished or perfect, but they do need to be intentional. A clear, thoughtful walkthrough of your application helps your new engineering team get up to speed faster, make fewer assumptions, and deliver better work sooner.

The more context you give, the more your development partners can support your business goals effectively.

How to Demo Your Application to a New Development Team: A Helpful Guide

Autumn — Wed, 30 Jul 2025 18:42:36 +0000

We’ll cover:

How to introduce your business and users.
What technical details are most beneficial to share early on.
What’s changed in your app recently—and what’s coming up.
How to prepare the team for emergencies and escalations.
What kind of support you need from the dev team week-to-week.

By the end, you’ll have a helpful checklist for your next application walkthrough.

1. Start with the Big Picture: Your Business and Your Users

What business purpose does your app serve?
Who are your users?
What problems does it solve for them?
How do you interact with those users?

Start from the 30,000-foot view:

→ “Our users are [x] who want a way to [y].”

Then, take on the personality of a daily user:

→ “So if I want to get [y] from the app, I would log in and navigate to [critical page #1] or [critical page #2].”

Finally, show how your team engages with those users:

→ “As a customer service representative, we can pick up a user’s case and [do x] or [do y].”

This context helps the engineering team understand why they’re building and supporting the product, making it easier to navigate the app with purpose instead of aimlessly clicking around.

2. What Does the Application Do?

Here, we should aim to answer questions like:

Where is the application hosted?
Is there up-to-date documentation on how to set up the application?
Are there important services that the onboarding team needs to be aware of (like Sidekiq Pro or AppSignal)?

Here are a few key areas to touch on:

Hosting and setup:

→ “When we have a new engineer starting, the first thing we ensure they have access to is [x].”

Application history:

→ “This started as a basic [code framework] app but has since expanded to include [other frameworks/tools].”

Important services:

→ “We use Sidekiq Pro for background jobs and AppSignal for monitoring.”

Known quirks or exceptions:

→ “An important thing that may not be super clear in the documentation is [x], which exists for [y purpose].”

Build process:

→ “When a change is ready, the testing suite runs and then [x] happens.”

These insights give the onboarding team a strong technical foundation to begin working efficiently.

3. Where Does the Application Stand Today?

What’s new:

→ “In the last three months, we added a new way for users to [x].”

What’s wrong:

→ “We’ve been having issues with [x] and [y], which we [have/haven’t resolved yet].”

What’s bothering you:

→ “It hasn’t happened in a while, but every few months, I worry about [x].”

What’s coming:

→ “In the next two months, the Ops team would like to see [x] happen.”

This helps the team prioritize their focus areas and understand where they can add the most value.

4. Preparing the team for emergencies

Emergencies are never fun, but they happen. Use this part of the demo to walk the team through what to do when something goes wrong.

What do you do when things go poorly?
Where do you look if there is an outage?
How have outages historically escalated to the engineers?
Have there been recurring themes in the recent outages?

How escalations happen:

→ “Historically, [x person/people] are the first to tell us when something is wrong.”

Where to look:

→ “When we get a report, we start by checking [x]. That usually tells us [y].”

Recovery process:

→ “If we need to rollback to a previous version of the app or database, here’s how we typically do that.”

Sharing your existing process gives your new team a sense of confidence and preparedness for when things break.

5. Helping Teams Help You

Cadence:

→ “Every Tuesday morning, our operations team meets to review priorities and plan the next few weeks. I need updates on [x] and any [y] incidents before that meeting.”

Preferred processes:

→ “It’s easiest for me if updates are made in [x-way].”

Escalation protocols:

→ “If there’s a new incident or outage, I’m responsible for notifying [x-people]. For that, I need to know [y] and [z].”

Making it happen 🚀

The more context you give, the more your development partners can support your business goals effectively.

Deploying a Ruby on Rails app to DigitalOcean Using Kamal

Autumn — Thu, 24 Jul 2025 00:11:37 +0000

If you’re deploying Ruby on Rails applications to the cloud, you may have explored tools to simplify and streamline the process. Recently, we’ve been experimenting with Kamal, a tool for deploying containerized applications, and we’re excited to share our experience with deploying a Rails app to DigitalOcean using their Managed Database service.

This post introduces Kamal, explains why it’s worth exploring, and walks you through a sample deployment configuration to demystify Kamal and help you decide if it’s the right tool for your next project.

What Is Kamal?

Here's how the official Kamal documentation describes it:

Kamal offers zero-downtime deploys, rolling restarts, asset bridging, remote builds, accessory service management, and everything else you need to deploy and manage your web app in production with Docker. Originally built for Rails apps, Kamal will work with any type of web app that can be containerized.”

In simpler terms, Kamal is a deployment tool designed for containerized applications. Whether you’re managing Rails apps or other containerized projects, Kamal handles complex tasks like asset management, remote builds, and service orchestration. It provides powerful features for those looking to avoid the overhead of Kubernetes while still leveraging Docker-based workflows.

The Case for Kamal: Why It’s Worth Exploring

You may have heard Kamal described as a "Capistrano-like tool for containerized apps." While that description is somewhat accurate, Kamal is much more than that. It stands out for developers who:

Want a simpler alternative to Capistrano.
Are focused on lightweight deployment workflows.
Appreciate a tool that integrates deeply with Rails (but also supports other frameworks).

Kamal offers several unique advantages, making it a compelling choice for deploying containerized applications.

Optimized for Rails

Kamal was initially built with Ruby on Rails in mind, offering built-in support for Rails conventions. But it’s versatile enough to work with any containerized web app, making it a great fit for diverse tech stacks.

Rails 8 Integration

Kamal is tightly integrated with Rails 8, coming pre-installed and leveraging new features like simplified containerization out of the box. This reduces setup time and ensures compatibility with the latest Rails conventions.

Streamlined Asset Management

Kamal automates asset bridging between deployment versions, ensuring static files like CSS and JavaScript are handled seamlessly without downtime. This eliminates the manual asset precompilation headaches often encountered in traditional workflows.

Easy Environment Management

With Kamal, environment variables and secrets are centralized in .kamal/secrets, simplifying managing production settings across servers. This reduces configuration drift and enhances security by keeping sensitive data out of version control.

A Modern Alternative to Capistrano

Kamal modernizes deployment by replacing Capistrano’s script-based approach with a Docker-centric workflow, offering better scalability and consistency. It’s easier to set up for containerized apps while retaining the simplicity Capistrano users love.

Flexible Support for Managed Databases

Kamal integrates effortlessly with managed database services like DigitalOcean’s, allowing you to configure database connections via environment variables without managing database containers. This flexibility simplifies infrastructure while leveraging cloud provider reliability.

Ideal for Small Teams or Solo Devs

Kamal’s lightweight design and minimal setup make it perfect for small teams or solo developers who need efficient deployments without the complexity of Kubernetes. It balances power and simplicity, reducing the learning curve for resource-constrained projects.

Developer-Friendly Debugging Tools

Kamal provides commands that give developers quick access to runtime diagnostics and interactive troubleshooting. These tools streamline issue resolution without requiring external monitoring setups.

Active Community and Documentation

Kamal benefits from a growing community on GitHub and comprehensive official documentation, offering quick support and detailed guides for both beginners and advanced users. This ecosystem ensures you’re never stuck when exploring its features.

Why We Chose a Managed Database Instead of a Database Container

Choosing a managed database service was a deliberate decision that has made our deployment process much simpler and more efficient. With DigitalOcean’s managed database service, many of the operational headaches of managing a database—like backups, scaling, and connection management—are handled automatically. This not only saves time but also ensures that the service provider professionally manages critical tasks like disaster recovery and high availability.

Managed databases also remove the need to configure and maintain database containers, which can be tricky to set up correctly, especially for production environments. Instead of worrying about things like replication, version upgrades, and performance tuning, you can focus entirely on building and improving your application. This approach is a game-changer for small-to-medium apps, where development resources might be limited. It allows developers to deploy confidently, knowing that the database infrastructure is reliable, scalable, and secure.

In our case, DigitalOcean’s managed database service was particularly appealing because of its seamless integration with other DigitalOcean products, intuitive user interface, and competitive pricing. Setting up the database was straightforward, and connecting it to the Rails app required only minor adjustments to configuration files. This simplicity made it easy to get the app up and running quickly, without spending hours on infrastructure setup.

If you're deploying small or medium-sized apps or new to cloud deployments, managed databases are worth considering. They offer a balance of simplicity and robustness that’s hard to achieve with self-managed solutions.

Getting Started with Kamal - Tips, Tools, and Insider Know-How

Kamal is designed to make deployments simple and efficient, but setting up a new tool can always feel a little daunting. Here’s how to get started with Kamal and some helpful tips to make the process smoother.

Prepare Your Environment

Before diving in, ensure you have the following tools and concepts ready:

Docker Installed and Configured: Kamal relies on Docker to build and run containers, so install Docker and familiarize yourself with basics like creating a Dockerfile and running containers. Test it locally with docker run hello-world to confirm it’s working.
SSH Access to Your Server: Kamal uses SSHKit to communicate with your server, so set up SSH keys and verify access with ssh user@your-server-ip. Passwordless login via keys is recommended for automation.
A Cloud Service Provider: Decide where you’ll host your app. Kamal works seamlessly with AWS, Google Cloud Platform, DigitalOcean, and more.
A Deployed App or Sample Rails App: To experiment with Kamal, it helps to have a simple Rails app ready to deploy.

Install Kamal

If you’re using Ruby on Rails 8, Kamal comes pre-installed in your app. For older versions or other frameworks:

Add Kamal to your Gemfile: gem 'kamal'
Run bundle install to install the gem.
Initialize Kamal with: kamal init

This generates config/deploy.yml (your deployment blueprint) and .kamal/secrets (for sensitive data). Add .kamal/ to .gitignore to keep secrets out of version control.

Configure Your `deploy.yml` File

The deploy.yml file defines how Kamal deploys your app. Here’s a starter example for a Rails app on DigitalOcean with a managed database:

service: my-app
image: username/my-app:1.0.0
servers:
  web:
    - 192.168.1.100  # Replace with your server IP
env:
  secret:
    - RAILS_MASTER_KEY
    - PRODUCTION_DB_HOST
registry:
  username: username
  password:
    - KAMAL_REGISTRY_PASSWORD

To connect your Rails app to a managed database like DigitalOcean’s, grab the host, username, and password from your provider’s dashboard, store them in .kamal/secrets, and reference them in deploy.yml under env.secret.

Pro Tips:

Service Name: Match it to your app’s repository name (e.g., my-app) for consistency.
Image Tagging: Use specific versions (e.g., 1.0.0) instead of the latest for easier rollbacks.
Secrets: Store sensitive values like RAILS_MASTER_KEY and PRODUCTION_DB_HOST in .kamal/secrets, not the YAML file.
Roles: Add workers: under servers if using background jobs (e.g., Sidekiq).

Understand the Deployment Workflow

Kamal uses a simple yet powerful workflow for deployments:

Build the Docker Image: Kamal builds your app’s image locally or remotely (configurable in deploy.yml).
Push to a Registry: Upload the image to DockerHub or another registry specified in the registry section.
Deploy: Run: kamal deploy

This pulls the image to your server, starts containers, and performs a rolling restart for zero downtime. If using accessories (e.g., Redis), they’re deployed automatically—no separate accessories flag is needed unless isolating specific updates.

Master Kamal’s Debugging Tools

Kamal includes several built-in commands to simplify debugging:

Logs: View real-time output with:

kamal logs -f

Rails Console: Debug interactively on the server:

kamal app exec --interactive "bin/rails console"

Shell Access: Inspect the container directly:

kamal app exec --interactive bash

Work with Accessories

For services like Redis or Sidekiq, define them as accessories in deploy.yml:

accessories:
  redis:
    image: redis:latest
    host: 192.168.1.100
    port: 6379

Deploy with Kamal deploy, and Kamal manages them alongside your app. Add volumes or environment variables as needed for persistence or configuration.

Example Configuration for Deploying with Kamal

Here’s the deploy.yml for a Rails app on DigitalOcean with their managed database:

service: my-rails-app
image: myusername/my-rails-app:1.0.0
servers:
  web:
    - your-droplet-ip  # From DigitalOcean dashboard
env:
  secret:
    - RAILS_MASTER_KEY
    - PRODUCTION_DB_HOST
registry:
  username: myusername
  password:
    - KAMAL_REGISTRY_PASSWORD
accessories:
  redis:
    image: redis:latest
    host: your-droplet-ip
    port: 6379

Kamal's Community and Documentation

Using a new tool can be much easier with a strong community and resources at your fingertips. Kamal offers both, making learning, troubleshooting, and exploring advanced features simple. Whether you are looking for quick answers, detailed guidance, or inspiration from other developers, tapping into Kamal’s community and documentation will accelerate your journey to mastering this powerful deployment tool.

Visit the Kamal GitHub repository to connect with other users and get quick support.
Explore the official Kamal documentation for advanced features, like load balancing and remote builds.
Follow developers sharing tips on GitHub or blogs (like this one!).

Ready to give Kamal a try?

Explore Kamal's features, or experiment with a simple app to see how it fits your workflow. Whether managing small apps or planning larger deployments, tools like Kamal and managed databases can save you time and effort. Take the first step by trying it out on your next project—you might just discover your new favorite deployment tool! You might even want to check out the Maintainable Podcast episode 'Martin Emde – Ruby Central and the Art of Being Tolerant to Change', where Martin shares insights on effectively managing changes and complexity in Ruby applications.

Managing Tech Debt with a Custom VS Code Extension

Autumn — Thu, 17 Jul 2025 20:07:04 +0000

The Planet Argon engineering team has always faced a common but annoying challenge when tackling technical debt management – when an engineer spotted a refactor opportunity during their coding sessions, they would have to create Jira tickets to track it manually. Switching back and forth from VSCode to Jira like that created several problems for our team:

Context Loss: Important details such as file location, line numbers, and the actual code snippet were frequently omitted when creating tickets for tracking tech debt.
Workflow Disruption: Developers had to switch between VS Code and Jira, breaking their focus and reducing productivity.
Inconsistent Documentation: Technical debt items varied greatly in quality and detail without a standardized process.

We needed a solution that would integrate directly into our development environment and streamline the entire process of capturing and documenting technical debt.

Our Solution: Cherrybomb VS Code Extension

To bridge this gap, we built Cherrybomb, a custom VS Code extension designed specifically to capture technical debt at the moment of discovery. Here’s why we’re excited about it.

We started with a status bar integration that remains visible whenever VS Code is open. This gives developers a constant, unobtrusive reminder that they can quickly flag technical debt. When they spot problematic code, they simply highlight it and click the status bar icon.

Behind the scenes, Cherrybomb immediately performs automatic context capture, collecting the selected code snippet, the file path, and exact line numbers. This ensures no critical information is lost.

The extension then displays an interactive webview form within VS Code that includes:

A dropdown menu populated with our active Jira projects.
Fields for the issue title and description.
A preview of the captured context information.

When the developer submits the form, Cherrybomb authenticates with our Jira Cloud instance and creates a new comprehensive Jira issue that contains all the information collected in the IDE as well as a via-cherrybomb label that makes it easy to filter and find these issues later.

We packaged the extension as a VSIX file and distributed it internally via a secure file-sharing system. This lets our team install and use it without having to publish it to the public VS Code extension marketplace.

Transforming How We Handle Technical Debt

Implementing Cherrybomb transformed our approach to technical debt in several ways.

The most immediate benefit was the elimination of context switching. Developers could now document technical debt without leaving VS Code, letting them keep their focus and create tech debt issues when they have the most context and understanding of the problem.

The quality of our documentation also improved. Every issue now includes precise code snippets, exact file locations, and line numbers. This makes future fixes more efficient, even when addressed by different team members.

Our standardized reporting structure has also improved how we prioritize technical debt across projects. Team leads can now make more informed decisions about which issues to address in upcoming sprints based on consistent, detailed documentation.

The impact on team productivity has been significant:

Time Savings: Developers spend less time on administrative tasks and more time writing quality code
Enhanced Collaboration: Clear, contextual issue tracking has improved communication between team members
Knowledge Sharing: Detailed technical debt tickets serve as learning opportunities for newer team members

The Evolution of Cherrybomb

While Cherrybomb has already made a substantial impact on our workflow, we see several opportunities for enhancement:

Feature Expansion

Adding more formatting options to the webview form for richer issue descriptions
Integrating additional Jira data fields like fix versions and custom labels

Integration Improvements

Connecting with other internal tools to create a more comprehensive technical debt management system
Adding Git integration to capture branch names and automatically update associated Jira issues when code snippets or branches change
Enhancing error reporting and handling for a smoother user experience

User-Driven Refinement

Ongoing collection of feedback from our engineering team to identify friction points
Iterative UI improvements based on real-world usage patterns

Small Tools, Big Impact

Cherrybomb demonstrates that committing to solving very specific workflow problems can have outsized effects on your team’s productivity and code quality. By embedding technical debt management directly into the development environment, we not only improved our documentation and saved time, but we also built our values of code quality and thoughtful refactoring into our devs’ workflows. The success of this project has also inspired us to look for other aspects of our development process that could benefit from similar streamlining.

Did this helpful little tool solve all of our tech debt or dev workflow problems? Of course not. But sometimes the most effective improvements aren't huge sweeping platform changes or introducing new processes. Sometimes, all it takes is building a focused tool that removes specific friction points from everyday workflows.

If you're interested in how we help clients tackle technical debt and improve their development workflows, check out our case studies on Walkenhorst's, I Will Teach You to Be Rich, and Newspaper Club. Each illustrates our commitment to building maintainable, efficient systems.

We Think You’ll Also Enjoy Reading…

FAQs

Q. Can your internal tools like Cherrybomb be adapted for client use?

A. While Cherrybomb is currently an internal tool, its success reflects our broader approach: build or integrate lightweight solutions that reduce friction in everyday workflows. For clients, we often customize tools, recommend integrations, or advise on process improvements to help your team manage tech debt more effectively.

Q. What types of clients benefit most from your technical debt management process?

A. We work best with companies that have long-standing Ruby on Rails applications and want to modernize their codebase. Whether your team is bogged down by legacy code or planning a major upgrade, we bring a thoughtful, practical approach to identifying and tackling the right pieces of debt at the right time.

Q. What benefits has your team seen since using Cherrybomb?

A. We’ve seen significant improvements in developer focus, consistency in technical debt documentation, and team-wide collaboration. Cherrybomb has helped us prioritize tech debt more effectively and reduced time spent on manual ticket creation.

Q. Is Cherrybomb available to the public?

A. No, Cherrybomb was developed as an internal tool and is currently only distributed to our team via a secure file-sharing system. We’ve packaged it as a .vsix file for easy internal installation. But we do build custom tools for our clients.

*This post was originally shared on Planet Argon's blog.

Linear and Jira: Making the Right Call for Your Team’s Workflow

Autumn — Wed, 09 Jul 2025 17:12:56 +0000

When it comes to project management tools, the choice between Linear and Jira isn't just about features—it's about how your team works best. Do you need a lightweight, developer-friendly experience or a platform capable of handling complex workflows and extensive reporting? Understanding the nuances of each tool can help ensure your team stays productive and efficient. Let's explore the key differences, real-world applications, and how to determine which one aligns best with your organization's needs.

Understanding Your Organization's Needs

Size and Structure Matter

Your organization's size and structure are important factors when deciding between Linear and Jira. Are you a lean startup with a flat hierarchy? Or are you a large corporation with layers of middle management and a matrix structure?

Linear excels in simplicity and minimalism, making it an excellent choice for smaller teams or companies with streamlined decision-making.
Jira, on the other hand, offers customization and reporting capabilities, ideal for large organizations with complex workflows and multiple stakeholders.

Who Needs Access?

Another consideration is who will use the tool and how. For example:

Linear is designed with developers in mind. Its Slack integrations, team-managed projects, and focus on triage make it perfect for teams prioritizing speed and collaboration.
Jira is better suited for organizations where transparency and accountability extend to many layers, from operations to engineering managers and beyond.

Insights from Real-World Use Cases

Linear in Action

Michael Kurt, our Project Manager, shared how Linear’s features can simplify workflows:

Using Linear's Triage and Slack integrations, teams can easily manage incoming tasks and stay updated. The system encourages thoughtful comments and careful communication by connecting Linear comments to Slack tags, making collaboration seamless."

Linear also allows team-specific setups, where each product team operates independently without overlapping tickets. This compartmentalization can reduce noise and foster focused collaboration.

Jira’s Strengths

For larger corporations, Jira's robust capabilities shine. As Michael observed:

For companies with a structure like Operations > Product Manager > Project Manager > Engineering Manager > Pod Lead, Jira's extensive customization options ensure everyone's needs are met. However, it can become overwhelming if too many layers are involved in ticket management."

Jira's detailed reporting and dashboard features make it a favorite for organizations that need to monitor progress across multiple teams and departments.

Key Questions to Ask

What Are Your Growth Goals?

If your company is scaling rapidly, consider the future:

Will adding more layers to your structure require a tool with broader reporting capabilities?
Do you prioritize lightweight tools to maintain agility as you grow?

How Much Transparency Do You Need?

Both tools offer transparency, but in different ways:

Linear's Slack integration keeps communication tight within teams.
Jira's dashboards and reports are ideal for sharing progress with external stakeholders and leadership.

The Verdict: Linear or Jira?

There's no one-size-fits-all answer, but here's a quick summary:

Factor	Linear	Jira
Team Size	Small to mid-sized teams	Large, complex organizations
Hierarchy	Flat or minimal layers	Matrix or multi-layered structures
Transparency Needs	Team-level visibility	Organization-wide reporting
Ease of Use	Simple and intuitive	Robust but can be overwhelming
Integrations	Excellent Slack integration	Wide range of integrations

Still Undecided? Test Both

Both Linear and Jira offer trial periods. Engage your team and run a pilot project with each tool. Pay attention to ease of onboarding, user adoption, and how well each tool supports your workflows.

Choosing between Linear and Jira requires understanding your organization's size, structure, and goals. Whether you aim for efficiency or comprehensive control, the right tool can help your teams do their best work. Take the time to evaluate your needs—your future self (and your team) will thank you.

Hotwire for Rails Developers: Keeping UI Fast and Maintainable

Autumn — Thu, 22 May 2025 16:11:15 +0000

The Challenge of Modern Frontend in Rails

Rails developers often face a dilemma: Should they stick with built-in Rails tools or go all-in on React for interactivity? The rise of JavaScript-heavy apps has made Rails projects harder to maintain. Many teams feel forced to separate the frontend and backend, leading to extra complexity, API management, and more dependencies to manage. While React is powerful, it often adds more overhead than necessary for traditional Rails apps.

But what if you could build a modern, dynamic UI without the extra complexity?

Enter Hotwire – A Rails-native alternative

Hotwire embraces the power of server-rendered HTML while still delivering a fast, interactive user experience. Instead of shifting everything to the frontend, it keeps Rails at the core and handles interactivity in a way that feels natural to the framework.

With Hotwire, you don’t need to set up a separate API, manage client-side state, or keep up with endless JavaScript updates. You get the best of both worlds—modern UI interactions without the React overhead.

What is Hotwire? A Rails Developer’s Perspective

Hotwire is a framework that brings modern UI interactivity to Rails without the complexity of a full JavaScript frontend. It keeps things simple by relying on server-rendered updates instead of pushing everything to the client.

At its core, Hotwire = Turbo + Stimulus:

Turbo – Handles fast page loads, real-time updates, and partial page changes without writing custom JavaScript. This means forms, lists, and UI interactions feel instant without managing the frontend state.
Stimulus – A small JavaScript framework that adds enhancements where needed. Unlike React, it doesn’t take over the UI—it simply connects behavior to existing HTML elements.

Why Hotwire Fits Rails So Well

Rails has always been about "convention over configuration." Instead of forcing developers to make endless decisions about frontend architecture, Hotwire follows Rails’ principles:

It works out of the box with Rails' existing tools.
It keeps backend logic in Rails instead of spreading it across multiple layers.
It reduces unnecessary complexity by avoiding heavy JavaScript frameworks.

With Hotwire, you don’t need to rework how your app is built—you just extend Rails' strengths to create a fast, interactive UI with minimal effort.

When to Use Hotwire Instead of React

There are many cases where React is overkill in a Rails app. If you don’t need a full-blown single-page application (SPA), React might be adding more complexity than value.

When React is Overkill

Your app isn’t an SPA, but it still has some interactive elements.
You’re using React for only a few small features (modals, forms, or UI updates).
You’re dealing with long build times, slow initial page loads, or performance issues caused by client-side rendering.

When Hotwire Shines

You want to keep your app fully within Rails without adding a separate frontend framework.
You need real-time updates but don’t want to set up WebSockets manually.
You prefer less JavaScript and more of Rails' simplicity.

Hotwire is a great choice for those who want modern UI features without the complexity of a JavaScript-heavy setup. It lets you build fast, interactive apps while keeping your Rails app clean and maintainable.

Hotwire in Action: How We Use it at Planet Argon

In our recent project for Olsson Roofing, we built a mobile-first web application for field maintenance workers. Instead of using React as we typically would, we embraced Hotwire—Rails' modern approach to building responsive web applications without writing much JavaScript.

Turbo Streams for Form Steps

One of our main uses of Hotwire was implementing a multi-step form process for roof inspections. We used Turbo Streams to navigate different form sections without full page reloads. When users submit a form step, the controller responds with a Turbo Stream that updates just the form content:

The form partial is structured to work with these Turbo Stream updates:

This approach allowed us to:

Keep each form step isolated and maintainable
Provide instant feedback when moving between steps
Maintain a smooth user experience on mobile devices with slower connections
Handle form validation errors without losing context

Stimulus for Enhanced Interactivity

While Turbo handled most of our needs, we used Stimulus for client-side interactions that required JavaScript. Looking at our views, we can see how we connected Stimulus controllers:

This data-controller="form" attribute connects to our form controller that handles image previews:

The controller is automatically loaded thanks to our Stimulus configuration in app/javascript/controllers/index.js:

What We Learned

The Good

Productivity Boost: Hotwire allowed us to build interactive features with significantly less code than a React-based approach.
Performance: Thanks to Turbo's smart HTML streaming, the app feels snappy even on slower mobile connections.

The Challenging

Mental Model Shift: Coming from React, it took time to shift our thinking from client-side state management to server-side HTML updates.
Debugging: Initially, debugging Turbo Frame and Stream issues was tricky since they operate differently from traditional AJAX requests.
Documentation: While Hotwire's documentation is good, finding solutions for edge cases sometimes required diving into source code or community discussions.

What We'd Do Differently

Frame Organization: We would better organize our Turbo Frames hierarchy. For example, we could have nested frames for related form sections to better manage state:

Stimulus Controllers: Instead of the somewhat monolithic form controller we ended up with, we would create more focused, reusable stimulus controllers.
Error Handling: We'd implement more robust error handling for Turbo requests, possibly with a dedicated error Stimulus controller:

FAQ’s and Resources

"Can Hotwire handle complex UIs?" → Yes, but it requires rethinking how you structure frontend logic.
"What about existing React components?" → Hybrid approach: Keep React where needed and transition the rest.
"Is it hard to learn?" → If you know Rails, you can pick up Hotwire fast—here are some of our favorite resources.
- Hotwired.dev
- Hotwire Native for Rails Developers by Joe Masilotti
- From React to Hotwire – An Unexpected Journey webinar from Arkency
- Hotwire for Rails Developers course by Pragmatic Studio
- Hotwire Spark: live reloading for Rails applications by 37 Signals

Key Takeaways

Our experience with Hotwire has been largely positive. While there was a learning curve, the benefits of simpler code, better performance, and enhanced reliability made it a great choice for this mobile-first application. The framework's approach to progressive enhancement particularly shined in our use case, where network connectivity couldn't be guaranteed.

We're excited to continue using Hotwire for future projects, applying the lessons we've learned to build even better applications. The framework's alignment with Rails' "convention over configuration" philosophy means we can focus more on solving business problems and less on technical implementation details.

Also! Listen to Joel Hawksley discuss how frontend complexity affects maintainability and why simplicity matters on Maintainable Podcast: The Hidden Costs of Frontend Complexity.

We Think You'll Also Enjoy Reading...

FAQ's

Q: "What are the limitations of Hotwire?"

A: Hotwire simplifies building interactive Rails applications but may fall short for extremely complex, state-heavy apps typically suited for full JavaScript frameworks like React or Vue. While great for most Rails projects, it may require additional custom JavaScript or third-party integrations to handle sophisticated frontend logic or highly interactive UI components.

Q: "Can I use Hotwire with existing Rails applications?"

A: Yes! Hotwire is designed to integrate seamlessly into existing Rails apps. You can incrementally adopt it by replacing specific UI components or interactions with Turbo and Stimulus without rewriting your entire frontend.

Q: "How does Hotwire handle complex interactions?"

A: Hotwire manages complex interactions using Turbo for seamless partial page updates and Stimulus for targeted JavaScript behavior. Together, they allow developers to handle rich, interactive experiences without heavy reliance on complex JavaScript frameworks, keeping your UI maintainable and performant.

This post was originally posted on the Planet Argon blog.

How to Demo Your Application to a New Development Team: A Helpful Guide

Autumn — Wed, 23 Apr 2025 20:07:46 +0000

Part 1 in our series: Onboarding a New Development Team

We’ll cover:

How to introduce your business and users.
What technical details are most beneficial to share early on.
What’s changed in your app recently—and what’s coming up.
How to prepare the team for emergencies and escalations.
What kind of support you need from the dev team week-to-week.

By the end, you’ll have a helpful checklist for your next application walkthrough.

1. Start with the Big Picture: Your Business and Your Users

What business purpose does your app serve?
Who are your users?
What problems does it solve for them?
How do you interact with those users?

Start from the 30,000-foot view:

→ “Our users are [x] who want a way to [y].”

Then, take on the personality of a daily user:

→ “So if I want to get [y] from the app, I would log in and navigate to [critical page #1] or [critical page #2].”

Finally, show how your team engages with those users:

→ “As a customer service representative, we can pick up a user’s case and [do x] or [do y].”

This context helps the engineering team understand why they’re building and supporting the product, making it easier to navigate the app with purpose instead of aimlessly clicking around.

2. What Does the Application Do?

Here, we should aim to answer questions like:

Where is the application hosted?
Is there up-to-date documentation on how to set up the application?
Are there important services that the onboarding team needs to be aware of (like Sidekiq Pro or AppSignal)?

Here are a few key areas to touch on:

Hosting and setup:

→ “When we have a new engineer starting, the first thing we ensure they have access to is [x].”

Application history:

→ “This started as a basic [code framework] app but has since expanded to include [other frameworks/tools].”

Important services:

→ “We use Sidekiq Pro for background jobs and AppSignal for monitoring.”

Known quirks or exceptions:

→ “An important thing that may not be super clear in the documentation is [x], which exists for [y purpose].”

Build process:

→ “When a change is ready, the testing suite runs and then [x] happens.”

These insights give the onboarding team a strong technical foundation to begin working efficiently.

3. Where Does the Application Stand Today?

What’s new:

→ “In the last three months, we added a new way for users to [x].”

What’s wrong:

→ “We’ve been having issues with [x] and [y], which we [have/haven’t resolved yet].”

What’s bothering you:

→ “It hasn’t happened in a while, but every few months, I worry about [x].”

What’s coming:

→ “In the next two months, the Ops team would like to see [x] happen.”

This helps the team prioritize their focus areas and understand where they can add the most value.

4. Preparing the team for emergencies

Emergencies are never fun, but they happen. Use this part of the demo to walk the team through what to do when something goes wrong.

What do you do when things go poorly?
Where do you look if there is an outage?
How have outages historically escalated to the engineers?
Have there been recurring themes in the recent outages?

How escalations happen:

→ “Historically, [x person/people] are the first to tell us when something is wrong.”

Where to look:

→ “When we get a report, we start by checking [x]. That usually tells us [y].”

Recovery process:

→ “If we need to rollback to a previous version of the app or database, here’s how we typically do that.”

Sharing your existing process gives your new team a sense of confidence and preparedness for when things break.

5. Helping Teams Help You

Cadence:

→ “Every Tuesday morning, our operations team meets to review priorities and plan the next few weeks. I need updates on [x] and any [y] incidents before that meeting.”

Preferred processes:

→ “It’s easiest for me if updates are made in [x-way].”

Escalation protocols:

→ “If there’s a new incident or outage, I’m responsible for notifying [x-people]. For that, I need to know [y] and [z].”

Making it happen 🚀

The more context you give, the more your development partners can support your business goals effectively.

We Think You’ll Also Enjoy Reading…

FAQ’s

Q: Before demoing my application to a new development team, what should I prepare?

A: Before your demo, jot down a few notes about your app’s core users, business goals, recent features or bugs, and any known technical quirks. Sharing key links (like documentation or staging credentials) in advance is also helpful.

Q: Who should lead the application demo on our side?

A: Ideally, the demo should be a team effort: a product owner or project manager can provide business context while a senior engineer or technical lead can walk through the architecture and infrastructure details.

Q: What if I don’t have documentation for some parts of the app?

A: That’s totally okay—your demo helps fill in those gaps. The development team can also assist you in documenting things as they go. Check out our post on Ruby on Rails Code Audits: 8 Steps to Review Your App to learn how we uncover undocumented parts of apps.

Q: How long should the demo be?

A: Plan for around 30–60 minutes, depending on the complexity of your app. It’s okay if not everything is covered in one sitting—this initial demo is just the start of the onboarding process.

DEV Community: Autumn

Before You Rebrand: A Second Act Approach to Marketing

The rewrite reflex

The second act approach to marketing

When Reporting Quietly Becomes the Slowest Part of your Rails app

The pattern we keep running into

A shift in how we approach reporting

What tends to work better in practice

We’re walking through this LIVE

Ruby 4.0 and Ruby Box: What Changed and How to Upgrade Safely

Ruby Box: Isolation without abandoning Ruby’s flexibility

Basic example

Selectively exposing behavior

Why this matters in real applications

ZJIT: A new foundation for Ruby performance

Enabling ZJIT

What changes in practice

Ractors: Continued progress toward true parallelism

Basic Ractor usage

Structured communication with Ractor::Port

Why this matters for Rails applications

Core language and standard library improvements

Improved conditionals

Array enhancements

Better error context

Why We’re Excited about 4.0

Upgrade strategy: How we recommend teams approach Ruby 4.0

1. Establish a behavioral baseline

2. Upgrade Ruby before Rails

3. Use Ruby Box experimentally

4. Measure, then enable JIT options

5. Avoid the rewrite trap

Closing thoughts

How to Demo Your Application to a New Development Team

1. Start with the Big Picture: Your Business and Your Users

2. What Does the Application Do?

3. Where Does the Application Stand Today?

4. Preparing the team for emergencies

5. Helping Teams Help You

Making it happen 🚀

How to Demo Your Application to a New Development Team: A Helpful Guide

1. Start with the Big Picture: Your Business and Your Users

2. What Does the Application Do?

3. Where Does the Application Stand Today?

4. Preparing the team for emergencies

5. Helping Teams Help You

Making it happen 🚀

Deploying a Ruby on Rails app to DigitalOcean Using Kamal

What Is Kamal?

The Case for Kamal: Why It’s Worth Exploring

Optimized for Rails

Rails 8 Integration

Streamlined Asset Management

Easy Environment Management

A Modern Alternative to Capistrano

Flexible Support for Managed Databases

Ideal for Small Teams or Solo Devs

Developer-Friendly Debugging Tools

Active Community and Documentation

Why We Chose a Managed Database Instead of a Database Container

Getting Started with Kamal - Tips, Tools, and Insider Know-How

Prepare Your Environment

Install Kamal

Configure Your deploy.yml File

Understand the Deployment Workflow

Master Kamal’s Debugging Tools

Work with Accessories

Example Configuration for Deploying with Kamal

Kamal's Community and Documentation

Ready to give Kamal a try?

Managing Tech Debt with a Custom VS Code Extension

Our Solution: Cherrybomb VS Code Extension

Transforming How We Handle Technical Debt

The Evolution of Cherrybomb

Small Tools, Big Impact

We Think You’ll Also Enjoy Reading…

FAQs

Q. Can your internal tools like Cherrybomb be adapted for client use?

Q. What types of clients benefit most from your technical debt management process?

Q. What benefits has your team seen since using Cherrybomb?

Configure Your `deploy.yml` File