DEV Community: Władysław Kulik

Building Shopify Apps Solo: My React Router 7 + AI Tech Stack

Władysław Kulik — Sat, 24 Jan 2026 09:13:14 +0000

Two apps. Two months. One developer. Here's the tech stack that made it possible.

The Challenge

As a solo developer, I wanted to build Shopify apps without drowning in infrastructure complexity. I needed a stack that would let me ship fast, iterate quickly, and not burn out managing separate frontend and backend codebases.

After exploring several options, I landed on React Router 7 — and it turned out to be the perfect choice.

Why React Router 7?

Shopify's Official Recommendation

This was the deciding factor. Shopify officially recommends React Router 7 for new apps, and their template comes with authentication, session handling, and billing integration already configured. I didn't have to reinvent the wheel.

Server and Client in One

No separate backend needed. Loaders fetch data on the server, actions handle form submissions, everything lives in one codebase. For a solo dev, this simplicity is a game-changer.

No API Layer Needed

Traditional React + Express setup means REST endpoints, CORS handling, two deployments. With React Router 7, the loader IS your API. Less code, fewer bugs, faster shipping.

Why Not Next.js?

Next.js is great, but Shopify officially recommends React Router 7. Fighting against that would mean more work and less community support. I went with the grain.

The Full Tech Stack

Layer	Technology
Framework	React Router 7
Database	Turso (distributed SQLite)
Database Client	libSQL
Hosting	Railway
Queue/Sessions	Redis
AI	OpenAI API

The Framework Evolution

Here's something interesting: I started with Remix 2 for my first app, and by the time I built the second one, Shopify had shifted to recommending React Router 7.

The migration path was smooth — core concepts remained the same: loaders, actions, server-side rendering. This gave me confidence that investing in this ecosystem was the right call.

Interesting Challenges I Solved

Rate Limiting

Shopify's API has strict rate limits. When processing hundreds of images per batch, I had to implement a queue system with Redis and careful throttling.

Billing Integration

Shopify's Billing API is powerful but tricky — free trials, usage-based pricing, subscription lifecycle. React Router actions made this manageable. Each billing event is just a POST handler.

Background Jobs

Generating AI content for 50+ items can't happen in a single request. I used bee-queue with Redis to process jobs in the background while showing real-time progress to merchants.

AI as a Real Co-Pilot

I have to mention this: Claude AI helped me write code, debug issues, and make architectural decisions throughout the entire process. It's like having a senior dev on call 24/7.

This isn't just hype — it genuinely cut my development time in half.

What I Built

Using this stack, I launched two apps under my GoodySell brand:

AI Alt Generator — automatically generates SEO-friendly alt text for product images
AI SEO Blog — helps merchants create optimized blog content with AI

Both solve real pain points for Shopify merchants who don't have time for repetitive SEO tasks.

Key Takeaways

Start with the official template — Don't fight the framework. Shopify's templates save weeks of work.
Keep it simple — Every abstraction costs time. React Router 7 let me ship fast without sacrificing quality.
AI accelerates everything — Use it for coding, debugging, architecture decisions.
Go with the ecosystem — Shopify recommends React Router 7. Fighting that choice would be swimming upstream.

Wrapping Up

If you're a developer thinking about building Shopify apps — give React Router 7 a shot. The official support, simplified architecture, and active community make it the obvious choice for solo developers.

Got questions about the stack or building Shopify apps? Drop a comment below.

Built by SilverWeb. Follow me for more posts about solo development and building SaaS products.

Unit Conversion in the Digital Age: Why It Still Matters

Władysław Kulik — Mon, 19 Jan 2026 19:57:31 +0000

You might think unit conversion is a solved problem. After all, we've had calculators for decades and Google can convert inches to centimeters in milliseconds. So why does it still matter?

Because in practice, unit conversion remains one of the most common sources of errors in engineering, science, and software development. And the consequences can be catastrophic.

The $327 Million Typo

In 1999, NASA's Mars Climate Orbiter disintegrated in the Martian atmosphere. The cause? One engineering team used metric units (newton-seconds) while another used imperial units (pound-force seconds). Nobody caught the mismatch. A spacecraft worth $327 million was lost because of a unit conversion oversight.

