DEV Community: Jeroen Boers

How and why I rebuilt my website from WordPress to EmDash

Jeroen Boers — Fri, 03 Apr 2026 11:53:10 +0000

For a long time, my website lived on WordPress with Elementor. That setup did something important for us: it made the site editable for my cofounder without needing me for every small change. That part genuinely mattered, and I do not want to pretend otherwise. When you are building something together, having a visual editor is useful. It lowers the barrier to making content changes, and it keeps the website from becoming "the developer’s problem" every single time something needs to be updated.

Still, over time I noticed I was starting to avoid working on the site. Not because I had run out of ideas, but because improving it had become annoying in a very specific way. Every time I wanted to tweak styling, clean up layout, improve structure, or make broader SEO changes, I felt like I had to fight through layers of builder settings, theme behavior, and plugin logic. Nothing was impossible, but very little felt clean.

That was the real problem for me. Elementor solved the editing problem, but it made the development side feel heavier and more opaque than I wanted. WordPress added to that feeling. Need a feature? Probably a plugin. Need another feature? Probably another plugin. Need to update everything? Hopefully nothing breaks. Even when things were working, the site often felt more fragile than it should have.

At the same time, I had a pretty clear idea of how I wanted to work on the site going forward. I wanted the frontend to live in code again in a way that made sense to me. I wanted to improve design and SEO more systematically. I wanted to use AI tools and coding agents to help with real improvements, not just random copy suggestions. I wanted the site to feel like software again.

That is what pushed me toward EmDash.

What attracted me was not that it was new. I was not looking for novelty. I was looking for a setup that gave me a CMS without making the frontend feel like a black box. Once I decided to migrate, I realized pretty quickly that I did not want to treat it like a literal one-to-one port. I was not interested in dragging all of the old implementation details into a new system. What I wanted was to extract the important parts of the current site and rebuild it properly.

That turned out to be the right mental model for the whole project.

The idea that made the migration manageable

Instead of thinking, "How do I recreate my WordPress site in EmDash?", I started thinking, "How do I turn my current website into a specification?"

That specification had a few parts:

the visual style
the exact routes I wanted to preserve
the page types behind those routes
the content itself
the SEO rules I did not want to accidentally break

Once I had those written down, the migration stopped feeling like a giant vague project and started feeling like a series of smaller, solvable tasks.

What I actually did

The process was more structured than glamorous. I did not open EmDash and start blindly building pages. I first tried to understand what my existing site actually was.

1. Extract the design language from the current site

I started with a screenshot of my homepage. I sent that to ChatGPT and asked it to extract the site’s design system in a way that would be useful for implementation.

I did not ask for generic design feedback. I asked for something practical.

For reference, this is what we started out with:

For example, this was the kind of prompt I used:

I am rebuilding this website in a new stack.

Based only on this screenshot, extract the visual system in a way that an AI coding agent can use.

Please describe:
- primary, secondary, accent, background, surface, border, and muted colors
- typography style and likely heading hierarchy
- spacing rhythm
- button styles
- card styles
- border radius and shadow language
- what feels intentional in the design
- what should stay the same in a rebuild

Output as a markdown design-system document.

The output became a file in my project that looked something like this:

# Style system

## Colors
- Primary: dark blue
- Accent: green
- Background: warm off-white
- Surface: white
- Borders: light gray
- Text: near-black

## Typography
- Modern sans-serif
- Large bold headings
- Clean readable body text
- Friendly but product-focused tone

## UI style
- Rounded buttons
- Soft shadows
- Generous spacing
- Clean cards with subtle separation

This sounds simple, but it helped a lot. It gave me a reference point that was more useful than "make it feel like the old site."

2. Extract every route from the sitemap

This was the SEO-sensitive part, and probably one of the most important steps in the whole migration.

I took my sitemap or sitemaps from the WordPress site and sent them to ChatGPT with a prompt to extract all public routes and group them by type.

Something like this:

Here are my sitemap URLs.

Extract every indexable route and preserve the exact pathnames.

Group them by page type:
- homepage
- marketing page
- article
- article index
- category page
- author page
- legal page
- utility page

Also tell me:
- which routes should definitely stay identical for SEO
- which routes share a common template
- which pages are likely generated from the same content model

Output as a markdown route inventory.

That gave me a real inventory instead of a vague idea of what existed.

A simplified version looked like this:

# Route inventory

## Core pages
- /
- /about
- /pricing
- /contact

## Blog
- /blog
- /blog/my-first-post
- /blog/another-post

## Categories
- /category/shopify
- /category/seo

## Legal
- /privacy-policy
- /terms-of-service

This became one of my most important migration documents. It meant I had a clear list of what needed to survive the rebuild exactly as-is.

3. Reduce the site to page types

Once I had the routes, I grouped them into templates. This step made the project feel much smaller.

A site with 40 pages sounds like a lot. A site with 5 page types sounds very doable.

My page types looked roughly like this:

# Page types

## Homepage
Hero, supporting sections, trust, CTA, footer

## Standard page
Intro, flexible content blocks, CTA

## Article page
Title, metadata, article body, related content

## Article index
List/grid of articles with pagination or categories

## Simple content page
Minimal layout for legal or basic informational content

This helped a lot when working with both Stitch and coding agents, because I was no longer asking for "all my pages." I was asking for a homepage template, an article template, a standard page template, and so on.

Using Stitch without letting it take over

After I had a style document and route/page-type docs, I used them to create prompts for Google Stitch.

The main thing that helped here was not using Stitch like a magical website generator. I treated it more like a design assistant for the major page types.

So instead of asking it to rebuild the entire site, I would ask it for a strong homepage direction, or a clean article page layout, based on the style system I had already extracted.

For example, for the homepage I would use a prompt like this:

Create a homepage for a modern software website.

Use the attached style-system document as the source of truth.
The tone should feel friendly, premium, and clear, not flashy.

Structure:
- hero
- proof or trust section
- problem/solution section
- feature grid
- how it works
- FAQ
- final CTA
- footer

This will later be implemented in Astro/EmDash, so keep it realistic and reusable.

For the article page, something more like this:

Create a long-form article page for a technical/product-focused site.

Requirements:
- strong readability
- generous whitespace
- good room for code examples
- metadata near the top
- optional table of contents
- related content section
- visually clean, not overdesigned

This will later be implemented in Astro/EmDash.

That gave me a nice starting point without making me feel locked into the generated result.

Setting up EmDash locally

Once the planning was solid enough, I set up the new project locally.

This was honestly one of the nicest parts of the migration. After spending enough time in WordPress and Elementor, being back in a normal project with files, structure, and code felt great.

At a high level, the setup looked like this:

npm create emdash@latest

Or if you are working from the repo directly:

git clone https://github.com/emdash-cms/emdash.git
cd emdash
pnpm install
pnpm build

After that, I chose a starting point, ran the site locally, and began shaping the frontend properly.

The important thing here is that I did not start by rebuilding random pages. I started with the shared system.

What I built first

This is one of the parts where being a bit methodical saves a lot of time later.

I started with the things that everything else depends on:

layout shell
header
footer
max-width containers
typography rules
button styles
card styles
spacing rules
shared content sections

That gave me a real visual foundation.

Only after that did I start building actual page templates:

homepage
standard page
article page
article index

Then I mapped real routes onto those templates.

This order matters more than it sounds. If you start by generating pages one by one, especially with AI involved, you can end up with a weird pile of near-duplicate components. Starting with the shared design system keeps things much more sane.

Connecting Stitch MCP to Codex or Claude

This was one of the parts I was most curious about going in, because it is where the workflow starts to become much more agent-friendly than a typical WordPress setup.

In my case, I connected the Stitch MCP flow to Codex. The goal was not to let AI "take over the website." The goal was to give the coding agent enough structured context that it could actually be helpful.

That context included:

the design-system file
the route inventory
the page-types document
the project files themselves
the Stitch output for the relevant page types
the EmDash project conventions

The result was that I could ask the agent for very concrete work, like:

Read:
- docs/migration/style-system.md
- docs/migration/routes.md
- docs/migration/page-types.md

Then:
- implement the homepage using reusable components
- preserve the exact homepage route
- keep spacing and typography aligned with the style document
- use the Stitch design only as inspiration, not as literal final code
- document anything unclear

That worked much better than the kind of AI workflow I could have used in WordPress, because the system was much easier to reason about. The agent was operating on actual project files, not trying to untangle page-builder markup and plugin settings.

Put the migration docs inside the repo

This was such a small thing, but it made the whole process better.

I created a structure like this:

docs/
  migration/
    style-system.md
    routes.md
    page-types.md
    content-notes.md

