/home/pierce

This image is now illegal in 5 states

Mon, 09 Mar 2026 00:00:00 +0000

While my haircut should be illegal in this photo, it’s the grainy screen in the background is what is becoming increasingly illegal here in the United States.

This is me. Somewhere around 14 years old, hunched over a desk covered in screws, cables, and whatever else I could scrounge. The picture is grainy. The desk (and my hair) is a mess. But the feeling I had in that moment was very real: I just built a working computer from parts I picked out of a dump, and I finally managed to boot Damn Small Linux on it.

No one asked me for my ID. No one verified my age. No one told me I needed parental consent to boot an open source operating system.

It was the beginning of a thrill that started my lifelong incessant interest in all things computers.

5 states and counting

As of 2026, five US states have passed laws requiring age verification at the operating system level — not just for apps or websites, but for the OS itself:

California (AB 1043) — effective January 1, 2027. Requires all operating systems, including Linux, to collect a user’s birth date or age during account setup.
Colorado (SB 26-051) — penalties beginning in 2028. Requires OS providers to collect and store age brackets and share this data with app stores.
Louisiana (HB 570) — effective July 1, 2026.
Illinois (SB 3977) — effective January 1, 2027.
Utah (SB 142) — some provisions already active, with more activating throughout the year.

New York has a bill proposed (S8102A) that goes even further, explicitly forbidding self-reporting and leaving allowed verification methods up to the Attorney General. More states will follow.

These laws assume that every operating system has an account creation flow where age can be neatly verified. That might be true for Windows, macOS, iOS, and Android. But it is absolutely not true for Linux, BSD, or the hundreds of other open source operating systems that power much of the world’s infrastructure.

You can’t card a kernel

Here’s where these laws fall apart entirely: open source operating systems.

Arch Linux doesn’t have an account creation wizard. Gentoo compiles from source. Damn Small Linux fits on a business card-sized CD. There is no “sign up” flow. There is no corporation to serve a subpoena to. The author of your favorite distro might be a pseudonymous contributor in another country.

How do you enforce age verification on software that anyone can download, modify, compile, and distribute? Who is liable — the person who wrote the bootloader? The volunteer who maintains the package mirror? The kid who burns the ISO to a USB stick?

These laws betray a fundamental misunderstanding of how software works. They were written with Apple and Microsoft in mind, and open source got caught in the crossfire.

Gatekeeping curiosity

But the technical infeasibility isn’t even what bothers me the most. What bothers me is the message these laws send to the next generation.

When I dragged those computer parts home from the dump, I wasn’t doing anything dangerous. I was learning. I was problem-solving. I was building something real with my hands and my brain, completely unsupervised, completely self-directed. Nobody curated that experience for me, and that’s exactly why it worked.

That moment of raw, unsupervised exploration — pulling a computer out of the trash, figuring out which parts still worked, downloading an operating system that would fit on the tiny USB stick I had, and getting it to boot — that’s how real learning happens. Not from an age-gated app store. Not from a parental consent form. From doing the thing.

The curiosity that led me to build that computer is the same curiosity that led me to learn programming, that led me to a career in software engineering, that led me to building my own business. You don’t develop that kind of curiosity inside a walled garden.

Punishing the next generation

Age verification for operating systems treats every minor as a potential victim and every computer as a potential threat. It assumes the worst of kids and does nothing to actually protect them. A determined 14 year old will find a way around any age gate. An incurious one never needed it in the first place.

What these laws will actually do is create friction for the kids who are genuinely interested in learning. The kids who want to install Linux on old hardware. The kids who want to understand how computers actually work, not just how to consume content on them. The kids who are exactly like I was — messy desk, Kurt Cobain hair and all.

We should be encouraging that kind of exploration, not legislating it out of existence.

The kid in that photo didn’t need protection from his operating system. He needed the freedom to break things, fix them, and learn. We shouldn’t take that away from the next generation.

From Side Hustle to Full-Time: My first 5 years building Shopify Apps

Wed, 27 Aug 2025 00:00:00 +0000

Back in 2020, I published my first Shopify app. My goal was simple: generate some side income to fund my future son’s college bills. I’ve already written about that..

5 years later, I’m now working full time on my apps. It’s been a hell of a ride. Replacing my income with app revenue once seemed like an improbable dream. Now it’s my full time reality.

It all hit me when my newest Shopify swag came in the mail (thanks again Liam), and I was comparing how much my son has grown between my first care package and now.

I just need to express how grateful I am for the Shopify platform. They’ve been instrumental in facilicating this ecosystem of merchants and partners. Since 2020 I’ve managed to:

Featured as a top 40 use of customer account extensions, and showcased it as an official launch partner of their Winter Editions.
Build the first Shopify POS integration for drivers license scanning
Build the first checkout extension for customer ID verification during checkout
Attended two Editions.dev conferences in lovely Toronto 🇨🇦 which are now a family tradition
Made connections with other amazing and talented partners across the globe
Meeting the genius legend himself, Tobi