This wasn't a calculation error. It was a communication error — the kind that happens when different systems, teams, or regions use different measurement standards.

Why Unit Conversion Gets Complicated

Simple conversions like kilometers to miles are straightforward. But real-world scenarios often involve:

Chained conversions — Converting pressure from PSI to atmospheres to pascals requires multiple steps, each introducing potential rounding errors.

Context-dependent units — A "ton" means different things in different countries (short ton, long ton, metric ton). Data storage has similar issues: is a gigabyte 1,000,000,000 bytes or 1,073,741,824 bytes? (The answer depends on who you ask — and that ambiguity causes real problems.)

Domain-specific units — Scientists working with pressure might need to convert between pascals, bars, torr, millimeters of mercury, and inches of water. Each field has its preferred units, and collaboration means constant translation. Tools like Convertyze's pressure converter exist precisely because manually tracking 15+ pressure units gets unwieldy fast.

Temperature scales — Celsius, Fahrenheit, Kelvin, Rankine, Réaumur. The first three are common, but aerospace and thermodynamics often require Rankine. And the conversion formulas aren't just multiplication — they involve offsets, which makes mental math error-prone. A reliable temperature converter handles all five scales without you needing to remember whether to subtract 32 first or multiply by 9/5 first.

The Digital Dimension

Modern computing adds another layer. When you download a file, your browser might show megabytes while your ISP advertises speeds in megabits. That's an 8× difference that confuses people daily.

Cloud storage pricing often uses decimal gigabytes (1 GB = 1,000,000,000 bytes) while your operating system calculates using binary values (1,073,741,824 bytes). That "missing" storage space isn't missing — it's a unit conversion issue.

For developers and IT professionals, having quick access to a data storage converter that handles both binary and decimal prefixes saves time and prevents miscommunication with clients who wonder why their "1 TB" drive shows only 931 GB.

Practical Implications

Unit conversion matters in:

International collaboration — A development team in Europe sends specifications in metric; the manufacturing partner in the US works in imperial. Someone has to convert, and someone has to verify.

Scientific reproducibility — Papers often use SI units, but lab equipment might display imperial or domain-specific units. Converting correctly is part of doing science right.

Software development — APIs for weather, shipping, or IoT devices return data in various units. Hardcoding conversion factors is a maintenance nightmare and a bug waiting to happen.

Everyday decisions — Cooking with a recipe from another country, comparing fuel efficiency between cars (MPG vs L/100km — note these are inversely related), or understanding weather forecasts while traveling.

The Modern Approach

The solution isn't memorizing conversion factors. It's having reliable tools and — more importantly — developing the habit of double-checking units at system boundaries.

When data moves between teams, systems, or countries, that's when unit mismatches occur. Build verification into those handoff points. Use tools that show their work (conversion formulas, not just results) so you can verify the logic.

And when precision matters, use converters that handle edge cases: negative temperatures, very large or small numbers, and the full range of units your field actually uses — not just the common ones.

Conclusion

Unit conversion isn't glamorous, but it's foundational. The Mars Climate Orbiter teaches us that even rocket scientists can miss unit mismatches. The rest of us aren't immune either.

The good news: awareness is half the battle. The other half is having reliable tools ready when you need them.

What's your worst unit conversion horror story? I'd love to hear about bugs, miscommunications, or near-misses in the comments.

Emojis: From Japanese Mobile Phones to a Global Visual Language

Władysław Kulik — Sun, 18 Jan 2026 18:35:24 +0000

Emojis have fundamentally changed digital communication. What started as a simple solution for Japanese mobile carriers in the late 1990s has evolved into a visual language used by over 90% of the world's online population. Every day, billions of emojis are sent across messaging platforms, social media, and emails.

But emojis are far more than cute little pictures. They represent a meaningful shift in how people express emotions and connect with each other in the digital age. Understanding their history, psychology, and technical implementation reveals why these tiny symbols have become so deeply embedded in modern life.

The Origin Story: Japan, 1999

The emoji story begins with Shigetaka Kurita, a designer at NTT DoCoMo, Japan's largest mobile carrier. In 1999, DoCoMo was launching i-mode, one of the world's first mobile internet platforms. The service allowed users to send emails from their phones, but there was a problem with text-based communication.

