DEV Community: coder om

🛍️ Building a Shopify Automation Script — Lessons & Setup Reference

coder om — Sat, 28 Feb 2026 04:47:31 +0000

What this doc is: A first-person reference log of everything I went through while building a Shopify product image optimization tool. The actual goal of the script doesn't matter — what matters is the journey to get the script talking to Shopify at all. These steps, challenges, and fixes will apply to almost any Shopify automation I build in the future.

🎯 What I Was Trying to Do

My client had a Shopify store with 250+ products. Many product images were over 1MB in size, which was tanking their site performance. The goal was simple: automatically compress all images over 200KB down to under 200KB and re-upload them to Shopify — no manual work, no mistakes, fully automated.

🗂️ The Stack I Chose

Runtime: Node.js (v20+)
Language: TypeScript (with ts-node for running directly)
Libraries: axios for HTTP, sharp for image compression
Shopify interface: Shopify Admin REST API

📋 Step-by-Step: What I Did, What Broke, and How I Fixed It

Step 1 — Writing the Script

I started with a TypeScript script that would:

Fetch all products via the Shopify API (with pagination for 250+ products)
Download each product image
Compress images over 200KB using sharp
Re-upload the compressed image back to Shopify, replacing the original

The script was fully typed with interfaces for all Shopify API shapes (ShopifyProduct, ShopifyImage, SummaryRow, etc.) and had a final before/after summary report.

✅ No issues here — the code was solid from the start.

Step 2 — First Run: `getaddrinfo ENOTFOUND https`

Error:

Fatal error: getaddrinfo ENOTFOUND https

What happened: I had set my SHOPIFY_STORE env var to https://coderom.myshopify.com — with the https:// prefix. But the script was already building the URL as https://${STORE}/..., which resulted in https://https://coderom.myshopify.com. DNS couldn't resolve https as a hostname.

Fix: Added a one-liner at the top of the config to strip any protocol prefix automatically:

const STORE = (process.env.SHOPIFY_STORE ?? "")
  .replace(/^https?:\/\//i, "")  // strips https:// or http://
  .replace(/\/$/, "");            // strips trailing slash

Lesson learned: Always sanitize env var inputs. Users (including myself) will paste full URLs. Strip the protocol defensively so the script never breaks regardless of how the var is set.

Step 3 — Second Run: `connect ETIMEDOUT`

Error:

Fatal error: connect ETIMEDOUT 218.248.112.60:443

What happened: The script connected to an IP but timed out. I ran a curl test to isolate whether this was a code issue or a network issue:

curl -v --connect-timeout 10 https://solar-for-nature.myshopify.com

Result: same timeout, same IP — 218.248.112.60.

Root cause: That IP is not a Shopify IP. Shopify runs on Fastly CDN (151.101.x.x, 23.227.x.x). My ISP (Indian ISP) was DNS hijacking the request — intercepting the DNS resolution and pointing the domain to a local IP instead of Shopify's actual servers.

Fix: Changed DNS resolver to Cloudflare (1.1.1.1) in system network settings, which bypassed the ISP's DNS hijacking. Could also be fixed by connecting to a VPN or using mobile hotspot.

Lesson learned: ETIMEDOUT doesn't always mean the store is down or the code is wrong. Always run a curl test to check the resolved IP. If it doesn't look like a CDN IP, the problem is DNS, not the script. This is especially common in India with ISPs like Jio, Airtel, and BSNL.

Step 4 — The Shopify App Setup Problem

Wrong Turn 1 — Creating a Public App first

My first attempt was creating an app through the Shopify Partners dashboard. I built it there, but then I noticed a Distribution field on the app's homepage inside the partner dashboard. I clicked it, which took me to the distribution section where Shopify presented two options:

Public distribution — Publish on the Shopify App Store (listed or unlisted). Reaches a global merchant audience with unlimited installs. Requires Shopify review.
Custom distribution — Generate custom install links for one store or one organization. Installs are limited to that store/org. No App Store review.

I selected Custom distribution since this was for one specific client store. Shopify showed a warning: "This can't be undone" — once you select custom distribution, you can't switch it back to public. I confirmed, and it then asked me for the store domain (e.g. shopone.myshopify.com). It generated a custom install link which I opened, and that installed the app on the store.

The problem: Even after going through all this — Partners dashboard → custom distribution → install link → app installed on store — the token situation was still unclear and this whole flow added unnecessary complexity for what should have been a simple script setup.

The lesson: The Shopify Partners dashboard is for building apps meant to be distributed to multiple stores — even if you pick custom distribution and limit it to one store, it's still the wrong tool for a private client script. It creates overhead (distribution settings, install links, partner account dependency) that you don't need.

For any client-specific automation script, always use a Custom App created directly inside the store's own admin, not through the Partners dashboard. It lives inside one store, is invisible to the App Store, and gives an instant access token with zero distribution complexity.

What I learned: There are two types of Shopify apps:

Type	Use case	Review needed?	Time to token
Public App	Listed on App Store, used by many stores	✅ Yes — Shopify reviews it	Days/weeks
Custom App	Built inside one specific store	❌ No review	Instant

For any client-specific automation script, always use a Custom App. It lives inside one store, is invisible to the App Store, and gives an instant access token.

How to create a Custom App (the right way):

Go to client's Shopify Admin → Settings → Apps
Click Develop apps → Allow custom app development (one-time)(if sees this)
Click Build apps in Dev Dashboard it will open dev dashboard
Click Create app → and you will see 2 ways to move forward:
- i) Start with Shopify CLI and ii) Start from Dev Dashboard
- I went with Start from Dev Dashboard
Name it (e.g. Image Optimizer)
In the version settings under the Access Scopes → select scopes:
- read_products — for reading/auditing
- write_products — for modifying/uploading
Click Release → So this is a 2nd release of the app which means with updates
Click Settings → Here you can get the Credentials i.e. Client ID and Secret and rest of the settings related to the app.

⚠️ Common gotcha: After this you might think you can now move forward to your app scripts because you are seeing here Credentials i.e. Client ID and Secret but no you need to get the the Access Token. I missed this at first and thought I can use the this secret and it will work but it didn’t actually.

Step 4b — The Access Token Wasn't There: OAuth Endpoint to the Rescue

After completing all the Custom App steps above, I ran into a problem: the "Access Token is not correct". The API credentials section showed a Client ID and Client Secret, but no access token.

I initially tried using the Client Secret directly as the API token — that didn't work and caused auth failures.

After going through Shopify's documentation, I found the actual solution: for this app setup, the access token isn't pre-generated in the UI — I had to request it programmatically by hitting Shopify's OAuth endpoint using the Client ID and Client Secret.

The request:

POST https://{shop}.myshopify.com/admin/oauth/access_token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id={your_client_id}
&client_secret={your_client_secret}

The response:

{
  "access_token": "shpat_xxxxx",
  "scope": "read_products,write_products",
  "expires_in": 86399
}

The access_token value (shpat_xxxxx) is what goes into SHOPIFY_TOKEN. This is the token used in the X-Shopify-Access-Token header for all API calls.