That meant the project itself contained the context for the migration.

It also meant I was not constantly re-explaining everything to the agent. I could point it to files and say, "work from these." That makes a bigger difference than I expected.

Content migration: let the platform do the boring part

For content itself, I tried to be practical.

I did not want to manually recreate every article or page using AI. That sounded slow, error-prone, and generally miserable. The much better approach was to let EmDash handle the WordPress content migration path where possible, then use AI for the work around it.

That meant AI was helping with:

structure
prompts
route mapping
template recreation
cleanup
implementation
content QA

Instead of helping with:

manually copying article number 37 into a new file at 1 AM

That split felt right to me.

The actual guide part: how I would recommend doing this

If you want the short version of the process, this is the order I would recommend.

Migration checklist

export or document the current site
capture the visual style from screenshots
extract all routes from the sitemap
group routes into page types
generate page-type directions in Stitch
set up EmDash locally
add migration docs into the repo
build shared layout and components first
build templates second
migrate content
map every old route to a real page
QA the result before launch

Minimal file structure that worked well for me

my-site/
  docs/
    migration/
      style-system.md
      routes.md
      page-types.md
      content-notes.md
  src/
    components/
    layouts/
    pages/

Example of a practical migration prompt for an agent

Read these files first:
- docs/migration/style-system.md
- docs/migration/routes.md
- docs/migration/page-types.md

Goal:
Rebuild the current WordPress site in EmDash while preserving existing public routes.

Rules:
- preserve route paths exactly unless documented otherwise
- build reusable components instead of one-off page sections
- keep the visual style aligned with style-system.md
- recreate templates first, then wire up routes
- document any route or content mismatch

Example of a good sanity-check list before launch

- [ ] homepage rebuilt
- [ ] standard page template rebuilt
- [ ] article template rebuilt
- [ ] blog index rebuilt
- [ ] important routes preserved exactly
- [ ] metadata checked
- [ ] internal links checked
- [ ] redirects added if needed
- [ ] content imported
- [ ] mobile layout checked
- [ ] forms and CTAs tested

What changed for me after the rebuild

The biggest difference is that the website now feels like something I can actually work on properly again.

That might sound obvious, but it is hard to overstate how much better that feels. If I want to improve the design system, I can do that in code. If I want to improve internal linking, metadata handling, or article layout, I can do that in code too. If I want AI to help me identify weak pages, improve templates, or suggest structural changes, I can point it at a system that actually makes sense.

That was really the whole point of the migration.

I was not trying to make the site dramatically different for the sake of it. I was trying to make it easier to own, easier to improve, and less annoying to work on.

A few things I would do the same way again

A few parts of this process were much more helpful than I expected:

extracting the style system before touching code
extracting all routes before touching code
thinking in page types instead of individual pages
keeping migration docs inside the repo
building the shared system before the templates
using AI for structure and implementation help, not for blind content recreation

Those were the parts that made the migration feel controlled instead of chaotic.

A few things I would avoid

There are also a few traps I would try to avoid if I had to do it again.

I would not start by trying to recreate every page exactly, one by one. That is a good way to turn the project into a slog.

I would not let design tools generate production structure without checking whether the result is actually reusable.

I would not casually change routes during the migration just because a different URL pattern looks nicer.

And I definitely would not keep all the important migration context in my head or in random chat tabs. Writing it down inside the project is worth the small effort.

Final thoughts

I do not think WordPress and Elementor are bad tools. They solved real problems for us at a certain stage. My cofounder could edit the site visually, and that was useful. But eventually I wanted something that gave me more control, less black-box behavior, and a better foundation for improving the website over time.

That is what made this migration worth it for me.

The interesting part was not just moving to a new CMS. The interesting part was changing the shape of the work. Instead of treating the old website as something I had to keep patching, I treated it as something I could analyze, document, and rebuild properly.

That made the whole process much less intimidating than I expected.

And maybe that is the nicest surprise in projects like this. Once you stop thinking of a migration as one giant leap and start treating it like a series of very boring, very clear steps, it becomes a lot more doable.

If you want to check out what we're building (the old site) go to https://addora.app

I'll be rolling out the new app this afternoon, and I'm super excited about it!

Next.js 16.2 Shows What an AI-Native Framework Actually Looks Like

Jeroen Boers — Tue, 24 Mar 2026 09:41:36 +0000