I’m so thankful for Shopify’s support, and for my closest mentors (you know who you are), merchants, customers and fellow partners that helped me realize my dream of working independently.

There’s no way I could fit all of the amazing experiences and lessons learned in these years into a single post. But I’ll try keep it to my top 5.

You’re running a SaaS, not a vending machine

Vending machines take money and dish out a product. No customer support, just a machine to maintain. That was my original idea of developing apps, probably like most developers. I’d ship a product, customers would come and I’d make passive money. Easy right?

I wasn’t particularly interested in having 1:1 email conversations or heaven forbid phone calls (😱) with merchants.

Over time, my perspective completely shifted. Now, I eagerly start conversations with prospective merchants, offering video calls and demos. The support inbox is your sales machine. Too often support is seen as an expense - a mandatory service that costs you time and mental energy, but with not much in return.

To me, support is the most fulfilling part of operating a SaaS business. The moment when a customer understands how to use your product, and they see value in it really makes my day. And if my app isn’t the solution, I still have an opportunity to be helpful and at least point in the right direction.

These conversations help you understand your product gaps, your competitors shortcomings, or identify new opportunities. They’re the entry point for growing your business, especially as an app developer. It’s your opportunity to connect with your customers, and it’s crucial to build these relationships. While your app doesn’t need relationships to function, your business does.

Support is often the only chance you have to engage with a merchant, who are also juggling multiple projects and tasks at a time. Helping them efficiently and eagerly goes a long way.

Books I recommend:

Experiments not formulas

As a developer, I liked how code is deterministic to fit a problem. You can create systems that if x then y, and easily compensate for z.

But as a soloprenuer, you constantly have to make educated (sometimes not) guesses, and learn to adapt. You need to learn to become comfortable with experimentation. Without trying new marketing channels, onboarding flows, features, or pricing—you’ll never know what you’re missing.

Now this is an art, and it’s subject to a bit of luck of course. There are so many different signals to consider, but ultimately what it comes down to is serving a customer’s need. Based on the customer’s feedback, you’ll know how close you are to hitting your target.

Now I optimize towards unknowns, because that’s where the magic happens. You might find a new segment, or solve a problem for one merchant that leads to other opportunities thanks to word of mouth.

You also can’t just A/B test everything, those are for testing with large volumes of traffic. Sometimes you only have a sample size of a dozen, and you’ll have to use your intution and conversations with your customers to understand the right path to take.

Marketing can be learned

Shopify’s app design guidelines are already a great resource if you have no idea where to learn how to market. That’s how I essentially got started.

Focus on solving a problem. A very small small problem. Not too many settings, not too many moving parts. Don’t promise the world, just solve a small thing.

How do you know it’s small enough? You can fit a description of your app in one sentence. You can distill the entire value of the app to one key feature. Once you have done that, you’re ready to build and publish it.

Even if your app doesn’t rank on the first page for a keyword, that’s okay — you’ll still get merchants trying it out. But try to differentiate. Build a better UX, use newer APIs, remove steps from onboarding, focus on a specific group of merchants that aren’t called out on other apps homepages.

Just like your app’s functionality will evolve, your marketing will too. Don’t sweat the details until you know you’ve found some traction.

Results don’t come overnight

Products are experiments, they’re little seeds you plant of an unknown type. You don’t necessarily know if they will sprout in a month, 6 months or even a year. To complicate things, you don’t necessarily know what your little plant needs.

It could fair better in a different type of soil (market), it could be a niche product that only a small subset of butterflies (merchants) need, it may be a solution that is only for a temporary problem (ran out of analogies).

The thing is, you still have to go out there and water it every day. That means experimenting with marketing copy, analyzing your keywords that lead to installs, trying different pricing strategies. It does not mean cooking up additional features just because you think it will increase rentention, or rushing out features purely on demand.

It means months of dedicated work. I got up early before my full time job, and I worked after the kids went to bed. I deactivated my social media accounts, I blocked reddit on my phone and computer. I treated my side business like a hobby, I adopted the mindset was being paid to “play”.

I recommend:

Atomic Habits
Committing to a specific time every day to work on your app
Removing distractions, like social media, reddit, gaming, TV - whatever those might be for you

Know your position, know your customer

Like (probably) all developers, I started out charging far too little. Which is fine. It gave me installs, it gave me more support tickets, it gave more experience more quickly.

But you’ll start to get a taste for a segments of customers, and you’ll also find that some segments have very specific needs. The demand for your product might be very price sensitive, or it might not be because it’s absolutely required.

Your pricing should reflect the value your app provides. Undercharging only increases your support burden.

Your app lives in an ecosystem, there will be segments of customers that you can more easily communicate or work with, or perhaps their demand is much higher for your service than another segment. Understanding who your customer is dictates your positioning for keywords and marketing.

Problems are opportunities

A merchant coming to you with an unrelated problem is an opportunity to expand your offerings, or at the least make a referral and build a partnership with another app.