⚠️ Important: Tokens expire after 24 hours. This means for long-running automations or scheduled tasks, I need to re-request a new token before each run using this same OAuth call.

⚠️ Client Secret ≠ Access Token. This was my exact mistake — I copied the Client Secret from the app credentials page thinking that was the token. It's not. The Client Secret is only used to obtain an access token via the OAuth endpoint. The actual token you use in API calls is the access_token returned from that POST request.

Step 5 — Building a Debug Script Before Going to Prod

Before running the full optimizer (which modifies images), I built two safer scripts:

shopify-debug.ts — A pure connectivity tester that runs 5 progressive checks:

DNS resolution
TCP port 443 reachability
HTTPS handshake
API version detection (tries 2025-01 → 2024-10 → ... → 2024-01)
Reports exactly which version works and what error each one returns

This was invaluable — it told me immediately where in the chain things were breaking rather than just showing a generic fatal error.

shopify-image-audit.ts — A 100% read-only script that:

Fetches all products
Checks each image size (using HEAD requests first, falling back to full download)
Lists every image URL over 200KB with its size
Makes zero writes to the store

Why I built the audit script first: Running the optimizer directly on a production store is risky. The audit script let me verify that connectivity, auth, and pagination all worked correctly, and showed me exactly what would be changed — before any changes were made.

Lesson learned: For any Shopify automation, always build in this order:

Debug/connectivity script first
Read-only audit script second
Write/modify script last — only after both above confirm everything works

Step 6 — The Optimizer: How Image Compression Works

The core compression logic uses sharp and works in two stages:

Stage 1 — Quality reduction:
Start at quality 85 and step down by 5 until the image is under 200KB:

let quality = 85;
while (quality >= 20) {
  compressed = await sharp(buffer).jpeg({ quality, progressive: true }).toBuffer();
  if (compressed.length <= TARGET_SIZE_BYTES) return compressed;
  quality -= 5;
}