Japanese culture relies heavily on context and emotional subtext. Face-to-face conversations include subtle cues — facial expressions, tone of voice, body language — that help convey meaning beyond the literal words. Written text stripped away all of this context. Messages came across as cold, ambiguous, or even rude.

Kurita's solution was elegantly simple: create a set of small pictographs that could be inserted into messages to add emotional context. He designed 176 icons, each fitting within a 12x12 pixel grid, covering basic emotions, weather, and common objects. He called them "emoji" — combining the Japanese words "e" (絵, picture) and "moji" (文字, character).

Kurita drew inspiration from Japanese manga, where characters are often drawn with symbolic representations called "manpu," as well as from weather pictograms and street signs. The original set was primitive by modern standards, but it solved the core problem: people could now add a smiling face to soften a message or a heart to show affection.

The concept spread rapidly across Japanese carriers. SoftBank and au (KDDI) developed their own emoji sets, creating a fragmented ecosystem where emojis sent from one carrier might appear as blank squares on another. Despite these compatibility issues, emoji usage exploded in Japan throughout the early 2000s.

For over a decade, emojis remained largely confined to Japan. Western users occasionally encountered them through Japanese apps or devices, but without standardization, they couldn't spread globally. That changed when Apple and Google began pushing for international emoji support.

Going Global: The Unicode Standard

For emojis to work worldwide, they needed standardization. This task fell to the Unicode Consortium, a nonprofit organization that maintains the universal text encoding standard used by virtually all modern computing systems.

In 2010, Unicode 6.0 officially incorporated emoji support, bringing together the various emoji characters used by Japanese mobile carriers into a unified standard. Each emoji received a unique code point — for example, the "grinning face" became U+1F600. Any device that supports Unicode can now recognize these code points and display the appropriate emoji.

This standardization solved compatibility but introduced platform-specific rendering. While all platforms agree on what U+1F600 means, each company creates its own visual interpretation. Apple's version looks different from Google's, which looks different from Microsoft's or Samsung's.

These differences matter. A 2016 study by the GroupLens research lab at the University of Minnesota found that the "grinning face with smiling eyes" emoji was rated as positive on some platforms but negative on others, where the rendering appeared more like a grimace. When the same emoji is sent across platform boundaries, the sender and receiver can interpret it very differently.

Why Human Brains Respond to Emojis

The rapid adoption of emojis is rooted in human psychology. Research suggests that people process emoji faces using neural pathways associated with emotional recognition, though not identically to how they process real human faces. Studies show that emojis trigger emotional responses and can influence how people interpret messages, even if the exact brain mechanisms differ from face-to-face perception.

Face-to-face communication includes countless nonverbal cues that help convey emotional meaning. Text-based digital communication strips away all of this, leaving messages prone to misinterpretation. Emojis serve as a digital substitute for these lost cues. Adding 😄 to a message signals friendly intent. Including 😬 indicates awkwardness.

Studies consistently show that messages containing emojis are perceived as warmer and more sincere than identical messages without them. In professional contexts, appropriate emoji use has been shown to increase perceptions of both competence and warmth — a rare combination in workplace communication.

Emojis have also become tools for social identity. Different communities develop their own usage patterns and meanings. The 💀 skull emoji, for instance, is commonly used by Gen Z to indicate something is extremely funny ("I'm dead" from laughing), a usage that often confuses older generations. Similarly, certain emoji combinations have developed specific meanings within various online communities that outsiders may not understand.

Emojis in Professional and Legal Contexts

What began as a casual communication tool has migrated into serious applications. Brands have embraced emojis to appear more relatable — social media posts containing emojis receive higher engagement rates. Email subject lines with emojis have higher open rates in many demographics.

In workplace platforms like Slack and Microsoft Teams, emoji reactions have created new communication patterns. A quick 👍 acknowledges receipt, 🎉 celebrates good news, and 👀 indicates interest. This reduces notification fatigue by allowing acknowledgment without triggering full message alerts.

