←all writing
1117 Jun 2026/4 min read

From Liquid to running a SaaS: the tech I had to learn, in order

I started with Shopify themes in Liquid and now run the stack of a SaaS as CTO. This is the order I learned things in, and which project forced each step.

CareerLearningDevOps

I did not plan a path from Shopify developer to CTO. Each step came from a project that needed something I did not know yet. Looking back, the order makes sense, and it may help someone who is where I was in 2021.

1. HTML, CSS, JavaScript (2019)

My first job was frontend developer at White Orange Software. Turning designs into pages.

I still use this more than anything I learned later. When a layout breaks on a phone or a page feels slow, the answer is usually in plain CSS or plain JavaScript, below whatever framework is on top.

2. Liquid and the Shopify theme system (2021)

Liquid is a template language. You cannot fetch from a database or call a function you wrote. You get the objects Shopify gives you and you print them.

Working inside those limits taught me to read a platform’s data model before writing code. Products, variants, collections, metafields. Most hard Shopify problems are data model problems.

3. Third-party APIs (2023)

PetsFirst needed Razorpay for payments and Shiprocket for delivery. This was real work with outside APIs: keys, webhooks, test mode and live mode, and failures that are not your bug.

4. The Shopify Admin API and Node scripts (2024)

At Renaissance Jewel, the catalogue was too big to manage by hand. So I wrote Node scripts that create and update products through the Admin API.

This is where I left the theme editor for the first time. I learned rate limits, retries, and making a script safe to run twice. It was also the first time I wrote code that ran on my machine against real production data, which makes you careful quickly.

5. A custom Shopify app (2024)

Sethi Couture needed logic that a theme cannot hold, so we built a custom app. Now there was a server that I was responsible for. It had to be deployed, it had to stay up, and it had to keep working when Shopify changed an API version.

6. A full product alone: Next.js and Postgres (late 2024)

Roosthaven was my first build with no Shopify in it at all. Next.js front end, Node.js back end, Postgres on Neon, AI features, AWS.

Everything Shopify had been doing for me without my noticing, I now had to do: authentication, a database schema, file uploads, hosting, deploys. I set up a CI/CD pipeline here because I was alone and could not afford manual releases.

7. An API for two clients: Express, MongoDB, Flutter (early 2025)

PetsFirst Health had a website and a mobile app on one API. This taught me API design in a way a single web app never does. When an installed app depends on your endpoint, you cannot rename a field because you feel like it.

8. Running a SaaS (2025 onwards)

At Happy Pet Tech the code was not the new part. The new part was everything around the code.

  • One database shared by many businesses, where one missing filter is a data leak.
  • A pipeline that many developers push through every day, not only me.
  • nginx, Docker, monitoring, rollbacks.
  • Real-time features: sockets, push notifications, webhooks from WhatsApp.
  • A team. Code review, deciding what not to build, and being the person who gets called when it is down.

What I would do differently

I would learn databases earlier. For years Shopify hid the database from me, and I thought of data as “what the platform gives you”. Schema design, indexes and query cost were the biggest gap when I moved to full products.

I would also learn deployment earlier. I could build a lot before I could put any of it on a server myself. The day I could deploy my own work without help, the kind of projects I could take changed.

What Shopify gave me that courses do not

Years of watching real customers buy, or fail to buy. I know what a slow page costs, what one extra form field costs, and how a confusing error loses a sale. I bring that to every technical decision now, and I think it is the reason I care more about how a product feels to use than about which framework it is built with.

← all writing nextTwo AI features I built: one for pet parents, one for home buyers →