Stage 2 — Dimension resize (if Stage 1 isn't enough):
If even quality 20 doesn't get it under 200KB, proportionally scale down the image dimensions:

const scaleFactor = Math.sqrt(TARGET_SIZE_BYTES / compressed.length);
const newWidth = Math.max(Math.floor((metadata.width ?? 1200) * scaleFactor), 400);
compressed = await sharp(buffer)
  .resize({ width: newWidth, withoutEnlargement: true })
  .jpeg({ quality: 75, progressive: true })
  .toBuffer();

Why this order? Quality reduction is invisible to most viewers. Resizing dimensions is noticeable. So quality is always tried first, and dimension reduction is only the last resort.

Shopify rate limiting: The Shopify API allows ~2 requests/second. The script adds a 600ms delay between image uploads to stay within this limit and avoid 429 Too Many Requests errors.

🧱 Final Project Structure

image-optimizer/
├── src/
│   ├── shopify-debug.ts          # Step 1: Run this first — tests connectivity
│   ├── shopify-image-audit.ts    # Step 2: Read-only image size report
│   └── shopify-image-optimizer.ts # Step 3: Compresses & re-uploads images
├── package.json
└── tsconfig.json

Always run in order: debug → audit → optimizer.

⚡ Quick Reference: Run Commands

# Install dependencies (one time)
npm install

# 1. Test connectivity and API access
SHOPIFY_STORE=store.myshopify.com SHOPIFY_TOKEN=shpat_xxx npx ts-node src/shopify-debug.ts

# 2. Audit images (read-only, safe on prod)
SHOPIFY_STORE=store.myshopify.com SHOPIFY_TOKEN=shpat_xxx npx ts-node src/shopify-image-audit.ts

# 3. Run optimizer (modifies images — run after audit confirms everything)
SHOPIFY_STORE=store.myshopify.com SHOPIFY_TOKEN=shpat_xxx npx ts-node src/shopify-image-optimizer.ts

📌 Master Checklist for Any Future Shopify Automation

[ ] Use a Custom App, not a Public App — avoids review, instant token
[ ] Enable correct API scopes (at minimum: read_products; add write_products if modifying)
[ ] Hit the OAuth endpoint programmatically with Client ID + Secret to get the access_token
[ ] Never use Client Secret directly as the API token — it's only used to request the real token
[ ] Tokens obtained via OAuth expire after 24 hours — re-request before each run
[ ] Set SHOPIFY_STORE without https:// — or strip it in code
[ ] If ETIMEDOUT, run curl and check the resolved IP — may be DNS hijacking
[ ] Switch to 1.1.1.1 DNS or use a VPN if ISP is hijacking DNS
[ ] Always run the debug script before the real script
[ ] Always build a read-only audit script before a write script
[ ] Respect the ~2 req/s rate limit — add 500–600ms delays between writes
[ ] Back up prod data before any destructive operation

💡 Key Lessons (TL;DR)

ETIMEDOUT ≠ code bug. Check the IP with curl -v. ISPs in India (and elsewhere) hijack DNS.
Never use a Public App for client scripts. Custom App is always the right choice — instant, no review, scoped to one store.
Access Token never appears in the UI, don't use the Client Secret directly — hit the OAuth endpoint (POST /admin/oauth/access_token) with the Client ID and Secret to programmatically get the real access_token.
Client Secret ≠ Access Token. The secret is a credential used to request a token. The token is what you actually use in API calls. Confusing these two wastes a lot of time.
Build read-only first. Debug → Audit → Optimizer. Never jump straight to writes on prod.
Auto-detect API version. Hardcoding it is fragile. Try newest-first.
Quality before resize. When compressing images, always try quality reduction before touching dimensions.

Building a Reversible Bundle Transformation Engine in Shopify

coder om — Thu, 26 Feb 2026 09:45:12 +0000

How I solved the three-way conflict between merchandising UX, operations accuracy, and checkout correctness — without a backend service or third-party app.

The Problem No One Tells You About Bundles

When you first hear the requirement — "we want to sell bundles" — it sounds straightforward. Put a few products together, wrap them in a bow, charge a price. Done.

It isn't.

The moment you go deeper, you hit a wall that every Shopify developer eventually collides with: Shopify's inventory model is variant-centric, but bundle UX is representation-centric. Those two things want fundamentally different things from your cart.

This is the story of how I designed and built a solution that satisfies both — a reversible transformation engine that keeps the customer-facing cart clean and bundled, while sending real, fulfillable component SKUs through to checkout and inventory.

This article is written for Shopify developers. It assumes familiarity with Liquid, the Ajax Cart API, and basic theme architecture. I'll cover the full design rationale, the data contract, the implementation step by step, the tradeoffs I made, and the hardening I'd apply before going to production.

The Business Requirement (And Its Hidden Complexity)

The stated requirement had four parts:

Show a bundle as a single product on the PDP with a clean add-to-cart experience.
Keep the cart showing one tidy bundle line — not three or four component lines confusing the customer.
At checkout, pass real component variant IDs so Shopify decrements inventory correctly.
Avoid maintaining a separate inventory model for an abstract "bundle SKU" that doesn't physically exist.

On paper, four clean bullets. In practice, each one creates a constraint that fights the others.

The deeper complexity becomes clear when you think about the full lifecycle of a cart item, not just the PDP moment:

PDP: Customer selects bundle, adds to cart.
Cart: Customer sees one clean line item.
Checkout: Backend needs real purchasable variant IDs — not a synthetic bundle ID.
Post-checkout return: If the customer comes back to the storefront (abandoned checkout, payment failure, etc.), the cart should look bundled again, not like a disassembled pile of components.

Most implementations I've seen solve one or two of these well and quietly break the others. The checkout split is easy. The reconstruction on return is almost always missing.

Why This Is Technically Hard in Shopify

Shopify's checkout and inventory pipeline is built around variants. When checkout fires, Shopify's backend processes line items, decrements inventory, and generates order line items — all at the variant level. There is no native concept of a "bundle variant" that internally maps to multiple inventory units.

That means any bundle abstraction you build in the storefront has to be transparent to Shopify's checkout. The checkout cart must contain real component variant IDs, in real quantities, with real inventory backing.

But your customer doesn't care about any of that. They bought "The Starter Kit." They don't want to see four separate line items in their cart and wonder if they accidentally added duplicates.

So the cart state your customer sees and the cart state Shopify's checkout needs are structurally different. You need a transformation layer that lives between them — one that:

Keeps the customer-facing representation intact while the customer is browsing and adding items.
Explodes the bundle into components exactly at the moment the customer initiates checkout.
Optionally reconstructs the bundle representation when the customer returns to the storefront.

This transformation must be safe (can't lose cart items on failure), reversible (can reconstruct the original representation), and invisible to the customer (all of this happens before the page redirects to checkout).

Important Distinction: Pack UI vs Bundle Engine

Before going further, it's worth clarifying a naming collision that existed in this codebase.

Pack UI refers to the PDP display and variant selection experience — the card-style quantity selectors (buy 1 / buy 2 / buy 3) that live in snippets/product-details.liquid and are powered by assets/pdp-custom.js. This is a presentational layer.

Bundle transformation refers to the cart and checkout pipeline — the logic that reads cart state, splits bundle lines into component lines, and rebuilds them on return. This lives entirely in assets/bundleCartBreaking.js.

These two systems share a product but operate independently. This article covers only the bundle transformation engine. The Pack UI is a separate concern.

The Architecture: A Three-Layer System

The solution I designed has three distinct layers.

Layer 1: Data Contract

Every bundle line item in the cart carries a set of private metadata properties. These are Shopify line item properties — a native feature of the Ajax Cart API — with keys prefixed by _ to mark them as internal and hide them from the customer-facing cart UI.

The contract is:

Property Key	Purpose	Example Value
`_Individual Product Variant IDs`	Comma-separated component variant IDs for checkout split	`"44112233,44112244,44112255"`
`_Bundle Id`	The bundle's own variant ID, used as grouping key on reconstruction	`"43998877"`
`Bundle Name`	Human-readable label for the bundle, used on reconstruction	`"The Starter Kit"`

These three properties are set at add-to-cart time and travel with the line item throughout the cart lifecycle. They are the single source of truth for every transformation the engine performs.

Layer 2: Transformation Pipeline

The engine has two directions:

Forward (cart → checkout): On checkout click, read the cart, detect bundle lines by the presence of _Individual Product Variant IDs, expand each bundle line into its component variant rows, preserve the _Bundle Id and Bundle Name on each component row (for later reconstruction), clear the cart, re-add all items (expanded components plus untouched non-bundle items), and redirect to /checkout.

Reverse (checkout return → cart): On storefront load, check for a session flag (userWentToCheckout) indicating the user came back from a checkout session. If the flag is present, read the cart (now containing component rows), group component rows by _Bundle Id, reconstruct bundle line items with the full _Individual Product Variant IDs value, clear the cart, and re-add the reconstructed bundle lines.

Layer 3: Presentation Filtering

The _-prefixed properties are hidden from the customer's cart UI via a filter in snippets/line-item.liquid. The line item template loops over properties and skips any key beginning with _. The customer only ever sees Bundle Name — the friendly label — not the internal IDs.

The Sequence, End to End

Here is the complete lifecycle of a bundle from add-to-cart to checkout to return, visualized as a sequence:

┌─────────────────────────────────────────────────────────────┐
│  CUSTOMER                                                   │
│                                                             │
│  1. Opens PDP for "The Starter Kit"                         │
│  2. Clicks "Add to Cart"                                    │
│     └─ Product form submits with hidden properties:         │
│        · _Individual Product Variant IDs: "111,222,333"     │
│        · _Bundle Id: "99887"                                │
│        · Bundle Name: "The Starter Kit"                     │
└─────────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────────┐
│  CART (Customer View)                                       │
│                                                             │
│  · "The Starter Kit" × 1           £49.00                   │
│    (internal properties hidden)                             │
│                                                             │
│  [Checkout]                                                 │
└─────────────────────────────────────────────────────────────┘
                          │
             Customer clicks [Checkout]
                          │
                          ▼
┌─────────────────────────────────────────────────────────────┐
│  BUNDLE TRANSFORMATION ENGINE (Invisible to Customer)       │
│                                                             │
│  1. Fetch GET /cart.js                                      │
│  2. Detect bundle lines via _Individual Product Variant IDs │
│  3. Expand to component rows:                               │
│     · Variant 111 × 1, _Bundle Id: "99887"                  │
│     · Variant 222 × 1, _Bundle Id: "99887"                  │
│     · Variant 333 × 1, _Bundle Id: "99887"                  │
│  4. POST /cart/clear.js                                     │
│  5. POST /cart/add.js (component rows)                      │
│  6. Set sessionStorage: userWentToCheckout = true           │
│  7. Redirect → /checkout                                    │
└─────────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────────┐
│  SHOPIFY CHECKOUT                                           │
│                                                             │
│  · Product A (Variant 111) × 1                              │
│  · Product B (Variant 222) × 1                              │
│  · Product C (Variant 333) × 1                              │
│                                                             │
│  Inventory decremented at component level ✓                 │
│  Fulfillment sees real SKUs ✓                               │
└─────────────────────────────────────────────────────────────┘
                          │
         Customer abandons or returns to storefront
                          │
                          ▼
┌─────────────────────────────────────────────────────────────┐
│  BUNDLE RECONSTRUCTION ENGINE (Invisible to Customer)       │
│                                                             │
│  1. Detect sessionStorage flag: userWentToCheckout          │
│  2. Fetch GET /cart.js (component rows visible)             │
│  3. Group rows by _Bundle Id                                │
│  4. Reconstruct: "The Starter Kit" with IDs "111,222,333"   │
│  5. POST /cart/clear.js                                     │
│  6. POST /cart/add.js (bundle row)                          │
└─────────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────────┐
│  CART (Customer View — Back to Bundle Representation)       │
│                                                             │
│  · "The Starter Kit" × 1           £49.00                   │
└─────────────────────────────────────────────────────────────┘

Implementation: Step by Step

Step 0: Define the Bundle Metafield

Before any code, set up the data model that connects a bundle product to its component products in Shopify Admin.

Create a product metafield:

Owner type: Product
Namespace: custom
Key: bundle_components
Type: list.product_reference

The list.product_reference type is a native Shopify metafield type that stores references to other product objects. Its .value in Liquid returns an iterable of product objects, which means you can loop over component products and resolve their current default variants without any Ajax calls.

Only apply this metafield to products that are bundles. Non-bundle products leave it empty and the engine ignores them entirely.

Step 1: Populate Metafield in Admin

For each bundle product:

Open the product in Admin.
Scroll to the metafields section.
Fill custom.bundle_components with the component products.
Save.

This is the merchant-facing configuration interface. No code is needed here. The metafield UI handles the product picker.

Step 2: Include the Bundle Script Globally

In layout/theme.liquid, include the bundle engine near your other global JavaScript:

<script src="{{ 'bundleCartBreaking.js' | asset_url }}" defer></script>

The defer attribute ensures the DOM is available before the script initializes event listeners. This must be a global include — not scoped to the product template — because checkout button listeners need to be present on the cart drawer and cart page as well.

Step 3: Wire Checkout Button Hooks

The bundle engine needs to intercept checkout before the page redirects. It does this by listening to clicks on checkout buttons.

The existing script uses these selectors:

#ddCheckoutButton          // Cart drawer checkout
.ddCartPageCheckoutBtn     // Cart page checkout
.ddBuyNowButton            // Buy now

These need to match your actual checkout buttons. If your theme uses different selectors (for example, a GoKwik checkout button), you have two options:

Option A: Add the expected IDs or classes to your existing buttons.

Option B: Update the selectors in bundleCartBreaking.js to match your actual buttons.

The more robust approach for any theme is to use stable data-* attributes instead of class names or IDs, which are more likely to change across theme updates:

<button data-role="bundle-checkout">Checkout</button>

document.querySelectorAll('[data-role="bundle-checkout"]')

This decouples the bundle engine from the visual/styling layer of your buttons.

Step 4: Inject Bundle Properties into the Product Form

In snippets/buy-buttons.liquid, inside the {% form 'product' %} block, add hidden inputs for the three bundle properties:

{% if product.metafields.custom.bundle_components != blank %}
  <input
    type="hidden"
    name="properties[_Bundle Id]"
    value="{{ product.selected_or_first_available_variant.id }}"
  >
  <input
    type="hidden"
    name="properties[Bundle Name]"
    value="{{ product.title | escape }}"
  >
  <input
    type="hidden"
    name="properties[_Individual Product Variant IDs]"
    id="bundle-component-ids"
    value=""
  >
{% endif %}

The conditional {% if product.metafields.custom.bundle_components != blank %} ensures these properties are only added for bundle products. Non-bundle products go through the normal add-to-cart flow untouched.

The _Individual Product Variant IDs input starts empty. It will be populated by the next step.

Step 5: Resolve Component Variant IDs at Page Load

The hidden input for component variant IDs needs to be populated with the actual variant IDs of the bundle's component products. You resolve these from the metafield.

Add this Liquid and JavaScript to the product template or buy-buttons snippet:

{% if product.metafields.custom.bundle_components != blank %}
  {% assign component_ids = '' %}
  {% for component_product in product.metafields.custom.bundle_components.value %}
    {% assign variant_id = component_product.selected_or_first_available_variant.id %}
    {% assign component_ids = component_ids | append: variant_id %}
    {% unless forloop.last %}
      {% assign component_ids = component_ids | append: ',' %}
    {% endunless %}
  {% endfor %}

  <script>
    document.addEventListener('DOMContentLoaded', function () {
      var el = document.getElementById('bundle-component-ids');
      if (el && !el.value) {
        el.value = "{{ component_ids }}";
      }
    });
  </script>
{% endif %}

This resolves the default/first-available variant for each component product at page load. The resulting comma-separated string — for example "44112233,44112244,44112255" — gets written into the hidden input before the customer clicks "Add to Cart."

Important edge case: If your bundle variant options determine which component variant gets added (for example, a bundle size "M/L" maps to the Medium variant of Product A and the Large variant of Product B), this static Liquid resolution won't be sufficient. You'll need a JavaScript mapping table that listens to variant change events and updates the component IDs dynamically:

// Example mapping: bundle variant ID → component variant IDs
var bundleVariantMap = {
  "43001122": "44112233,44112244",   // Bundle size S/M
  "43001133": "44112255,44112266",   // Bundle size L/XL
};

document.addEventListener('variantChanged', function (e) {
  var ids = bundleVariantMap[e.detail.variantId] || '';
  document.getElementById('bundle-component-ids').value = ids;
});

For fixed-composition bundles with no variant options, the Liquid-only approach works cleanly.

Step 6: Cart UI Hides Internal Properties

This step is already implemented via snippets/line-item.liquid. The template loops over line item properties and skips any key beginning with _:

{% for property in item.properties %}
  {% unless property.first == blank or property.first contains '_' %}
    <div class="cart-item__property">
      <span>{{ property.first }}:</span>
      <span>{{ property.last }}</span>
    </div>
  {% endunless %}
{% endfor %}

The customer only sees Bundle Name in the cart. The _Bundle Id and _Individual Product Variant IDs values are invisible.

Step 7: The Checkout Split Pipeline

This is the core of the engine. When the customer clicks checkout, bundleCartBreaking.js intercepts the click and runs the transformation:

async function breakBundlesForCheckout() {
  // 1. Fetch current cart
  const cartResponse = await fetch('/cart.js');
  const cart = await cartResponse.json();

  // 2. Determine if any bundles exist
  const hasBundles = cart.items.some(item =>
    item.properties && item.properties['_Individual Product Variant IDs']
  );

  if (!hasBundles) {
    // No bundles — proceed to checkout normally
    window.location.href = '/checkout';
    return;
  }

  // 3. Build expanded item list
  const expandedItems = [];

  cart.items.forEach(item => {
    const componentIds = item.properties['_Individual Product Variant IDs'];

    if (componentIds) {
      // Bundle item — split into components
      const ids = componentIds.split(',').map(id => id.trim());
      ids.forEach(variantId => {
        expandedItems.push({
          id: parseInt(variantId),
          quantity: item.quantity,  // Multiply component qty by bundle qty
          properties: {
            '_Bundle Id': item.properties['_Bundle Id'],
            'Bundle Name': item.properties['Bundle Name']
            // Note: _Individual Product Variant IDs intentionally excluded
          }
        });
      });
    } else {
      // Non-bundle item — pass through unchanged
      expandedItems.push({
        id: item.variant_id,
        quantity: item.quantity,
        properties: item.properties
      });
    }
  });

  // 4. Clear cart
  await fetch('/cart/clear.js', { method: 'POST' });

  // 5. Re-add expanded items
  await fetch('/cart/add.js', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ items: expandedItems })
  });

  // 6. Set session flag for return reconstruction
  sessionStorage.setItem('userWentToCheckout', 'true');

  // 7. Redirect to checkout
  window.location.href = '/checkout';
}