Emojis have even entered legal territory. In 2017, an Israeli small claims court ruled that emojis (including 💃 and 🌟) sent in response to an apartment listing constituted sufficient indication of interest to warrant damages when the prospective tenants ghosted the landlord. The judge wrote that the emojis "convey great optimism" and awarded approximately $2,200.

Criminal cases have examined whether emoji sequences containing weapons constitute threats. Courts have ruled both ways depending on context, creating legal uncertainty. The fundamental challenge is that emoji meaning is highly contextual — what one person intends as playful sarcasm, another might interpret as hostility.

Technical Implementation for Developers

For developers, understanding emoji implementation is essential for building robust applications.

Each emoji is defined by one or more Unicode code points. Simple emojis use a single code point, but complex emojis combine multiple code points using the Zero Width Joiner (ZWJ). The family emoji 👨‍👩‍👧‍👦 is actually four separate emojis joined by ZWJs. Skin tone modifiers work similarly — 👋🏽 combines the base emoji with a Fitzpatrick modifier.

This creates challenges for string handling. In JavaScript, string length is measured in UTF-16 code units, not visible characters:

"👍".length       // 2 (surrogate pair)
"👨‍👩‍👧‍👦".length   // 11 (4 emojis + 3 ZWJs)

Applications enforcing character limits must account for this. The solution is counting grapheme clusters using Intl.Segmenter:

function countCharacters(str) {
  const segmenter = new Intl.Segmenter('en', { granularity: 'grapheme' });
  return [...segmenter.segment(str)].length;
}
countCharacters("👨‍👩‍👧‍👦")  // 1

Naive string operations can corrupt emojis by splitting them mid-sequence, resulting in broken characters displayed as replacement symbols. Database storage requires proper encoding — MySQL's utf8 only supports 3-byte characters, while most emojis require 4 bytes. The solution is utf8mb4 encoding. PostgreSQL and modern SQLite handle full Unicode by default.

Regular expressions also need special handling. The Unicode property escape \p{Emoji} with the u flag helps match emoji characters correctly.

For developers working with emojis regularly, resources like EmojiPortal provide reference information about Unicode code points, categories, and character composition.

Cultural Variations

Despite their visual nature, emojis are not a universal language. The thumbs up 👍 is positive in most Western cultures but traditionally offensive in parts of the Middle East and Greece. The folded hands 🙏 represents prayer in Western contexts but means "please" or "thank you" in Japan.

Generational gaps exist too. The 😂 "face with tears of joy" remains popular among older millennials but younger users view it as outdated, preferring 💀 for the same purpose. The 🙂 slightly smiling face has developed a passive-aggressive connotation among younger users that older generations often miss.

Platform differences compound these issues. A gun emoji 🔫 that appears as a water pistol on Apple devices appeared as a realistic handgun on other platforms until 2018, potentially changing whether a message seemed threatening.

The Future of Emoji Communication

Emoji evolution continues rapidly. Skin tone modifiers, introduced in Unicode 8.0 in 2015 and based on the Fitzpatrick scale used in dermatology, allowed diverse racial representation. Gender-neutral options and accessibility-focused emojis followed.

Static emojis are increasingly supplemented by animated versions. Apple's Memoji and Samsung's AR Emoji allow personalized animated avatars. These developments blur the line between emoji, sticker, and GIF.

AI systems increasingly need emoji literacy. Sentiment analysis must account for how emojis modify or reverse the meaning of text. Chatbots use emojis to seem more personable.

Conclusion

From 176 pixelated icons on Japanese mobile phones to thousands of symbols used by billions daily, emojis have transformed communication in barely two decades. They fill the emotional void left by text-based digital communication, trigger genuine neurological responses, and present ongoing technical challenges for developers.

These tiny symbols help people connect across distances and language barriers, expressing emotions that words alone cannot capture. Whatever form they take in the future, emojis have earned their place as a defining feature of digital-age communication.

What's the emoji you use most often? Drop it in the comments.

IANA vs Offset-Based Time Zones: What Every Developer Should Know

Władysław Kulik — Wed, 07 Jan 2026 15:55:15 +0000

"Let's meet at 3 PM UTC+2."
"Wait, is that Eastern European Time? Or Central European Summer Time?"
"Just tell me what time it is in New York."