Or a problem with your current app could lead to understanding a UX problem that you otherwise would have missed. Being proactive and seeking out problems signals to your customers that yes, you give a shit. The right attitude leads to more ~problems~ opportunities in the future.

Your app doesn’t exist in a bubble, you should be thinking about how your not integrating with Shopify but how you integrate into the merchant’s entire workflow for the problems they have. That might mean learning about other apps in their stack and how you can make their lives easier and more productive.

It’s such a rewarding experience to solve problems, especially in the age of A.I. where you can iterate quickly and really give a wow experience to someone else.

That’s a wrap

Ok I lied, I gave an extra couple of bonus sections. My b.

I can’t possibly fit all of the lessons learned into a single blog post. It’s best just to learn for yourself firsthand anyway.

I’m still learning, but I credit Shopify for at least giving me that initial feedback loop to at least take my first steps. Without that, I don’t see how I could have made it this far. The wonderful folks behind the App Store, documentation and amazing APIs and platform makes it possible.

But I’m so grateful for this opportunity to service others and solve real world problems. It’s hard to believe this is my full time gig, and now I have a hard time of seeing myself doing anything else. 5 years later, I’m still excited to build my small part of the future of commerce.

Happy building 🔨

How well is my Shopify app actually doing? Finding out with Rankbase

Fri, 09 Aug 2024 00:00:00 +0000

Probably like you, my expertise came from an engineering background - not marketing, which is why I choose to build apps on the Shopify platform.

One of the highest moments is getting that first install and subscription. This quick highs then fade into long nagging questions, like “but wait, how was my app found”? Then the anxiety of _“is my app listing doing OK in the competitive marketplace?” And the classic “which keywords actually matter?” And the dreaded: “which marketing channels are actually working?”

You have probably set up Google Analytics on your Shopify App Listing page, but navigating the report builder in GA4 is a steep learning curve. It’s clearly a square peg in a round hole.

We Shopify Developers need to understand exactly which keywords and channels merchants are coming from, otherwise our marketing efforts could be random casts in the dark.

Introducing Rankbase

I’ve recently stumbled across Rankbase (thanks Daniel for the referral), which goes a great job of solving these problems.

The setup was painless, I just needed to connect my Google Analytics Account and provide my Shopify Partner ID, and Rankbase gave me the exact data I needed.

No, a Shopify Partner API token isn’t required, they won’t scrape your transactions. This tool is purely a marketing funnel inspection tool, not revenue ops.

Finding your effective (and ineffective) marketing channels

Rankbase uses your Google Analytics account to create a report of Install Clicks - a.k.a. prospective merchants that have clicked the Install button on your Shopify app listing.

One of the more powerful charts breaks down your installs by source. A source could be a Shopify App Store search, Google Search, or in my case even a Yahoo search here and there:

How is this helpful? Well let’s say you’re interesting in broading your marketing reach outside of the Shopify App Store and are considering writing content for SEO/Facebook Groups that link back to your app. You could blindly write content in 4-5 different channels and pray that your hard work results in installs.

Or you could measure the effectiveness of each channel, and also using UTM parameters discover which of your blog posts/videos/tutorials are making the biggest splashes because they’re bringing in installs.

Then that feedback gives you a clue of how to shape your content for future posts and which channels you should focus on next.

Rankbase gives you this view, and even gives you a breakdown of locale of the merchant. This is extremely helpful to know if you should start to consider translating your app to different languages, but you should know that Shopify has started automatically translating listings as well.

Finding your important Shopify App Store keywords

But if you’re first starting out, you probably should get a handle on your Shopify App Store rankings first. This is because if you rank highly enough in the Shopify App Store, then those corresponding keywords will naturally appear in the top results in Google. Having your app in the top three for a given keyword is extremely powerful.

Rankbase helps you understand which searches are being made by merchants that have installed your app. From there you can determine where you position is good, or where it could use some work:

But it doesn’t stop there, one of the really cool features it has is this suggestion tool that will help you strenghten your listing for that specific keyword.

It’ll help you identify where the keyword could be placed in the various fields of your app store listing to help you rank higher. One of the best things (for partners) about the Shopify App Store is that you can make changes to your listing and get feedback in real time. So you can tweak and modify to see how your content affects your positioning.

If you have writer’s block - no sweat. You can let A.I. give you a draft, just by entering in your OpenAI key.

Wrap it up

So in short, if your serious about marketing your Shopify app and don’t want to learn the Google Analytics API to make readable charts - then I highly recommend giving Rankbase a try. Farid (the developer) is super quick to help answer questions and even gave me a short consult as part of my free trial.

It has a 14 day trial for the entire app so you can see the value, and the plans aren’t badly priced. Most likely the keyword tweaks you make from this app will pay for itself.

Hopefully this was helpful, if you want to read more tips and tricks on running and growing your Shopify Apps, follow this blog’s RSS or check me out on Twitter (I will never call it X).

Cheers and happy building 🔨

How to not fight compute piracy