The critical detail in step 3 is that _Individual Product Variant IDs is not included on the component rows. Each component row only carries _Bundle Id and Bundle Name. This is what allows the reconstruction to work on return — the absence of _Individual Product Variant IDs on a row signals "this is a component, not a bundle."

Step 8: Reconstruct Bundles on Return

On every storefront page load, the engine checks for the userWentToCheckout session flag:

document.addEventListener('DOMContentLoaded', async function () {
  const wentToCheckout = sessionStorage.getItem('userWentToCheckout');
  if (!wentToCheckout) return;

  // Clear the flag immediately to prevent re-running on next page load
  sessionStorage.removeItem('userWentToCheckout');

  await undoCartBreaking();
});

async function undoCartBreaking() {
  const cartResponse = await fetch('/cart.js');
  const cart = await cartResponse.json();

  // Group component items by _Bundle Id
  const bundleGroups = {};
  const nonBundleItems = [];

  cart.items.forEach(item => {
    const bundleId = item.properties && item.properties['_Bundle Id'];
    const hasComponentIds = item.properties && item.properties['_Individual Product Variant IDs'];

    if (bundleId && !hasComponentIds) {
      // This is a component row (has bundle ID but no component IDs list)
      if (!bundleGroups[bundleId]) {
        bundleGroups[bundleId] = {
          bundleId: bundleId,
          bundleName: item.properties['Bundle Name'],
          variantIds: [],
          quantity: item.quantity
        };
      }
      bundleGroups[bundleId].variantIds.push(item.variant_id);
    } else {
      nonBundleItems.push({
        id: item.variant_id,
        quantity: item.quantity,
        properties: item.properties
      });
    }
  });

  // If no bundle groups found, nothing to reconstruct
  if (Object.keys(bundleGroups).length === 0) return;

  // Build reconstructed bundle items
  const reconstructedItems = [...nonBundleItems];

  Object.values(bundleGroups).forEach(group => {
    reconstructedItems.push({
      id: parseInt(group.bundleId),
      quantity: group.quantity,
      properties: {
        '_Bundle Id': group.bundleId,
        'Bundle Name': group.bundleName,
        '_Individual Product Variant IDs': group.variantIds.join(',')
      }
    });
  });

  // Clear and rebuild
  await fetch('/cart/clear.js', { method: 'POST' });
  await fetch('/cart/add.js', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ items: reconstructedItems })
  });

  // Trigger cart refresh event so drawer/page updates
  document.dispatchEvent(new CustomEvent('cart:refresh'));
}