This conversation happens in distributed teams every single day. Time zones sound simple until you actually have to work with them. And the root of most confusion comes down to two fundamentally different ways of thinking about time: IANA identifiers and UTC offsets.

The Two Approaches to Time Zones

Offset-Based: The "Simple" Way

UTC offsets seem straightforward. UTC+2 means two hours ahead of Coordinated Universal Time. UTC-5 means five hours behind. Simple math, right?

Here's how they're typically written:

UTC+0 (London in winter)
UTC-5 (New York in winter)
UTC+5:30 (India, year-round)
UTC+9 (Tokyo, year-round)

The appeal is obvious. It's just addition and subtraction. If it's 12:00 UTC, then UTC+2 is 14:00. Done.

But here's the problem: offsets don't tell the whole story.

IANA: The "Complete" Way

The IANA Time Zone Database (sometimes called the Olson database or tz database) takes a completely different approach. Instead of numbers, it uses location-based identifiers:

Europe/Warsaw
America/New_York
Asia/Kolkata
Pacific/Auckland

Each identifier represents not just a current offset, but an entire history of time changes for that location. Every daylight saving transition, every government decision to shift the country's time zone, every weird exception—it's all in there.

Why Offsets Fail (And When They Don't)

Here's a real scenario that breaks offset-based thinking.

March 10, 2024. A team schedules a daily standup at "9 AM UTC-5" with colleagues in New York.

Sounds fine. But on March 10, the US switches to daylight saving time. New York moves from UTC-5 to UTC-4.

If the calendar system stored that meeting as "9 AM UTC-5," one of two things happens:

The meeting stays at the same UTC moment, so it's now 10 AM local time in New York
The meeting stays at "9 AM local," but now all UTC calculations are off by an hour

Neither is what anyone wanted.

Now imagine the system used America/New_York instead.

The system knows that on March 10, 2024, at 2:00 AM, clocks jump forward. The 9 AM meeting automatically adjusts. Everyone shows up at the right time.

This is the core difference: offsets are snapshots, IANA identifiers are living rules.

When Offsets Are Actually Fine

Offsets aren't useless. They work great when:

Storing a specific moment in time (timestamps in databases should always be UTC)
Doing one-time conversions ("What time is it right now in UTC+3?")
The location doesn't observe daylight saving time (Arizona, for example)
Maximum simplicity is needed for a quick calculation

But for anything involving future dates, recurring events, or historical data—IANA is the only reliable choice.

The Weird Edge Cases That Break Everything

Time zones are full of surprises. Here are some that catch developers off guard:

Countries That Change Their Minds

Morocco has flip-flopped on daylight saving time multiple times. Egypt suspended DST, brought it back, suspended it again. Turkey switched to permanent DST in 2016, leaving its neighbors confused every spring and fall.

Hardcoding UTC+1 for Morocco means the app breaks when rules change. Using Africa/Casablanca means the IANA database updates handle it automatically.

The 30 and 45-Minute Offsets

Not all offsets are whole hours:

India: UTC+5:30
Nepal: UTC+5:45 (yes, 15 minutes different from India, just to be unique)
Iran: UTC+3:30
Afghanistan: UTC+4:30

These aren't mistakes. They're deliberate choices, often political. And they mean offsets don't always increment by hours.

The Day That Never Existed

In 2011, Samoa skipped December 30 entirely. The country jumped from December 29 directly to December 31 to move from UTC-11 to UTC+13. Anyone with a birthday on December 30 in Samoa just... didn't have one that year.

Try handling that with UTC offsets alone.

One Country, One Time Zone, Five Hours of Sun Difference

China spans five geographical time zones but uses a single official time: UTC+8 (Asia/Shanghai). When it's noon in Beijing, the sun hasn't reached its peak in Xinjiang—it's more like 10 AM by solar time.

Software built for users in western China needs to account for this cultural reality even though the "official" time zone is straightforward.

How to Actually Handle This in Code

The Wrong Way (Hardcoded Offsets)

// DON'T DO THIS
function convertToNewYork(utcDate) {
  return new Date(utcDate.getTime() - 5 * 60 * 60 * 1000);
}

This will be wrong for half the year and completely wrong if the US ever changes its DST rules (which has happened before).

The Right Way (IANA Identifiers)

// DO THIS
function convertToNewYork(date) {
  return date.toLocaleString('en-US', { 
    timeZone: 'America/New_York' 
  });
}

// Or with modern Intl API for more control
const formatter = new Intl.DateTimeFormat('en-US', {
  timeZone: 'America/New_York',
  year: 'numeric',
  month: '2-digit',
  day: '2-digit',
  hour: '2-digit',
  minute: '2-digit',
  hour12: false
});

console.log(formatter.format(new Date()));

For Serious Work: Use a Library

The native JavaScript Date object is notoriously bad with time zones. For production apps, consider:

Luxon—built by a long-time Moment.js contributor, excellent time zone support
date-fns-tz—tree-shakeable, works with date-fns
Day.js with timezone plugin—lightweight alternative

// Luxon example
import { DateTime } from 'luxon';

const nyTime = DateTime.now().setZone('America/New_York');
const warsawTime = DateTime.now().setZone('Europe/Warsaw');

console.log(`New York: ${nyTime.toFormat('HH:mm')}`);
console.log(`Warsaw: ${warsawTime.toFormat('HH:mm')}`);
console.log(`Difference: ${warsawTime.offset - nyTime.offset} minutes`);

The Database Rule: Store UTC, Display Local

This is non-negotiable. In any database, timestamps should always be in UTC. Always.

-- Good
CREATE TABLE events (
    id SERIAL PRIMARY KEY,
    name VARCHAR(255),
    start_time TIMESTAMP WITH TIME ZONE, -- Stored as UTC
    timezone VARCHAR(50)  -- e.g., 'Europe/Warsaw'
);

-- When inserting
INSERT INTO events (name, start_time, timezone) 
VALUES ('Team Standup', '2024-03-15 08:00:00+00', 'America/New_York');

Store the user's IANA time zone separately. When displaying, convert from UTC to their local time. This way:

Timestamps can always be compared correctly
Historical data remains accurate even if time zone rules change
Any user can see the event in their local time

The Real-World Problem: Comparing Multiple Time Zones

Here's where theory meets reality.

Teams spread across Warsaw, New York, and San Francisco face this puzzle every week. Warsaw is UTC+1 (or UTC+2 in summer). New York is UTC-5 (or UTC-4). San Francisco is UTC-8 (or UTC-7).

That's a 9-hour spread. And twice a year, when Europe and the US switch to daylight saving time on different dates, the math gets even messier.

For a few weeks in March and November, the difference between Warsaw and New York isn't the usual 6 hours—it's 5 or 7, depending on which side of the DST transition each location is on.

Most time zone tools show one conversion at a time. But when coordinating across three or four cities, seeing everything at once becomes essential.

A Tool Built to Solve This

Understanding this problem led to creating TimeSyncer.

It's a free timezone platform that lets users compare multiple cities simultaneously—mixing IANA-based zones and offset-based zones in the same view. At a glance, it shows when 9 AM in Warsaw overlaps with working hours in New York and San Francisco.

The key feature: dragging a time slider updates all clocks together. No mental math, no switching between tabs, no "wait, did I account for DST?"

It covers 400+ time zones across 244 countries, handles all the weird edge cases (yes, including Nepal's UTC+5:45), and updates automatically when governments change their time zone rules.

For anyone regularly coordinating across time zones, give it a try. It's free, no registration required.

Key Takeaways

Use IANA identifiers for anything involving future dates or recurring events. Offsets are snapshots; IANA identifiers are living rules.
Store timestamps in UTC. Always. Convert to local time only for display.
Don't hardcode offsets. DST rules change, governments make decisions, and code will break.
Use proper libraries. Native Date objects in most languages have poor time zone support.
Remember the edge cases. 30-minute offsets exist. Countries change their rules. Some places skip entire days.
For multi-timezone coordination, use visual tools. The human brain isn't built for juggling multiple conversions at once.

Time zones are one of those problems that seem simple until you dig in. But with the right understanding and the right tools, they don't have to be a daily headache.

Got war stories about DST transitions breaking production? Drop a comment below.