Thu, 31 Aug 2023 00:00:00 +0000

Just last week, my I went to launch my development environment powered by Gitpod to fix a quick bug on one of my apps.

However, to my dismay, I found my paid account was now blocked without any recourse. I was effectively blocked from running my trusty development environment for the better part of the day.

Eventually after sending several emails and messages over Discord, the Gitpod team realized my account was falsely flagged and they reverted the ban.

I’m actually lucky to have this situation resolved relatively quickly. Larger teams or enterprises are notorious for outright ignoring blocked users, because the almighty fraud algorithm determined you’re guilty. No appeals. No do overs.

As an end customer this is a terrible experience. There was no explanation and no answer to why it happened, and lack luster reasoning at best.

The nature of the beast

I empathize with the these product teams though. Freemium fraud is a particularly nasty beast. It’s a fine line between providing a sample of value to developers evaluating your product, while at the same time preventing losses from crypto mining, command and control bot net servers, or proxying exploits or data theft.

Let’s imagine you’re offering compute as a service. Perhaps you’ve started a hosting company that specializes hosting Node.js apps or scripts.

Naturally developers need to try the tool before committing to even the basic plan. Developers are also fickle and really need to sample before they buy. They also want self service and they want no interaction with sales at all if they can help it.

So practically industry standard to offer a Free tier. But the issue is the bad actors that leverage your free tier to crypto mine to the free tier limits and scale up on as many free tier accounts as possible.

Nailing jelly to a wall

So you implement detections on NPM package names to ban accounts. That will work for potentially awhile, but the bad guys are just as technical. They can republish these packages under new names on NPM.org. Or they can deploy the code directly in the Node.js app, without even using a package manager.

You can even scan the code itself, search for mentions of similar variable names from a known bad signature. Or certain port usage, network usage.

Or you can start to detect nefarious use by unusual resource consumption, which I believe what got me into trouble recently.

The cure can be worse than the disease

Be very careful with your anti-fraud detection schemes.

You can unintentionally block or impede your paying customers, self-inflict churn and hurt your brand reputation.

Anti-fraud detection rules that automatically employ bans or suspensions should always follow these basic guidelines:

Don’t automatically ban paying or trusted users
Allow automatic unblocking after passing KYC
Evaluate efficiency of the rule periodically

Don’t ban trusted users

There should be very clear actions that elevate a users trust level in your system.

For our sample hosting company, potentially the strongest signals are payments. If a customer is in good standing on their subscription with multiple payments, then most likely they are not going to revert to a Free plan and crypto mine or abuse your service.

Define a list of actions or attributes that a trusted account takes that an bad actor cannot. These will define your trusted users.

Verified email addresses
Verified phone numbers
At least one successful payment

Then design your anti-fraud processes to exclude these trusted accounts.

Keep the door half open

Now that you have employed a rule to automatically ban or suspend users based on an algorithm, expect false flags.

Not only is it a terrible experience to those falsely banned, but it also leads to lost sales.

To alleviate the customer support operational burden, give the flagged user a means to prove trust.

One simple way to set this up is by adding a KYC gate. This gates are extremely effective at thwarting repeat bad actors. They stop fraud by identifying the customers real world information like a drivers license, passport, etc.

Now this is the most sure fire option, but there are other trust signals that you can employ instead, like verifying a phone number with a one time code in an SMS message.

The severity of the potential fraud should dictate which KYC gate should be used to prevent it.

Continuously evaluate your rules

Anti-fraud rules are short lived because they are used against financially motivated and actors. Eventually these rules will be circumvented or their actions so blended against real traffic and good user activity that once again you have to split the hairs and make new rules.

You also have to be careful to not introduce too much friction and over flag accounts. This is worse than actually defeating the fraud in most cases.

Please steal these ideas

Why am I so confident these methods work? I have personally employed them at RVshare as I set up the Trust & Safety dashboard app, processes, analytics, product integrations and eventually a small team dedicated to this set of particular problems. I’ve seen what works well and what doesn’t.

Rental marketplace fraud is an entirely different set of bad actors and attack vectors, but the motivations and methodologies can apply to any business to weave the needle between prevention and conversion optimization.

Dealing with a particularly nasty form of fraud and need help? Please message me. I’m always happy to help.

Build a Currency Exchange API - without code

Fri, 14 Jul 2023 00:00:00 +0000

Recently, Shopify has removed the total_price_usd field from their Admin Order API. This caused me a big headache personally. Long story short, now I had to find a way to quickly convert orders back into USD.

Unfortunately, I couldn’t find a currency conversion API in Shopify, but I did find an API that offered a free tier. Open Exchange Rates offers 1,000 calls per month for free.

Great. But in this case I’m processing quite well over that, and I can’t afford the usage here for the value provided.

Yes, I’m known to be frugal, I drive a 2003 Corolla.

So I’ve found a way to leverage Pipedream workflows and a data store to cache the prices and then serve a real time API endpoint to respond to requests.