Are people moving away from Next.js, or just getting less patient with it?

Over the past year, the mood around Next.js has shifted. It is still widely used, but the excitement is more mixed than it used to be. A lot of developers have become frustrated with the size of the framework’s mental model, especially around the App Router, caching, rendering boundaries, and the growing number of rules you need to keep in your head to understand why something behaves the way it does. Some teams have moved away from it entirely, usually for reasons that have less to do with ideology and more to do with local development performance or the feeling that too much of the framework has become implicit.

I understand that reaction. Next.js is not a lightweight layer over React anymore. It is a full application runtime with strong opinions about rendering, data fetching, caching, bundling, and deployment. That makes it more capable, but it also makes it easier to feel like you are working inside a large system rather than a simple library.

Even so, I still enjoy working with it. When Next.js is moving in the right direction, it solves a real problem: how to build React applications with strong full-stack defaults without spending half your time assembling the stack yourself. That is why Next.js 16.2 stands out to me. Not because it makes the framework simple again, but because it shows a more coherent direction.

The performance side still matters

The obvious part of the release is performance. Next.js 16.2 puts real emphasis on making the development loop faster, especially through Turbopack. That matters more than many framework discussions admit. A complicated framework becomes much harder to tolerate when every change takes too long to rebuild, reload, or stabilize.

If local startup is slow and feedback is delayed, the cost is not just inconvenience. It changes how willing developers are to experiment, refactor, or investigate problems properly. A framework that wants to own more of the application stack has to earn that by keeping the loop tight.

The more important shift is legibility

That is only half of what makes 16.2 interesting, though. The more important change is that Next.js is starting to expose the project in a way that makes it easier for an AI agent to operate on it without guessing. That is a more meaningful shift than simply adding some assistant tooling.

It changes the assumptions behind the framework. Instead of treating the codebase as something only a human developer will inspect directly, Next.js now assumes that another system may enter the repository, read local instructions, inspect runtime signals, and make changes based on structured context rather than intuition.

`AGENTS.md` is a small file with a big implication

The clearest example is AGENTS.md. New projects now include this file by default, and the default rule is deliberately direct: before doing any Next.js work, read the relevant docs from node_modules/next/dist/docs/, because the installed docs are the source of truth and training data may be outdated.

That is a small detail, but it says something important about the design. The framework is no longer assuming that broad prior knowledge is good enough. It is pushing both humans and agents toward local, version-matched documentation instead of relying on memory or stale examples.

Local docs beat vague prior knowledge

That is a technically sensible move. One of the main failure modes in AI-assisted development is version drift. A model may understand a framework well in the abstract while still being wrong about the exact behavior of the version that is installed.

In a framework like Next.js, where small differences in caching, routing, or rendering semantics can matter a lot, that kind of mistake is expensive. Shipping the docs with the package and explicitly telling the agent to read them first is a practical way of reducing that risk. It turns framework knowledge from something probabilistic into something grounded in the actual dependency tree.

Shared debugging surfaces matter

The same pattern shows up in the new logging and debugging changes. Browser logs can now be forwarded to the terminal during development, which matters because an agent operating mostly through the shell does not have natural access to the browser console.

That sounds minor until you think about how much frontend debugging depends on signals that exist only in the browser. If those signals remain trapped in a context the agent cannot see, then the agent is forced to work from indirect descriptions. Moving that information into the terminal makes it part of a shared debugging surface for both people and tools.

The dev server state is becoming explicit

The new dev server lock file is another good example. When a development server is already running, Next.js now records structured information about that process, including things like PID and port, and uses it to avoid the familiar mess of duplicate dev servers started in the same project.

For a human developer, that is a nice quality-of-life improvement. For an agent, it is more important than that. Agents are much more likely to blindly start processes unless the environment tells them clearly what already exists. A file like that is not flashy, but it is exactly the kind of operational detail an AI-native workflow needs.

Browser-aware tooling changes the shape of debugging

The experimental browser-aware tooling pushes the same idea further. Instead of forcing an agent to reason about the state of the application from code alone, Next.js is beginning to expose browser context, diagnostics, and framework-level information in a structured way.

That matters because many of the hardest frontend problems are not purely static code problems. They involve the relationship between server-rendered output, hydration, client state, network behavior, and framework internals. If the framework can make that state inspectable in a machine-usable form, then automated assistance becomes much more reliable.