Why This Avoids Separate Bundle Inventory

The key insight in this architecture is that the bundle product never enters the checkout cart. The bundle variant is used as a cart representation vehicle and a grouping key — nothing more. Shopify's checkout always receives real component variant IDs.

This means:

Shopify decrements inventory against component variants, not a synthetic bundle SKU.
Fulfillment receives real, physically pickable SKUs.
You never have to maintain a shadow inventory model for bundles.
The bundle product can have "Continue selling when out of stock" enabled without consequence — stock is enforced at the component level.

This is the primary operational win. Merchandising gets their clean single-SKU bundle product on the storefront. Operations gets clean per-SKU inventory movement. Neither team has to compromise.

Tradeoffs and Why This Pattern Was Worth It

No architecture is without tradeoffs. I want to be transparent about where the risks are.

The risk in clear + add: The transformation involves clearing the entire cart before re-adding. If the POST /cart/add.js call fails after the clear, the customer's cart is empty. This is the single most dangerous moment in the pipeline. It requires a robust failure rollback strategy (covered in the hardening section below).

Checkout button coverage must be exhaustive: If there is a checkout path you haven't wired the bundle engine to — a secondary checkout button, a third-party checkout widget — bundles will slip through un-split. This requires deliberate QA across all cart entry points.

More complex QA surface: Compared to a simple product, a bundle with this transformation engine has significantly more states to test. The test matrix is real work.

But the alternative is worse: The common alternative — maintaining a separate bundle SKU with its own inventory that you then sync to component products — creates a permanent operational burden. Someone has to keep bundle inventory in sync with component inventory at all times. Overselling becomes a real risk. Fulfillment teams deal with phantom SKUs. This architecture front-loads engineering complexity in exchange for operational simplicity at scale. For stores running bundles as a significant revenue line, that's the right trade.

Production Hardening Checklist

The core engine works. Before taking it to production, here is what I would implement:

1. Preserve cart note and attributes across transformation

During clear + add, Shopify loses cart.note and cart.attributes. Read them before clearing and restore them via /cart/update.js after the re-add:

const cart = await fetch('/cart.js').then(r => r.json());
const cartNote = cart.note;
const cartAttributes = cart.attributes;

// ... clear and re-add ...

await fetch('/cart/update.js', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ note: cartNote, attributes: cartAttributes })
});

2. Failure rollback

Snapshot the cart before transformation. If the add fails after clear, restore from snapshot:

const snapshot = JSON.parse(JSON.stringify(cart.items)); // Deep copy before clear

try {
  await fetch('/cart/clear.js', { method: 'POST' });
  await fetch('/cart/add.js', { ... });
} catch (err) {
  // Restore snapshot
  await fetch('/cart/add.js', {
    method: 'POST',
    body: JSON.stringify({ items: snapshot.map(/* map to add format */) })
  });
  console.error('Bundle split failed, cart restored:', err);
  return; // Do not redirect to checkout
}

3. Button idempotency

Disable checkout buttons during transformation to prevent double-clicks triggering duplicate pipeline runs:

button.disabled = true;
button.textContent = 'Processing...';
// Re-enable only on failure

4. Skip non-bundle carts gracefully

Check for bundles before running any transformation. If no bundle lines are present, skip the entire pipeline and redirect directly:

if (!hasBundles) {
  window.location.href = '/checkout';
  return;
}

5. Quantity multiplication

When a customer adds a bundle with quantity 2, each component should also be added with quantity 2. Make sure the expansion step uses item.quantity for component quantities.

6. Feature flag for gradual rollout

Gate the entire engine behind a theme setting to enable safe rollout:

In config/settings_schema.json:

{
  "type": "checkbox",
  "id": "enable_bundle_split_checkout",
  "label": "Enable bundle split at checkout",
  "default": false
}

In layout/theme.liquid:

{% if settings.enable_bundle_split_checkout %}
  <script src="{{ 'bundleCartBreaking.js' | asset_url }}" defer></script>
{% endif %}

Enable on staging first, validate against the full test matrix, then enable on production.

7. Use stable data-* hooks

Replace class-based or ID-based checkout button selectors with data-role attributes. CSS classes change with theme updates. data-* attributes are yours to control.

QA Test Matrix

Run every case in this matrix before launch.

Functional Tests

Test Case	Expected Outcome
Add bundle to cart	One cart line with all three private properties set
View cart	`_`-prefixed properties hidden, `Bundle Name` visible
Checkout from cart drawer	Cart splits, checkout receives component variants
Checkout from cart page	Same as above
Buy now flow	Same as above, single item path
Return after checkout	Cart reconstructs bundle representation
Non-bundle product in cart	Passes through checkout transformation untouched

Quantity Tests

Test Case	Expected Outcome
Bundle qty = 1	Each component qty = 1
Bundle qty = 2	Each component qty = 2
Bundle qty = 1 + normal product qty = 2	Bundle splits correctly, normal product unchanged
Update bundle qty in cart before checkout	Correct qty passed to split