This hack essentially offers a free exchange API with an hourly refresh on currency rates back to USD. Lucky for you, I’m sharing the two workflows for you too, so you just need to register an API key and plug it in.

Storing current currency exchange rates in a Data Store

The sole purpose of this workflow is to retrieve and store the current currency exchange rates for USD into a Data Store.

Copy this workflow to your Pipedream account to get started.

The first step is to set up a workflow that will update a Data Store of current exchange rates. We’re going to use the Open Exchange Rate API that grants a generous 1,000 API requests per month.

After signing up for an account and confirming your email address, you’ll be granted an App ID (a.k.a. your API key).

This workflow is configured to run every hour, so the math comes out to 24 calls per day * 31 days per month = 744 calls per month, which is under the 1,000 calls limit for this API.

Now that you have an API key, use it in this workflow by connecting it:

So next you’ll need to create a new Data Store, I named mine Exchange Rates for simplicity:

Then after deploying, when you open your Data Store you’ll see the rates property is updated every hour with a mapping of all prices:

Creating the Conversion API

The second and last workflow we need to copy will create a simple GET endpoint to allow us to query this data store of fresh exchange rates.

Copy this workflow to your Pipedream account to create the endpoint.

The only step you need to perform here is connecting your brand new Exchange Rates data store, and you’re good to go!

Don’t forget to also set the key property to rates so it can find our stored exchange rates:

Now use this endpoint to pass the currency_code and amount as query params, then the response will include the cached currency rate from your data store.

It’s wicked fast, and it scales.

This pattern is pretty interesting to me, I’m starting to leverage Pipedream to cache various APIs or add an abstraction layer on top of APIs to make them easier to use.

This is especially useful for semi-hidden or undocumented APIs that you want to interact with. I’ll have to share more about that in a latter post.

A Eulogy to Free Social Media APIs

Tue, 06 Jun 2023 00:00:00 +0000

Recently both Twitter and Reddit have effectively killed their APIs to the public. Much to the chagrin of their users. A handful of the most popular subreddits like /r/videos, /r/reactiongifs and /r/lifeprotips are staging a protest by voluntarily shutting down June; some even threating to shut down permanently.

This new user hostile policy will also end 3rd party clients to Reddit as well, leaving the only option left analytics leaden spyware that is the official Reddit client.

This is a trend that I personally don’t see reversing, and it will only expand to non-text based social media platforms next.

Looking back at the decade plus that these APIs offered a real-time firehose into organic rich content, it should have been obivious. Programmatic access to effectively a rich feed of near infinite dynamic actual human generated content - for absolutely nothing. Just stay within our polling limits please; have fun kids.

These platforms that opened up their APIs saw innovations exceed their own capabilities, and often enriched the platform. The RemindMe bot on Reddit was one of my favorite examples, especially when it came to internet strangers holding a grunge over some prediction of a future event: RemindMe! 2 years "Was the term 'highly regarded' used in the Presidential Debate?"

We, I, took these APIs for granted. I leveraged them to power my first startup client, a social media aggregator aimed for university administrators. I’ll always look back fondly learning to build an ETL pipeline to load, abstract and store these feeds of content into a normalized database (heck even reverse engineering one). There was no gate, I didn’t need capital. Just armed with my laptop, a few PHP tutorials and a will to learn.

Don’t hate the players, hate the A.I.

In the end, I can see why the writing is on the walls.

If these platforms were vulnerable to bots gaming posts or unfairly influencing posts away from organic discussion before, the cat’s out of the bag now. The heuristic line of quickly detecting a bot vs a human on social media has become that much more blurred.

Even if that isn’t the primary reason, consider the hosting costs of unlimited access to databases that are most likely transfering petabytes if not zettabytes of data per day; consider the reputational cost of unfettered bot access powered by LLMs to these text based platforms. The sugar high of low interest rates over the past decade is over, tax write offs for software development too.

Mourn for the next generation

It’s not all bad. On one hand, never before has learning software development been so accessible also thanks to LLMs. However, there’s a stark difference between learning "Hello, world" on an isolated computer and actually retrieving real time content from social media platforms that are the lowest barrier to entry for learning API interactions that actually leverage the power of the internet.

Sure, you can learn a weather, Pokemon or Star Wars character API - the fundamentals are the same. But it’s just not that compelling to new learners.

However, the fun of interacting with /r/gifs programmatically is now over for the future generation without the means to pay:

I specifically remember my first successful API call to search Twitter with a simple API I registered with on the same day. The rush of understanding the possibilities that lay before me. Now those opportunities are locked behind an approval process and a credit card.

Now, it’s possible that I’m just overly nostaglic, but all of the fringes of the internet that were open and free are now closing. There must be new edges the next generation of learners are finding, and it’s just out of my perspective. But I reflect on how lucky I was to find these while they were open.

Thanks for the good times!

Disagree? @ me.

Funding my son's college with a Shopify app

Mon, 09 May 2022 00:00:00 +0000

Shopify Devs sent me a package of swag, and I feel like I must reciprocate as best I can.