What “AI-native” should mean

This is why I think “AI-native framework” is the right description here. A framework with AI features could just mean some code generation layered on top of the existing product. That is not very interesting.

An AI-native framework is different. It changes the environment so that a machine actor has access to the same kinds of grounding mechanisms that serious human workflows depend on: local documentation, explicit repository instructions, shared diagnostics, and machine-readable operational state. The point is not to make the framework generate more code. The point is to make it possible for automated systems to act with fewer blind spots.

Performance and legibility are the same story

I also think this fits naturally with the performance work in 16.2. Faster rebuilds and faster refreshes reduce mechanical latency. Files like AGENTS.md, bundled docs, terminal-forwarded logs, and structured dev server state reduce interpretive latency.

One makes it faster to test a change. The other makes it easier to understand what should be changed in the first place. Those are different problems, but they reinforce each other. If a framework is going to be used in workflows where humans and agents collaborate, both kinds of latency matter.

Why I still like working with Next.js

None of this means the criticism of Next.js goes away. The framework is still complex, and many of the frustrations people have with it are reasonable. It still asks developers to understand a lot of framework behavior that is not obvious at first glance.

But 16.2 is interesting because it does not respond to that situation with more abstraction or more marketing language. It responds by making the system more observable, more explicit, and faster to work with. That is a much better direction.

That is also why I still like working with Next.js even while understanding why some people are leaving it. The framework is at its best when it reduces accidental complexity without hiding too much of the real model. For a while, it felt like Next.js risked becoming both more powerful and less legible at the same time.

What is notable about 16.2 is that it pushes back against that. It suggests that framework design is no longer only about rendering strategy or bundler speed. It is also about whether the project can explain itself clearly enough for both a developer and an agent to work on it without constantly guessing.

What do you think?

Are we looking at a genuinely better direction for frontend frameworks here, or just a more sophisticated way of managing growing complexity? And if you are still using Next.js, does 16.2 make you more confident in where it is going, or not really?

A beginner’s guide to setting up your first Shopify app using Ruby on Rails

Jeroen Boers — Sat, 21 Mar 2026 15:48:46 +0000

Hi there, my name is Jeroen, and this is my first article on dev.to.

I am a Senior Ruby on Rails developer, and over time I have ended up building quite a few Shopify apps. If you are curious about Shopify app development and have at least touched Ruby on Rails before, this article should be a nice starting point.

We are not going to discuss every possible concept around Shopify apps yet. That would just make this article much longer and more confusing than it needs to be.

Instead, we are going to do the most important thing first:

set up a brand new Shopify app using Ruby on Rails and get it running locally.

This article can serve as a reference if you just want to get your first app up and running and have a look around.

Introduction

For this guide, I am assuming a few things:

you already have Ruby on Rails installed
you already have Node.js installed
you already have Git installed
you are comfortable using your terminal
you have a Shopify Partner account and a development store

You do not need to be deeply experienced with Rails yet. It is enough if you roughly know what Rails is and how to run commands in a project.

If you do not have the Shopify side set up yet, you will need a Partner account and a development store before you can properly install and test your app.

For this guide, we are going to use Shopify’s maintained Ruby app template. This is currently one of the nicest ways to get started quickly, because it already includes a Rails backend, Shopify authentication, session storage, Admin API access, and webhook support. The template does also include a React frontend, but that is fine. We can mostly treat that as already wired up for us while we focus on the Rails side first.

Part 1: Installing Shopify CLI

Before we create the app, we need Shopify CLI.

Shopify CLI is the command line tool that helps create Shopify apps, manage app extensions, create tunnels for local development, and connect your local project to Shopify.

You can install it globally by running:

npm install -g @shopify/cli@latest

Once that is done, it is a good idea to check if it worked:

shopify version

If that gives you a version number, you are good to go.

Part 2: Creating the app

Now that we have Shopify CLI installed, we can use Shopify’s Ruby template to create our app.

Run:

shopify app init --template=https://github.com/Shopify/shopify-app-template-ruby

The template is specifically for building a Shopify app using Ruby on Rails and React.

The CLI will ask you a few questions while setting everything up. Just follow along and choose a name for your app.

Once it is done, navigate into the folder it created:

cd your-app-name

You now have a Shopify app on your machine.

Part 3: Starting the app locally

This is the nice part.

From the root of your new app, run:

shopify app dev

When you run this for the first time, Shopify CLI will guide you through connecting the project to an app and development store.

After a bit of setup, it will print a URL in the terminal.

Open that URL in your browser and install the app on your development store.

At that point, your app should be running.

That is already a big step. A lot of the mystery disappears once you have a real app running and can click around in it.

Part 4: What we just created

It helps to understand what this template already gave us.

Shopify’s Ruby template comes with these things out of the box:

OAuth for app installation and permissions
GraphQL Admin API access
REST Admin API access
webhooks
the shopify_app Rails engine
the shopify_api gem
session storage through Rails / ActiveRecord

That sounds like a lot, but really it just means a bunch of the annoying setup work has already been done for us.

This is exactly why I like starting from the template instead of wiring everything by hand in a first guide.

Part 5: Having a look around the project

Now that the app is running, let’s have a quick look at some of the files and folders you will actually care about in the beginning.

We are not going to discuss every file. That would be a bit much for now.

The `shopify.app.toml` file

This file is very important.

Shopify CLI uses it as part of the conventional app structure for Shopify apps. It holds app configuration that Shopify CLI uses when running and managing the app.

You do not need to fully understand it yet, but it is good to know that this file is one of the central pieces that connects your local app to Shopify CLI.

The `web` folder

This is where the actual web app lives.

In the Ruby template, Rails builds the backend, and the frontend lives inside this same project structure.

This means that when you want to look at the application code, this is where you will spend most of your time.

The `web/app/controllers` folder

This folder contains controllers.

If you are new to Rails, a controller is basically the part that receives a request and decides what should happen next.

In a Shopify app, this might mean:

returning data to the frontend
handling an action from the merchant
talking to Shopify through the API
calling a service object

You do not need to master controllers yet. Just know that they often act as the entry point for requests.

The `web/app/services` folder

This is often where you put code that does the actual work.

For example, instead of putting a lot of logic directly inside a controller, you might move that logic into a service object.

That can make the app easier to read, because the controller stays smaller and the heavier logic lives somewhere more focused.

So a simple way to think about it is:

controllers receive the request
services do the work

That is not a perfect description of every Rails app, but it is a very helpful starting point.

The `web/config` folder

This is where your routes and general configuration live.

The routes file is especially useful early on, because it helps you understand what URLs in your app go where.

If you are still new to Rails, routes.rb is a very nice file to open because it gives you a map of the app.

Part 6: Making your first small change

At this point, I like making one tiny change just to get comfortable.

You can, for example, open the project in your editor and start by looking at:

web/config/routes.rb
web/app/controllers
web/app/services

You do not need to fully understand the whole app yet.

Just get used to the fact that underneath the Shopify-specific tooling, there is still a Rails app in there.

That is one of the most helpful mindset shifts in the beginning.

A Shopify app is not some completely magical thing.

It is a web application with Shopify-specific authentication, API access, and extension points.

Part 7: Making your first Shopify API call

Once your app is running, the next fun step is making a Shopify API call.

The Ruby template points to built-in examples for this, including Admin GraphQL and Admin REST API requests.

The current basic shape of an Admin GraphQL client looks like this:

client = ShopifyAPI::Clients::Graphql::Admin.new(session: session)
response = client.query(query: query)

That is the core shape you will keep seeing when you make authenticated Admin API requests from Ruby.

You do not need to understand every part of this line right away.

For now, the main thing to notice is:

a client is created
that client uses the current Shopify session
a query is sent to Shopify
a response comes back

That is the basic loop.

For a first day, I would not try to build a giant feature yet.

I would simply:

get the app running
find one example API call
follow how the request flows through the Rails app
make one small change and see what happens

That is enough to start building intuition.

Conclusion

We now have a Shopify app running locally using Ruby on Rails.

That is already a really nice place to start.

We installed Shopify CLI, created a new app from Shopify’s Ruby template, ran it locally, installed it on a development store, and had a quick look at the parts of the project that matter most in the beginning.

At this point, the best thing you can do is just spend a bit of time clicking around, opening files, and getting comfortable with the shape of the app. Once you see that it is still just a Rails application with some Shopify-specific pieces around it, things start feeling much more approachable.

I write more about Ruby on Rails, Shopify, and building practical things for merchants on Instasupport, so if you want more guides like this, you can find them for free with no ads and no paywall here: Instasupport.io Guides.