Error / Edge Cases

Test Case	Expected Outcome
`/cart/clear.js` fails	Cart unchanged, user shown error, not redirected
`/cart/add.js` fails after clear	Snapshot restored, user shown error
`_Individual Product Variant IDs` is empty	Skip split, proceed to checkout normally
Component variant out of stock	Handle gracefully, surface error before checkout

Regression Tests

Test Case	Expected Outcome
GoKwik / third-party checkout button still works	Bundle split fires before redirect
Cart drawer refresh event fires after reconstruction	Drawer reflects updated cart without page reload
Cart note preserved through transformation	Note intact after checkout and return

What I Would Do Differently If Rebuilding Today

This architecture is sound, but with the benefit of hindsight there are several things I'd approach differently.

Consolidate split and reconstruct into a single module. The current implementation has the two directions of transformation somewhat spread across the file. I'd build a single BundleCartEngine module with clearly named methods: splitForCheckout() and reconstructFromReturn(). This makes the code dramatically easier to reason about and test in isolation.

Add structured telemetry. Every transformation step should emit an event — split initiated, split complete, split failed, reconstruction initiated, reconstruction complete. This data is invaluable when debugging production issues. Even a simple console.group / console.groupEnd structured log with timestamps helps enormously.

Use deterministic transaction IDs. When the split fires, generate a UUID and attach it to all the component rows as a property. This gives you a way to trace a specific checkout event end-to-end if something goes wrong.

Introduce a proper state machine. The current implementation has implicit states (cart is bundle-native, cart is component-native, transformation in progress). Making these explicit with an enum and enforced transitions removes entire categories of race condition bugs.

Stronger button hook contracts. Using data-role="bundle-checkout" as a convention across all checkout-adjacent buttons, documented in a theme README, means future developers can add new checkout entry points without breaking the bundle engine.

What This Implementation Demonstrates

I've found this project comes up frequently in technical conversations, and the reason is that it touches almost every layer of the Shopify theme stack simultaneously.

It required:

Understanding how Shopify's Ajax Cart API and line item properties work at a protocol level.
Building a two-directional transformation pipeline that can safely mutate and restore cart state.
Designing a data contract (the three-property bundle metadata schema) that is deterministic and survives round-trips through Shopify's cart storage.
Working with Shopify's metafield data model to create a merchant-facing configuration interface.
Navigating the gap between what Shopify's storefront presents and what Shopify's checkout requires.

If I had to describe it in one sentence: I built a reversible bundle transformation engine where the cart stays bundle-native for UX, checkout stays SKU-native for inventory truth, and merchant configuration stays metafield-native for scalability — all within Shopify's native primitives, with no backend service required.

References

I Built a Tool That Turns GitHub Milestones Into Shareable Video Clips

coder om — Fri, 06 Feb 2026 10:09:15 +0000

Why I built Milestone Clip, how it works, and who it’s for

I kept hitting milestones on GitHub—100 stars on a repo, 500 followers, 1k forks—and wanted to share them in a way that actually looked good. Screenshots felt flat. Making a proper video meant opening an editor, picking fonts, syncing numbers, and exporting. Most “milestone” tools were either generic templates, locked behind heavy subscriptions, or required more time than I had.

So I built Milestone Clip: paste a repo or username, pick a milestone and a style, and get an MP4 you can post anywhere—usually in under a minute. No design skills, no watermark. This is the story behind it and how you can use it.

The problem: celebrating GitHub wins shouldn’t be a side project

GitHub milestones are worth celebrating. Stars, forks, and followers are signals that your work is being seen and used. But turning those numbers into something you’d actually want to post is awkward:

Screenshots are quick but look unfinished.
Generic “achievement” generators often feel templated and samey.
Real video editors give control but cost time (and sometimes money).
SaaS “social video” tools are often built for marketing teams, not developers, and pricing can be steep for occasional use.

I wanted something in the middle: one input, one style choice, one download. No account required to try it, no big learning curve, and output that looks intentional enough for X, LinkedIn, or Reels.

What Milestone Clip does

Milestone Clip is a web app that turns GitHub milestones into short, ready-to-post video clips.

You provide:

A GitHub repository (e.g. owner/repo) or a GitHub username
The milestone type: repo stars, repo forks, user followers, or total stars across a user’s repos
A visual style (minimal, cinematic, feed-style, etc.) and aspect ratio (9:16 for Reels/Shorts, 1:1 for feed, 16:9 for YouTube or slides)

You get:

An MP4 you can download and post immediately—no watermark on the free tier
Light and dark themes so the clip can match your brand or platform
Multiple styles—from simple “float” layouts to more visual options (e.g. spotlight, constellation, mosaic)—so it doesn’t all look the same

The flow is deliberately short: enter repo or username → choose milestone and style → generate → download. No install, no code.

Who it’s for

Open-source maintainers — Celebrate stars or forks when you hit 100, 1k, 10k, or any number you care about.
Developers — Share follower growth or total stars across your profile when you hit a personal milestone.
Communities and teams — Create a quick clip when a shared project hits a milestone and post it on social or in Slack/Discord.
Anyone — Who’s proud of their GitHub numbers and wants a simple, professional way to show them off without opening a video editor.

How I think about the product

A few principles that shaped the product:

Speed over flexibility — Optimized for “I have a number, I want a clip” in under a minute, not for full creative control.
Developer-first — Repo URLs and usernames are the main input; no “campaign” or “brand kit” setup required.
Free to try — One free video per day with core styles and standard quality so you can see the output before committing.
No watermark on free tier — The free clip is usable as-is; premium adds more styles, higher resolution (including 4K), and more generations.

The 10,000-stars open-source promise

One more thing that matters to me: if the Milestone Clip repo reaches 10,000 GitHub stars, the full app will be open-sourced—frontend, backend, video compositions, billing, and deployment. No “community edition” with features removed. The goal is to grow it with the community and then give the codebase back. So if you find it useful, starring the repo doesn’t just signal interest; it’s the mechanism for eventually opening the whole project.

Try it

You can use Milestone Clip at milestoneclip.com. No install, no code—just a repo or username and a few clicks.

Watch Full Preview at - https://youtu.be/hFbIECIOYTc

If you’re a maintainer, creator, or community lead and you’ve ever skipped sharing a milestone because making a video felt like too much work, I built this for you. I’d love to hear how you’d use it or what you’d want next—other platforms, more milestone types, or different styles. You can reach me on X @1omsharma or through the app.

Thanks for reading — and here’s to the next milestone.

Why Tech Careers Feel So Emotionally Heavy Now

coder om — Wed, 28 Jan 2026 04:02:48 +0000

I’ve been thinking about this a lot lately.

Not about salaries.
Not about tools.
Not about AI replacing jobs.

But about something quieter.

Why does a tech career feel so emotionally heavy now?

Even when you’re doing “okay”.
Even when nothing is technically wrong.

It didn’t used to feel this way

Earlier, tech felt stressful, yes.
But it didn’t feel heavy.

There was pressure to learn.
Pressure to perform.
Pressure to grow.