This is the story of how I finally built and shipped my first actual revenue generating app.

The year was 2020, a dark and infamous year of course; but simultaneously a golden age of side projects. I was a dad to be and with faced with a lot of time to think about the future.

The small, teeny tiny motivation

I had always wanted to build a small project that actually generated revenue. I knew I could either spend my off time playing a ton of videos games, or I could focus and actually ship something.

Before this I didn’t have constraints, I just had irregular free time without a real goal.

I would fail to build the MVP (bad), or fail to find a market (worse). Either way it was hours wasted.

I knew I didn’t have a large window (9 months) and still working full time.

I needed to leverage an existing market and build something folks needed, and focus on using my dev skills to build something to easily plug and play.

And I knew I had to take advantage of what was in front of me:

Time.

Lots. And lots. Of uninterrupted socially distanced time.

Micro apps can grow a large fund

I also didn’t need the app to earn a ton of money. I could contribute up to $4,000 per year to max out tax free contributions individual Ohio 529 plan.

$4,000 / 12 months = ~$333
$333 / $10 per merchant = ~34 subscribing merchants

By focusing on a small goal, for once I was able to ship and deliver a small revenue generating app.

$333 per month at a %6 growth rate without taxation for 18 years will grow to around $153,225. At $10 per subscription, I just needed 34 subscribers to reach my 529 contribution goal.

It’s not a crushing goal of trying to replace a full time job, but at the same time it’s a meaningful amount of money given enough time.

Enter Shopify Apps

I’m half ok at building stuff, especially extending existing systems. Give me a set of API documentation and I can figure it out.

But I wasn’t then and I am still not an eCommerce merchant.

Because of my limited timeline and limited goal, I swallowed my pride and made an app for an exisiting category that I thought was totally oversaturated with solid high review apps.

After all, I only needed to capture a small part of the market to reach my goal. Why take a big swing where a ball might be an instead take a stab a pie you know is there?

I can compete?

This ended up being a great decision. My entire devtrepreneur experience, I had been trying to swing for home runs each at bat.

I would whiff, but extremely slowly and with great effort.

I shipped the MVP of my app in a few weeks, and it was approved in another two weeks.

I was live, and much to my surprise I was getting a small trickle of installs - even subscriptions 😮

Small differentiators matter

My little app never will overthrow my well entrenched competitors. They will always outrank me in the SEO & Shopify App Store rankings.

But that doesn’t mean you can’t find a market with 2nd, 3rd, or 4th place.

My app was never top 10, but it resonated with a few merchants that had similar values that I tried to strive for in my app:

No Shopify app should ever need to alter your theme code
Don’t make me think
You shouldn’t feel like you’re in an app. Use Shopify’s design system.

Following a set of rules gave me a similar but different app than my competitors, which was enough to make me and my awesome customers happy.

Did you reach your goal?

Yes, 4 months after launch 🎯

Thanks to feedback and asking questions as much as I could, I found a set of must have features that others weren’t supporting, and did my best to deliver.

Finding your motivation

2020 was a great year for side projects - some picked up frisbee golf, some ran indoor marathons, some bought out entire shelves of toliet paper, and others tried to start businesses.

Looking back, sure the pandemic had an influence on my first profit generating app. But several other internal & external factors had played a part:

I had a small yet possible goal
I had a clear MVP objective by looking at competing apps
I had quite a bit of free time
Building on an established platform allowed me to focus on just building

5. They send you awesome swag!

So long story short, like Sublime Text 2 I will ride out my micro app until it dies. But until then I’m just glad knowing that I built something that will widen my son’s horizons just a little, or at least give him more options.

Getting started building Shopify apps

Checkout shopify.dev and the Shopify App Store and don’t forget to read the forums for finding pain points.

Thanks @ShopifyDevs for the awesome gifts and support over the years, and helping me build my first micro business.

That’s my story of building my first Shopify app, best of luck and happy building 🔨

Shopify App install notifications to Slack without code

Thu, 24 Feb 2022 00:00:00 +0000

Why would you want to be alerted when a Shopify store installs, subscribes or uninstalls your Shopify app?

Well when you’re finding some time off, enjoying a beer or just away from the laptop it’s always nice to see your app working for you.

On the flip side, knowing when a merchant uninstalls your app gives you a chance to immediately respond with a personalized message to try and win them back.

Sure, you can accomplish this functionality with coding directly within your app. It sounds easy right? Until you consider all of the steps:

Install a Slack package in your app.
Craft a message in JSON from Shopify’s API data.
Upgrade the package with new updates.
Create a new background queue for handling these notifications out of band so your app’s performance isn’t affected.
Repeat for installs, uninstalls, subscriptions, deactivations, & reactivations.

Read on for detailed setup instructions, or just copy my Shopify App to Slack notifications workflow here and riff on your own:

Copy this Workflow

Enter Pipedream

Pipedream is the perfect solution for this kind of integration.