But there was also time.

Time to be average.
Time to be slow.
Time to make mistakes.

Now it feels like the weight has increased.

Not on our skills.
But on our minds.

Everything is faster, all the time

Learning cycles are shorter.
Tools change faster.
Expectations reset quicker.

You don’t just feel behind.

You feel constantly behind.

Even when you’re learning daily,
there’s a sense that you’re late to something.

Late to AI.
Late to the right stack.
Late to the right opportunity.

That constant catching-up mode is exhausting.

The market uncertainty sits in your head

Earlier, if one job didn’t work,
another probably would.

Now the question is always there:

What if this doesn’t work out?
What if I chose the wrong thing?
What if the market doesn’t recover?

You don’t think about it consciously all the time.

But it sits quietly in the background.
Like low-level anxiety running all day.

AI added pressure, not clarity

AI was supposed to make things easier.

In some ways, it did.

But mentally, it added a new layer:

Should I use this?
Am I using it enough?
Will this replace me?
Do I need to pivot again?

Instead of reducing stress,
it often increases decision fatigue.

Not because AI is bad.

But because uncertainty multiplied.

Comparison is now unavoidable

Earlier, comparison was limited.

College friends.
Office teammates.
Maybe LinkedIn.

Now it’s global.

You compare with people from different countries,
different backgrounds,
different timelines.

Someone is always younger.
Someone is always faster.
Someone is always ahead.

So even normal progress feels insufficient.

You’re moving, but it doesn’t feel like enough.

Identity and career got too close

This is where it becomes emotionally heavy.

Tech stopped being just a job.

It became identity.
Status.
Self-worth.

So when the career feels unstable,
your sense of self feels unstable too.

You’re not just worried about work.

You’re worried about who you are becoming.

Or worse,
who you might fail to become.

There is no clear “done” anymore

Earlier, there were milestones.

Get the job.
Get promoted.
Become senior.

Now the finish line keeps moving.

Even after reaching something,
it doesn’t feel like arrival.

It feels temporary.

Like you need to keep proving yourself again and again.

That constant proving is emotionally draining.

Why this matters

This emotional weight doesn’t show up on resumes.

But it shows up as:

Feeling tired all the time.
Losing joy in learning.
Second-guessing yourself constantly.
Feeling guilty for resting.

And people think this is normal.

They think they are weak.

They are not.

They are responding to a system that became faster, louder, and more uncertain.

Final honest thought

Tech careers feel emotionally heavy now
because they ask too much from our minds,
not just our skills.

The pressure is not only to be good.

It’s to be relevant.
Fast.
Adaptable.
Always learning.
Always visible.

Feeling this weight doesn’t mean you are failing.

It means you are paying attention.

And the first step to surviving this industry
is admitting that the pressure is real —
even if nobody talks about it openly.

The Hardest Part About Learning to Code in 2026 Is Not Learning Code

coder om — Mon, 26 Jan 2026 03:33:59 +0000

I want to say something that sounds strange, but feels very true to me.

The hardest part about learning to code in 2026 is not learning code.

It’s everything around it.

What people think learning code is

Most people still think learning code means:

Open laptop
Watch tutorials
Practice problems
Build projects
Get job

That was maybe true some years ago.

Now it feels very different.

The real problem is not syntax

Today you can learn syntax in weeks.

JavaScript, Python, React, whatever.
AI can explain it.
YouTube can explain it.
Docs can explain it.

Syntax is not the hard part anymore.

The hard part is:

What should I learn
In what order
For which role
With which tools
For which market

This mental confusion is exhausting.

Too many paths, no clear direction

Frontend.
Backend.
Full stack.
DevOps.
Data.
AI.
ML.
Cloud.
Security.

Every path says:

This is the future
This is in demand
This is dying
This is saturated

So you are always thinking:

Am I late?
Am I learning the wrong thing?
Should I switch?
Should I restart?

This constant decision-making drains more energy than coding itself.

Comparison is the real killer

You open X or LinkedIn.

Someone built a startup at 19.
Someone got into Google.
Someone built 10 SaaS products.
Someone learned AI in 3 months.

And you are still debugging a basic feature.

So even when you are learning, you feel behind.

Not because you are slow.
But because you are always seeing the top 1 percent.

Earlier you compared with your college friends.
Now you compare with the whole internet.

Tools change faster than skills

You finally learn something.

A new framework comes.
A new library comes.
A new AI tool comes.

And suddenly you feel outdated again.

So the feeling is:

I am always running.
But the finish line keeps moving.

The mental load nobody talks about

The real difficulty is not code.

It’s:

Overthinking
Self-doubt
Fear of missing out
Fear of being replaced
Fear of choosing the wrong path

Earlier learning was slow but calm.

Now learning is fast but stressful.

Final honest thought

In 2026, anyone can learn to code.

But staying mentally stable while learning is the real skill.

The hardest part is not writing functions.
It’s managing your mind in a noisy world.

Too much information.
Too many examples.
Too many opinions.

So if someone feels tired, confused, lost:

It does not mean they are bad at coding.

It just means they are learning in the most chaotic time this industry has ever seen.

Software Engineering Is Shifting From a Mass Career to a High-Skill Profession

coder om — Sun, 25 Jan 2026 04:38:35 +0000

I want to talk about something I’ve been feeling for a long time, and I think many people like me feel it too, but we don’t always say it clearly.

Software engineering is slowly shifting from a mass career to a high-skill profession.
More like finance or medicine.
Less like a factory pipeline.

And this is not hype. This is not fear. This is just what I’m seeing around me.

Where I am coming from

I am from India.
Small town.
Tier-3 college.
Graduated recently.

Like most people around me, I was told one simple story growing up:

“Learn coding, get into IT, life is set.”

And for many years, that story was true.

There was a clear path:

learn basics
get a junior job
grow slowly
become mid-level
then senior

The industry had space for a lot of average people.
Not dumb people. Just normal people who needed time.

That time was provided by junior roles.

What changed (and everyone feels it)

Now with AI, something big changed.

The work that juniors used to do:

CRUD
simple features
bug fixing
writing boilerplate
copying patterns

AI does this extremely well.

Not 50%.
Not 70%.
Honestly, very very well.

So companies are asking:

“Why hire 10 juniors when 3 seniors + AI can do it?”

And that one question is quietly reshaping the whole industry.

The ladder is disappearing

Earlier the industry had a ladder:

junior → mid → senior

Now it feels like:

prove-you’re-mid → maybe become senior

The bottom layer is shrinking.

Not because software is dying.
But because human beginner work is dying.

This is the part nobody wants to say openly.

Expectations are insane now

Even for “junior” roles, companies want:

system design
cloud
DevOps
AI tools
good communication
production experience

So basically:

“Be experienced, but with zero experience.”

This is not just India.
This is US, Europe, everywhere.

The title still says “Junior”.
The reality says “Almost senior”.

Why it feels like finance or medicine now

Look at finance or medicine:

Not everyone can enter.
Not everyone survives.
Not everyone gets rich.

You need:

fast learning
strong base
mental stamina
continuous pressure

Software is moving in the same direction.

Earlier it was a mass career:
millions could enter, slowly learn, find a place.