I wrote a Shopify Partner API Integration for Pipedream, it’s free and open source to use in your Pipedream workflows.

Or create your own workflows with one of the 500+ pre-built actions, or build one of your own with Node.js, Python, Go or Bash; all without opening your IDE.

Steal my workflow

Setting up the workflow doesn’t require any code, you just need a few copy pastes from your Shopify Partner dashboard to get started.

Here’s how to do it.

First, copy my workflow that already connects Shopify App events to Slack:

Copy this Workflow

After your register, click Copy in the top right of the workflow to copy it to your Pipedream account:

Now you’ll have your own version of the workflow saved to your Pipedream account.

Creating a Shopify Parter API Key

In order to integrate with our new shiny Pipedream workflow with your Shopify Account, you’ll need to create an API key.

First login to your Shopify Partner account.

Then open your account settings, scroll to the bottom of the page and click on the Manage Partner API Clients button:

Then click the Create API Client button:

Awesome. Now you have an Shopify Partner API token you can use to authenticate your Pipedream workflow with:

Find your Shopify Partner Organization ID

This one is hidden in plain sight.

Opening up your Shopify Partner Settings reveals your Shopify Partner Organization ID:

Copy this number too so we can wire our workflow up to it.

Connecting your Shopify Partner account

Now armed with both your Shopify Partner Organization ID & API Key, we can return to your Pipedream workflow to finish the integration.

Now enter in your Shopify Partner ID we copied from before, your new Shopify Partner API key, and give this integration a name:

Connecting your Shopify App

The last integration step is to inform the workflow which of your Shopify Apps it should integrate with.

So let’s find your App’s ID and enter it into the workflow.

Find your App’s ID

Your App ID can be found by visiting your app details in the Shopify Partner Dashboard and viewing the URL.

It’s the number after the /apps/ portion of the URL:

Entering your Shopify App ID into the workflow

Back in the workflow enter in the App ID in this format:

gid://partners/App/<your App ID here>

Click Save to finish the integration.

Connect to your Slack workspace

Congrats, the hard part is over. Connecting to Slack is a cinch with Pipedream. Scroll down to the last step in the workflow and click Connect account to authorize your Slack account:

Configuring the Slack message

This is the real final step. Enter in these values for the Slack action and click Save then Deploy in the top bar.

Here’s the values for each field to make it easier to copy & paste:

Option	Value
Slack Channel	Choose from the dropdown menu
Blocks	`{{ steps.nodejs.$return_value }}`
Notification Text	`New Shopify Notification`
Bot Username	`Shopify Partner`
Icon	`:shopping_bags:`

Don’t forget to click Save then Deploy to make your Workflow live.

If all goes well, you’ll be getting updates in real time from your Shopify App.

This is just one example of the cool & useful things you can do with Pipedream.

Want to see another no code workflow example? Send your tutorial requests to me by email or message me on Twitter at @ctrlaltdylan.

You can also catch me hanging out at the Pipedream community Slack as well as our forum.

Have a prosperous day!

Why Pipedream?

Tue, 04 Jan 2022 00:00:00 +0000

I just wanted to make a quick write up on the next team I’ve joined and the product we’re building - Pipedream.

What is Pipedream?

In layman’s terms, Pipedream is a workflow builder. It’s a platform where you can build workflows from a series of pre-built steps - or build your own.

For example, with just a few clicks in Pipedream you can build a workflow to listen for a specific hashtag on Twitter and add them onto a Google Spreadsheet:

What’s even more amazing is that this workflow will keep populating this spreadsheet the the newest tweets in real time. Your spreadsheet is now a living database, just a few clicks.

There are over 500 integrations available out of the box, which means you can build nearly limitless applications.

You might be saying - ok cool Dylan; but I can do this same thing in Zapier or IFTT? What’s the big deal?

The big deal is that with Pipedream you can jump down into code at any time. You don’t need to register as a developer, you don’t need to jump through anyhops to customize a workflow to meet your needs.

It’s abstracted just enough to get started, and flexible enough to grow with your requirements.

The dog food tastes good

“Eating your own dog food” is tech speak for writing tools that you actually use.

It’s a silly phrase, but the idea is powerful. By building products you actually use, you become the expert in the customer’s wants and needs.

I loved working for RVshare because I am very much into travel and for a time lived out of tiny house full time. It was very close to dog fooding.

Pipedream is like that, except for maybe renting an RV once a year, I have used Pipedream to do all kinds of interesting workflows without coding:

Adding subscribers to a Mailerlite group automatically to kick off welcome & marketing email campaigns
Notifying a #finance Slack channel whenever my business bank account balance changes
Sending me a daily summary of revenue & profit from my Shopify apps

You might be saving to yourself, yea doesn’t Zapier & IFFT kind of do the same thing?

In a ways yes, but Pipedream takes it a step further because you can create artibitrary living scripts on the fly.

The difference between high code & no code

You’re probably aware of how often Google Spreadsheets replaces an application. It’s a quick & dirty malleable database with some basic permission handling, very vague history logging, and does an OK job at showing data.