Now it’s becoming a high-skill profession:
small percentage thrive, many struggle to enter.

The uncomfortable truth

The world is not running out of software work.
It is running out of safe learning jobs.

So what happens to all the graduates every year?

In India alone, millions graduate in tech.

But:

entry roles are shrinking
training budgets are shrinking
patience is shrinking

So many people will:

move to non-dev roles
leave tech silently
feel “I’m not good enough”
blame themselves

Even though it’s actually a structural change, not personal failure.

This is not a cycle, this is a shift

Earlier bad job markets were cycles:

2008
2020

This feels different.

Because AI doesn’t go backwards.

Once companies learn they can ship faster with fewer humans, they won’t suddenly go back to old ways just to be nice.

The real impact is psychological

The biggest damage is not even technical.

It’s this feeling:

always late
always behind
always catching up
always one tool away from being outdated

Earlier you could relax for a year and still be okay.
Now one year feels like ten.

Final honest line

Software engineering is not dying.
But the easy entry version of it is dying.

It’s becoming:

more elite
more stressful
more unequal
more unforgiving

And for people like me:
small town, tier-3 college, normal background —
the gap feels bigger than ever.

Not because we are worse.
But because the ladder itself is getting shorter.

I’m not pessimistic.
I’m not optimistic either.

I’m just realistic.

This industry is still powerful.
Still exciting.
Still meaningful.

But it’s no longer a factory pipeline for mass middle-class dreams.

It’s becoming a high-skill arena.

And everyone entering now should at least know that truth —
before blaming themselves for a system that quietly changed.

LinkedIn Strips Formatting — So I Built a Tool to Preserve It

coder om — Thu, 18 Dec 2025 09:09:58 +0000

Have you ever pasted a post into LinkedIn and thought…

“Wait… where did all my formatting go?”

Your bold disappeared.
Your italics vanished.
Your bullets turned into plain text.

I hit this problem every single time I copied content from GPT, Notion, or Google Docs.

So I dug into why this happens.

Here’s the truth 👇
LinkedIn does not support real text formatting like bold, italic, underline, or ~~strikethrough~~.

But you’ve probably noticed something interesting…

Some posts do keep their formatting.
They look cleaner.
Easier to read.
They stand out in the feed.

That’s because they use Unicode characters, not actual formatting.

So I built a small tool to fix this 👇

🚀 LinkedIn AI Formatter
What it does (and what it does not do):

✅ You paste content copied from GPT / Notion / Docs
✅ The tool detects formatting already present
✅ Converts only that formatting into Unicode equivalents
✅ You copy the output
✅ Paste into LinkedIn
✅ Formatting stays 🎉

❌ It does NOT add new formatting
❌ It does NOT rewrite your content
❌ It does NOT change structure or meaning

Just preservation. Nothing more.

Supported formatting:

𝗕𝗼𝗹𝗱
𝘐𝘵𝘢𝘭𝘪𝘤
𝚄̲𝚗̲𝚍̲𝚎̲𝚛̲𝚕̲𝚒̲𝚗̲𝚎̲
𝚂̶𝚝̶𝚛̶𝚒̶𝚔̶𝚎̶
• Bullet points

Numbered lists

If writing on LinkedIn matters to you —
readability matters.
And formatting is a big part of that.

Try it here 👇
👉 https://linkedin-ai-formatter.vercel.app

💻 Open Source at https://github.com/coderomm/linkedin-ai-formatter-app

Would genuinely love feedback — especially from people who write regularly on LinkedIn.

Building this in public 🚀
More small improvements coming.

LinkedIn #Writing #CreatorTools #IndieHacker #BuildInPublic #AItools

Hello coders 👋

coder om — Wed, 11 Oct 2023 16:44:24 +0000

I am very new to this platform. I’m currently working on .NET MVC . 🤝 I’m looking for help with Java development. Today is my first day and will definetly learn more about this and looking to share my little knowledge and experience related to coding.

DEV Community: coder om

🛍️ Building a Shopify Automation Script — Lessons & Setup Reference

🎯 What I Was Trying to Do

🗂️ The Stack I Chose

📋 Step-by-Step: What I Did, What Broke, and How I Fixed It

Step 1 — Writing the Script

Step 2 — First Run: getaddrinfo ENOTFOUND https

Step 3 — Second Run: connect ETIMEDOUT

Step 4 — The Shopify App Setup Problem

Wrong Turn 1 — Creating a Public App first

Step 4b — The Access Token Wasn't There: OAuth Endpoint to the Rescue

Step 5 — Building a Debug Script Before Going to Prod

Step 6 — The Optimizer: How Image Compression Works

🧱 Final Project Structure

⚡ Quick Reference: Run Commands

📌 Master Checklist for Any Future Shopify Automation

💡 Key Lessons (TL;DR)

Building a Reversible Bundle Transformation Engine in Shopify

The Problem No One Tells You About Bundles

The Business Requirement (And Its Hidden Complexity)

Why This Is Technically Hard in Shopify

Important Distinction: Pack UI vs Bundle Engine

The Architecture: A Three-Layer System

Layer 1: Data Contract

Layer 2: Transformation Pipeline

Layer 3: Presentation Filtering

The Sequence, End to End

Implementation: Step by Step

Step 0: Define the Bundle Metafield

Step 1: Populate Metafield in Admin

Step 2: Include the Bundle Script Globally

Step 3: Wire Checkout Button Hooks

Step 4: Inject Bundle Properties into the Product Form

Step 5: Resolve Component Variant IDs at Page Load

Step 6: Cart UI Hides Internal Properties

Step 7: The Checkout Split Pipeline

Step 8: Reconstruct Bundles on Return

Why This Avoids Separate Bundle Inventory

Tradeoffs and Why This Pattern Was Worth It

Production Hardening Checklist

QA Test Matrix

Functional Tests

Quantity Tests

Error / Edge Cases

Regression Tests

What I Would Do Differently If Rebuilding Today

What This Implementation Demonstrates

References

I Built a Tool That Turns GitHub Milestones Into Shareable Video Clips

The problem: celebrating GitHub wins shouldn’t be a side project

What Milestone Clip does

Who it’s for

How I think about the product

The 10,000-stars open-source promise

Try it

Why Tech Careers Feel So Emotionally Heavy Now

It didn’t used to feel this way

Everything is faster, all the time

The market uncertainty sits in your head

AI added pressure, not clarity

Comparison is now unavoidable

Identity and career got too close

There is no clear “done” anymore

Why this matters

Final honest thought

The Hardest Part About Learning to Code in 2026 Is Not Learning Code

What people think learning code is

The real problem is not syntax

Too many paths, no clear direction

Comparison is the real killer

Tools change faster than skills

The mental load nobody talks about

Final honest thought

Software Engineering Is Shifting From a Mass Career to a High-Skill Profession

Where I am coming from

What changed (and everyone feels it)

The ladder is disappearing

Expectations are insane now

Why it feels like finance or medicine now

The uncomfortable truth

Step 2 — First Run: `getaddrinfo ENOTFOUND https`

Step 3 — Second Run: `connect ETIMEDOUT`