Where it falls short is painfully obvious for many reasons I’ve written about before.

But it’s the backbone for many “side” effect work in businesses for one off tasks or follow ups by various departments. Anyone with or without coding skills can edit a spreadsheet’s structure, modify values and formatting.

On the flipside - a high code solutions are much closer to concrete - they’re much more rigid, slow and expensive to implement. The pro side is they are the operating closer to bare metal - a custom application can fit any mold, withstand change management thanks to Git and make custom interfaces.

Pipedream is not another application framework, nor is it a replacement for no-code tools like Zapier or IFTT. Instead it’s enhancing the productivity for all by building a solution in the sweet spot of low code.

At the end of the day, we’re all just internet plumbers

Whether we like to admit it or not, too much of our time is spent on wiring our application with 3rd party services.

We give ourselves lofty titles like Full Stack Engineer, Software Developer, etc. But let’s be honest, we know our apps just are clever integrations of 2 or more APIs with some custom logic between and the right interface for our audience.

We could ship more and faster, but we’re held back by necessary yet trivial work.

How many times have you had to program

Add a newly user to your marketing email provider to start a drip campaign?
Make a one off CLI task to upload some data to a Google Sheet for accounting?
Make a Slack message on a specific event or on a timer for debugging or operation purposes?

The reality is engineers have to not only provide solutions for customers - but support internal departments as well.

How developers would like to spend their time:

The reality:

After the first 3 dozen times installing a official package for your language or framework of choice, wiring it up to your business logic - you’ve already fallen for the maintainence trap.

Heaven forbid you forget to make sure your app doesn’t crash when the service is down. And now you’re having to keep up with maintaince and security updates on this package within the core of your application.

Your time is expensive, you should focus on providing real value to your customers via your differentiated core product above all else.

Democraticizing serverless & event based systems

The promise of serverless is mostly misguided. The idea that your application would separate into microservices with sharply narrowed focus sounds smart, but in reality it adds complexity not reduces it.

The worst of it is that it’s a heavy investment of time & learning without the gain of saving time in the long run. The holy grail of infinite scalability for “free” actually costs in terms of moving the debugging level up to the network, resource intensive & heavily complex dev environments. Heck, the concept of keeping “warm” doesn’t exist for apps running on 1 server. Long running functions? Woof be careful there.

The real benefits of serverless are only harvested by large teams that had dedicated engineers to just documenting and developing these cases, well until now.

Your app should only be concerned providing the primary process that brings value to your customer - everything else can be handled with asychronous & out of band workflows.

Since Pipedream’s interface to your application is really just HTTP webhooks, you get an event based serverless workflow without learning a new framework or an complex event system like Kafka.

With Pipedream you can create workflows that trigger on your business events, freeing up your developers to concentrate on building the best experience for your customers.

Examples of common businesses events you can map to Pipeline Workflows:

customer.registered
order.created
subscription.upgraded

All of these events have clear primary objectives in your businesses application. However, there are secondary actions like registering new customers with your marketing email providers, reporting to analytics dashboards, etc.

Raising the stakes, by lowering the bar

More often than not a good tool will do the following:

Organize complexity
Lower the bar to entry
Empower a wider audience to build solutions they couldn’t before

Pipedream is checks all of these boxes above, and is just getting started.

Interested in learning more?

Rails can humanize strings too

Wed, 29 Jul 2020 23:52:40 +0000

Enumerated values are not people friendly

Frameworks typically don’t include this kind of method out of the box with Strings. If you have an an emum of machine level names, naturally you want to use underscores and lowercases to keep it machine friendly:

   class Vehicle
     enum vehicle_type: %i(car truck semi_truck motorcyle)
   end

If you ever wanted to print out the vehicle_type in a string, your users would be a little confused as to why there would be underscores in the text:

   @vehicle.vehicle_type = :semi_truck
   puts "This type of vehicle is a #{@vehicle.vehicle_type}"
   
   # not really user friendly... just say "semi truck"
   => "This type of vehicle is a semi_truck"

Enter Humanize

Developer happiness is exactly what Rails so famously preaches above all else. And the String#humanize method is a great example.

Without even having to create a mapping of cannoncial names to their given machine names, you can use .humanize to convert underscores into spaces:

   @vehicle.vehicle_type = :semi_truck
   puts "This type of vehicle is a #{@vehicle.vehicle_type.humanize}"
   
   # yay, now our output is much more _human_ friendly. Remember, we write apps for real people
   => "This type of vehicle is a semi truck"

There’s even support for options like capitialize: true which will captialize the string:

   @vehicle.vehicle_type = :semi_truck
   puts "This type of vehicle is a #{@vehicle.vehicle_type.humanize(captialize: true)}"
   
   # yay, now our output is much more _human_ friendly. Remember, we write apps for real people
   => "This type of vehicle is a Semi Truck"

Anyway, check the docs out but that’s my 5 minute cool find for today. Happy building.